Come installare PDQ con Winget su Windows 11 e 10

PDQ e winget: il punto vero prima di partire

Se l’obiettivo è installare PDQ su Windows 11 o Windows 10 usando winget, la prima cosa da chiarire è quale prodotto stai gestendo. In ambiente Microsoft il nome “PDQ” viene spesso usato in modo generico, ma nella pratica si parla quasi sempre di PDQ Deploy, PDQ Inventory oppure della combinazione dei due. Il comportamento di installazione, i prerequisiti e la disponibilità nel repository di winget possono cambiare a seconda del pacchetto pubblicato e della versione disponibile in quel momento.

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

Questa non è una di quelle installazioni da cliccare e dimenticare. Se vuoi farla bene, devi verificare tre cose prima ancora del comando: che winget sia presente e aggiornato, che il pacchetto PDQ esista davvero nel repository, e che l’installazione sia compatibile con il contesto in cui lavori, cioè workstation singola, macchina amministrativa o ambiente di test. Il vantaggio di winget è chiaro: installazione ripetibile, meno errori manuali e possibilità di documentare il flusso. Il limite è altrettanto chiaro: se il pacchetto non è disponibile o il publisher non è quello atteso, non devi improvvisare.

Verifica preliminare di winget su Windows 11 e Windows 10

Su Windows 11 winget è normalmente già presente tramite App Installer. Su Windows 10 può esserci, ma non darlo per scontato. Prima di tutto conviene verificare la presenza del comando e la versione effettiva del client.

winget --version

Se il comando risponde con una versione, sei già a posto per il primo controllo. Se invece ottieni un errore tipo comando non riconosciuto, devi installare o aggiornare App Installer dal Microsoft Store oppure tramite il pacchetto ufficiale, a seconda delle policy aziendali. In un contesto gestito, questa è spesso la differenza tra un rollout pulito e un support ticket inutile.

Conviene anche aggiornare l’elenco delle fonti, così eviti di lavorare con metadata vecchi.

winget source update

Se il repository Microsoft non si aggiorna o restituisce errori, il problema non è PDQ ma il client winget, la connettività o eventuali restrizioni proxy. In quel caso non ha senso andare avanti con la fase di installazione: prima risolvi l’accesso al catalogo.

Trova il pacchetto PDQ nel catalogo winget

Il passaggio corretto è cercare il pacchetto esatto, non fidarsi del nome “a memoria”. La query deve restituire l’ID del pacchetto, il publisher e la versione disponibile. Questo è importante perché winget può mostrare più risultati simili, soprattutto se esistono varianti, vecchie entry o pacchetti di terze parti.

winget search PDQ

Nel risultato cerca con attenzione il campo Id. È quello che userai nel comando di installazione. Se trovi più voci, scegli quella con publisher coerente con il prodotto ufficiale. Se non compare nulla, non forzare il nome a caso: significa che il pacchetto non è indicizzato nel repository che stai usando, oppure è stato rinominato o rimosso.

Per evitare equivoci, conviene interrogare direttamente il pacchetto una volta individuato l’ID. Il comando sotto non installa nulla: serve solo a leggere i metadati.

winget show --id <ID_PACCHETTO>

Qui controlli almeno tre elementi: publisher, versione, tipo di installazione. Se il pacchetto è quello giusto, hai già ridotto il rischio di installare software sbagliato o un wrapper non desiderato.

Installazione con winget: comando base e varianti utili

Una volta confermato l’ID, l’installazione base è semplice. Il comando tipico usa l’ID esatto e accetta automaticamente i contratti di licenza del repository se previsto dalla tua policy interna.

winget install --id <ID_PACCHETTO> --exact

In molti casi è utile aggiungere il consenso esplicito ai termini, soprattutto in ambiente tecnico dove vuoi evitare prompt interattivi che bloccano l’automazione.

winget install --id <ID_PACCHETTO> --exact --accept-package-agreements --accept-source-agreements

