Installare Adobe Acrobat Reader gratis con Chocolatey

Installare Acrobat Reader con Chocolatey senza perdere controllo del pacchetto

Se devi portare Adobe Acrobat Reader su più postazioni Windows, Chocolatey è una scorciatoia pulita: riduce i click, rende ripetibile l’installazione e ti lascia un punto unico da cui aggiornare o rimuovere il software. Il punto non è “installare e basta”, ma farlo in modo prevedibile: sapere quale edizione stai distribuendo, come viene gestito il silent install, dove guardare se qualcosa si rompe e come tornare indietro senza lasciare il sistema in uno stato mezzo configurato.

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

Qui l’obiettivo è pratico: installare Reader con Chocolatey, verificare che il pacchetto sia davvero quello atteso, evitare di sporcare il sistema con opzioni inutili e tenere già pronto il rollback. La logica è da sysadmin, non da utente finale: prima osservi, poi installi, poi controlli. Se serve, chiudi con un update controllato invece di lasciare il pacchetto fermo a una versione vecchia per mesi.

Prerequisiti minimi e scelta del pacchetto

Chocolatey deve essere già presente sulla macchina. Se non lo è, va installato prima con privilegi amministrativi. Per Reader conviene usare il pacchetto ufficiale del repository Chocolatey, ma la prima verifica non è l’installazione: è il controllo del nome esatto del pacchetto e dei metadati disponibili, così eviti di prendere un pacchetto simile ma non corretto.

La verifica più semplice è questa:

choco search adobereader --exact --limit-output

Se il pacchetto è disponibile, vedrai una riga con il nome esatto. Se non compare, non forzare: controlla prima la sorgente configurata di Chocolatey e poi il nome del pacchetto. Anche un repository locale o un mirror aziendale può cambiare il risultato.

Per capire da dove stai scaricando i pacchetti, usa:

choco source list

Se stai lavorando in un contesto aziendale, questo passaggio è importante quanto l’installazione stessa: un mirror interno può introdurre ritardi, versioni congelate o policy di approvazione che influenzano il comportamento finale.

Installazione silenziosa di Adobe Acrobat Reader

L’installazione base si fa con un comando semplice. Su una shell amministrativa di Windows, esegui:

choco install adobereader -y

Il parametro -y conferma automaticamente le richieste. In un contesto operativo serio conviene aggiungere anche il flag per evitare interazioni indesiderate e mantenere il comportamento prevedibile nei task automatici:

choco install adobereader -y --no-progress

Se il pacchetto richiede riavvio o mostra dipendenze aggiuntive, Chocolatey lo segnala a fine esecuzione. Non ignorare l’output: è la prima fonte di verifica. Se l’installazione fallisce, il motivo più comune non è Acrobat Reader in sé, ma una policy locale, un download bloccato, un proxy che altera la sessione o una versione già presente che va gestita in upgrade invece che in install pulito.

In caso di automazione, io preferisco sempre esplicitare il contesto con un log file, così da avere una traccia consultabile dopo il run:

choco install adobereader -y --no-progress | Tee-Object -FilePath C:\Temp\choco-adobereader-install.log

Il log non sostituisce il controllo a video, ma ti evita di perdere i dettagli se il job gira da remoto o in finestra manutentiva.

Verifiche immediate dopo l’installazione

Non basta che il comando termini senza errori. Devi verificare tre cose: che il pacchetto sia registrato, che l’eseguibile sia presente e che l’applicazione si avvii correttamente. Per il primo controllo:

choco list --local-only adobereader

Se il pacchetto è installato, comparirà nella lista locale con la versione presente. Per il secondo controllo, cerca il binario o il collegamento creato dal pacchetto. Su molte installazioni Reader finisce in percorsi standard di Windows, ma il punto non è memorizzare un path fisso: è verificare che l’installer abbia completato la scrittura delle componenti principali senza errori di permesso.

Per il terzo controllo, avvia Reader e verifica che non vada in crash immediato. Se vuoi un check rapido da CLI, puoi almeno confermare la presenza del processo dopo l’apertura manuale:

Get-Process AcroRd32 -ErrorAction SilentlyContinue

Se il processo non compare, non dare per scontato che il pacchetto sia rotto: controlla Event Viewer, log applicativi e eventuali warning di protezione di Windows. In molte installazioni il problema è un blocco locale del profilo utente o un’estensione interferente, non il setup in sé.

Gestione degli aggiornamenti con Chocolatey

Il valore vero di Chocolatey arriva quando devi mantenere il software allineato. Reader è un target tipico di aggiornamento frequente, perché il rischio non è solo funzionale ma anche di sicurezza. Un pacchetto fermo per mesi espone a vulnerabilità già note e non è una buona idea lasciarlo lì solo perché “funziona”.

Per aggiornare il pacchetto in modo esplicito:

choco upgrade adobereader -y --no-progress

Prima di farlo su larga scala, controlla quale versione hai e quale è disponibile nel repository. Un buon check preliminare è:

choco outdated

Questo ti mostra i pacchetti installati con una versione più recente disponibile. Se stai operando in un ambiente gestito, il passaggio giusto non è aggiornare “a sentimento”, ma validare la versione in una macchina campione, verificare compatibilità con plugin o integrazioni locali e poi procedere con il rollout.

Se vuoi evitare che un aggiornamento automatico ti prenda alla sprovvista, puoi congelare temporaneamente il pacchetto durante una finestra critica. Non è una soluzione definitiva, ma è utile quando devi stabilizzare un parco macchine durante un cambio più ampio.

choco pin add -n=adobereader

Ricordati però che il pin va rimosso quando il blocco non serve più:

choco pin remove -n=adobereader

Lasciare un pin dimenticato è uno di quei dettagli che poi si trasformano in “perché questa macchina è l’unica non aggiornata?”.

Installazione su macchine nuove e distribuzione ripetibile

Se devi preparare più postazioni, il comando base resta lo stesso, ma il valore sta nella standardizzazione. In pratica, conviene avere uno script che faccia almeno questi passi: verifica della presenza di Chocolatey, installazione del pacchetto, controllo del risultato e registrazione del log. Un esempio minimale in PowerShell:

$pkg = 'adobereader'
choco install $pkg -y --no-progress
if ($LASTEXITCODE -ne 0) {
  throw "Installazione fallita per $pkg"
}
choco list --local-only $pkg

Questo non risolve tutto, ma evita la classica situazione in cui lo script continua anche dopo un errore evidente. Se vuoi farlo bene in ambiente enterprise, aggiungi logging su file, timestamp e raccolta del codice di uscita. È un dettaglio banale solo finché non devi ricostruire cosa è successo su venti endpoint diversi.

Un’altra cosa utile è distinguere tra installazione interattiva e distribuzione remota. In remoto, Reader può fallire per cause che in locale non vedi: policy software restriction, AppLocker, proxy autenticato, user profile non inizializzato o sessione senza contesto amministrativo. Se il pacchetto passa in locale ma fallisce via RMM o GPO, il problema spesso è nel contesto di esecuzione, non nel pacchetto.

Rollback e rimozione pulita

Se l’installazione non va bene o introduce incompatibilità, la rimozione deve essere semplice e tracciabile. Chocolatey ti aiuta anche qui:

choco uninstall adobereader -y

Prima di disinstallare, valuta il blast radius: Reader può essere usato come viewer di PDF per processi interni, firme, manuali o flussi documentali. Se lo rimuovi da una macchina condivisa, verifica che non ci siano dipendenze operative implicite. Il rollback non è solo “togliere il software”, ma assicurarti che il sistema torni allo stato precedente senza rompere attività collaterali.

Se vuoi tornare a una versione precedente, il rollback vero dipende da come gestisci i pacchetti nel tempo. In molti casi il modo più sicuro è reinstallare una versione specifica disponibile nel repository controllato, invece di affidarti all’ultima build pubblicata. Se usi un mirror interno, conserva almeno una versione nota e validata per il restore rapido.

Per verificare la situazione dopo la rimozione, controlla che il pacchetto non sia più presente e che i collegamenti principali siano spariti:

choco list --local-only adobereader

Se la voce compare ancora, non considerare conclusa la disinstallazione: potrebbe esserci stato un cleanup incompleto o un componente secondario rimasto installato fuori dal controllo del pacchetto.

Errori tipici e come leggerli senza perdere tempo

Quando l’installazione fallisce, la tentazione è rilanciare il comando a ripetizione. Meglio fermarsi e leggere il sintomo. Se vedi errori di download, controlla rete, proxy e certificati del sistema. Se vedi errori di installazione già presente, controlla la versione locale e valuta un upgrade invece del reinstall. Se il setup si chiude subito senza messaggi utili, guarda i log di Chocolatey e i log dell’installer del pacchetto, oltre agli eventi di sistema.

In ambienti con hardening, i problemi più comuni sono questi: esecuzione bloccata da policy, path di lavoro non scrivibile, mancanza di privilegi elevati o controllo applicativo che impedisce all’installer di estrarre file temporanei. In tutti questi casi il pacchetto non è “rotto”: è il contesto a essere restrittivo.

Un approccio utile è separare sempre il problema in tre livelli: download del pacchetto, esecuzione dell’installer, avvio dell’applicazione. Se il primo fallisce, è rete o repository. Se il secondo fallisce, è policy o permessi. Se il terzo fallisce, è il comportamento dell’applicazione o una dipendenza locale. Questa distinzione ti fa risparmiare molto più tempo di quanto sembri.

Quando ha senso usare Chocolatey e quando no

Chocolatey ha senso quando vuoi ripetibilità, controllo centralizzato e una storia chiara delle installazioni. È una scelta sensata per macchine amministrate, laboratori, VDI, endpoint gestiti e ambienti in cui il software va portato su più host con lo stesso standard. Se invece parli di una singola workstation non gestita e vuoi solo testare Reader una volta, il valore c’è ma è minore.

La differenza la fa il ciclo di vita. Con il pacchetto gestito, puoi installare, aggiornare, pinning temporaneo e rimozione con una catena prevedibile. Senza, ti ritrovi a inseguire installer manuali, versioni sparse e procedure che nessuno riesce a replicare identiche sei mesi dopo. Per un team tecnico, questa è la vera ragione per usare Chocolatey: non la comodità del singolo comando, ma la riduzione dell’ambiguità operativa.

Se il tuo obiettivo è avere Reader installato in modo pulito, il flusso corretto è semplice: verifica il pacchetto, installa con privilegi adeguati, controlla il risultato, mantieni aggiornato il software, conserva un rollback. Fatto così, l’operazione resta banale anche quando la devi ripetere cento volte.

Assunzione operativa: la macchina è Windows con Chocolatey già funzionante, accesso amministrativo disponibile e repository Chocolatey raggiungibile dalla rete in uso.