Se il pacchetto supporta installazione silenziosa, può essere opportuno aggiungere l’opzione dedicata. Non tutti i package manifest espongono gli stessi parametri, quindi va verificato con winget show o nella documentazione del vendor. Evita di presumere che ogni installer MSI o EXE accetti gli stessi switch.

Se stai operando su una macchina dove esiste già una versione precedente, prima controlla lo stato reale. Winget può gestire l’aggiornamento, ma non conviene mescolare upgrade e installazione nuova senza sapere cosa c’è già installato.

winget list | findstr /i PDQ

Se il pacchetto è già presente, valuta se fare un upgrade controllato invece di una reinstallazione. Questo riduce il rischio di toccare configurazioni locali o componenti già registrati nel sistema.

Installazione silenziosa in contesto amministrativo

In molte realtà il punto non è installare PDQ su una singola workstation, ma predisporre una procedura ripetibile. Qui winget è utile se lo tratti come strumento di distribuzione controllata, non come scorciatoia. Un esempio pratico: macchina di test, verifica del pacchetto, poi script di rollout su più endpoint con logging locale.

Se devi integrare l’installazione in un batch o in PowerShell, conviene redirigere l’output in un file di log per tenere traccia di errori e codici di uscita. Questo è particolarmente utile quando il pacchetto fallisce per prerequisiti mancanti, blocchi UAC o policy aziendali.

winget install --id <ID_PACCHETTO> --exact --accept-package-agreements --accept-source-agreements > C:\Temp\pdq-winget-install.log 2>&1

Se lavori in PowerShell, puoi anche verificare il codice di uscita subito dopo l’installazione. Non serve complicarsi la vita: il valore restituito ti dice se il deploy è andato a buon fine o se devi aprire il log.

echo $LASTEXITCODE

Codice zero significa successo. Un valore diverso va interpretato insieme all’output del comando, non a memoria. La differenza tra un’installazione riuscita e una fallita, in questo caso, sta quasi sempre nel dettaglio del log.

Problemi tipici: pacchetto non trovato, fonte non aggiornata, installazione bloccata

Il caso più comune è il pacchetto che non appare in ricerca. Le cause più probabili sono tre: catalogo non aggiornato, pacchetto non presente nella source usata, oppure nome/ID non corrispondente. La verifica rapida è questa: esegui winget source update, poi winget search PDQ, e infine winget show --id ... se trovi un candidato. Se dopo l’update il pacchetto resta invisibile, non insistere con tentativi casuali.

Un altro blocco frequente è il prompt interattivo che ferma il processo. Questo succede quando mancano i consensi o quando l’installer richiede privilegi elevati. In quel caso devi controllare che la sessione sia realmente amministrativa e che la policy locale non stia filtrando l’esecuzione. Su ambienti gestiti, il problema non è winget in sé ma il contesto in cui gira.

Se il download parte ma l’installazione fallisce, il punto da guardare è il log del pacchetto e l’eventuale risposta dell’installer. Alcuni pacchetti falliscono per dipendenze mancanti, altri per versioni di .NET o runtime richiesti. Qui il comando utile non è ripetere l’installazione, ma leggere il messaggio esatto e capire quale prerequisito manca.

Quando il problema è di rete, i sintomi sono diversi: timeout, impossibilità di raggiungere il repository, errore SSL o proxy. In quel caso la verifica minima è provare un download esterno e controllare la connettività verso i servizi Microsoft usati da winget. Se l’ambiente passa da proxy autenticato, assicurati che il client abbia le variabili o le policy corrette. Altrimenti stai solo perdendo tempo.

Controlli post-installazione: non fermarti al messaggio di successo

Un’installazione riuscita non basta. Dopo il deploy devi verificare che l’applicazione sia effettivamente presente, che parta e che la versione corrisponda a quella attesa. Il controllo più semplice è la lista dei pacchetti installati, ma se vuoi essere rigoroso conviene anche verificare il collegamento nel menu Start o il percorso di installazione sul disco.

winget list | findstr /i PDQ

Se il prodotto installato è PDQ Deploy o PDQ Inventory, controlla anche l’avvio dell’applicazione e l’eventuale presenza di errori nei log locali del programma. Il punto non è solo “si apre”, ma “si apre con la versione prevista e senza errori di runtime”. Se il software usa componenti server, verifica anche i servizi correlati e il loro stato in services.msc o via PowerShell.

In scenari dove PDQ viene usato per amministrare altre macchine, ha senso fare un test operativo minimo: apri la console, verifica la connessione alle credenziali configurate e controlla che i target siano raggiungibili. Un’installazione corretta ma una console che non si autentica è un falso positivo classico.

Versioning e aggiornamenti: usare winget senza trasformarlo in roulette

La parte più sottovalutata è la gestione del ciclo di vita. Se installi PDQ con winget oggi, domani potresti ricevere una versione diversa. Questo è utile per patching e standardizzazione, ma va governato. Prima di aggiornare in massa, verifica la release notes del vendor e confronta i cambiamenti con l’ambiente reale. Un tool di gestione endpoint non si aggiorna alla cieca, soprattutto se fa da ponte verso sistemi critici.

Il comando di upgrade segue la stessa logica dell’installazione, ma con la differenza che stai modificando uno stato già esistente. Qui il blast radius è più alto: se qualcosa va storto, puoi impattare configurazioni salvate, estensioni o integrazioni locali. Per questo conviene fare prima un test su una macchina di staging o su un profilo operativo non critico.

winget upgrade --id <ID_PACCHETTO> --exact

Se vuoi documentare il comportamento nel tempo, conserva almeno tre dati: versione iniziale, versione dopo upgrade e output del comando. È la differenza tra una procedura ripetibile e un promemoria vago nel wiki interno.

Quando preferire il download manuale invece di winget

Winget non è sempre la strada migliore. Se il pacchetto non è presente nel catalogo, se l’organizzazione richiede un binario firmato e verificato con hash specifico, oppure se devi allinearti a una release approvata internamente, può avere più senso usare il pacchetto ufficiale del vendor e distribuirlo con un metodo controllato. La scelta non è ideologica: dipende da quanto vuoi standardizzare e da quanto vuoi vincolare la sorgente del software.

In ambienti con auditing stretto, la catena di approvvigionamento conta più della comodità. In quel caso winget resta utile per il test e la validazione, ma la produzione può richiedere un repository interno, un pacchetto mirrorato o un meccanismo di approvazione diverso. L’importante è non confondere velocità con governance.

Procedura pratica consigliata

Se devi fare il lavoro oggi, il flusso più solido è questo: verifica winget, aggiorna la source, cerca il pacchetto PDQ, conferma l’ID, installa con consenso esplicito, poi verifica presenza e versione. È una catena corta, ma ogni anello serve.

1. Verifica il client con winget --version.
2. Aggiorna le fonti con winget source update.
3. Cerca il pacchetto con winget search PDQ.
4. Conferma i metadati con winget show --id <ID_PACCHETTO>.
5. Installa con winget install --id <ID_PACCHETTO> --exact --accept-package-agreements --accept-source-agreements.
6. Verifica con winget list | findstr /i PDQ e con l’avvio dell’applicazione.

Se una delle verifiche fallisce, non passare allo step successivo sperando che “si sistemi da solo”. In un’installazione gestita, il tempo perso a rincorrere sintomi è quasi sempre maggiore del tempo necessario a correggere il punto esatto di rottura.

Nota finale operativa

Assunzione: il pacchetto PDQ che cerchi è disponibile nel catalogo winget del tuo tenant/rete e il sistema ha accesso ai repository Microsoft senza restrizioni anomale. Se questa assunzione non regge, il primo passo non è cambiare comando ma chiudere il gap con winget search PDQ, winget source update e, se serve, con la policy proxy o il catalogo software aziendale.