Come installare software da remoto su un altro computer

Q: Come posso installare software da remoto su un computer appartenente a un gruppo di lavoro?

Imposta LocalAccountTokenFilterPolicy su 1 sulla destinazione, quindi usa PsExec con -h oppure PowerShell con la macchina aggiunta a TrustedHosts. I computer in un gruppo di lavoro non hanno un dominio che fornisca token completi, quindi sono necessari sia il valore del Registro di sistema sia l’autenticazione NTLM con una credenziale locale esplicita.

Per installare da remoto un software su un altro computer, connettiti tramite Desktop remoto ed esegui il programma di installazione come se fossi alla tastiera, oppure distribuisci un’installazione silenziosa dalla riga di comando con PowerShell Invoke-Command o PsExec e msiexec /qn. La riga di comando è dove la maggior parte delle persone incappa in Access is denied anche con la password di amministratore corretta, perché Windows fornisce agli account amministratore locali ordinari un token filtrato durante un accesso di rete. Desktop remoto evita il filtro perché è un accesso interattivo, e un account di dominio appartenente al dominio della destinazione ottiene comunque un token completo.

Per un normale account amministratore locale, la correzione più rapida è un valore del Registro di sistema sulla destinazione: imposta LocalAccountTokenFilterPolicy su 1 in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, quindi esegui il programma di installazione in modalità silenziosa e acquisiscine il codice di uscita. Questa guida copre ciascun metodo con comandi testati, uno script per più computer e una soluzione per ogni errore comune, dagli errori di PSEXESVC a winget 0x8a15000f.

Se preferisci evitare del tutto il rompicapo del token, HelpWire è un software di supporto remoto che si connette a una macchina all’altro capo, e puoi richiedere i privilegi di amministratore durante la sessione. Esegui il programma di installazione all’interno di un vero desktop interattivo, così il prompt di elevazione si comporta come farebbe alla tastiera.

Indice dei contenuti

La causa sono le restrizioni remote di UAC, dette anche filtraggio del token. Quando un account locale che appartiene al gruppo Amministratori effettua l’accesso tramite la rete, l’Autorità di sicurezza locale gli assegna un token filtrato con un livello di integrità medio, quindi il gruppo Amministratori si trova in uno stato di sola negazione e le azioni privilegiate vengono bloccate. L’accesso di rete, ossia WinRM, PsExec, WMI o una copia su C$, produce un token filtrato per gli amministratori locali.

Due dettagli determinano se sei colpito. Un account di dominio appartenente al dominio stesso della destinazione, nel gruppo locale Amministratori, è esente e riceve un token completo, motivo per cui negli ambienti di dominio questo si verifica raramente. L’Administrator integrato con RID 500 è anch’esso un caso speciale e non viene filtrato a meno che FilterAdministratorToken non sia abilitato. Tutti gli altri, cioè i normali account di amministratore locale e gli account di un dominio diverso, ricevono il token filtrato, sia che la destinazione sia in un gruppo di lavoro sia che sia membro di un dominio. Questo solo fatto spiega perché Access is denied da PsExec, net use, una copia su C$, oltre al token filtrato e non amministrativo con cui ti ritrovi tramite Invoke-Command.

La seconda causa principale è la sessione non interattiva. Un comando remoto viene eseguito dove nessuno può fare clic, quindi un programma di installazione che si aspetta una finestra rimane bloccato in attesa di un pulsante oppure fallisce del tutto.

Il modo più rapido per installare software da remoto è adeguare il metodo al tuo ambiente, perché ciascuno si comporta in modo diverso con i token di amministratore, i gruppi di lavoro e Windows Home. Questa tabella chiarisce quella scelta prima che tu esegua anche solo un comando. Inclusi qui sono i Criteri di gruppo, poiché sono riservati ai domini ed è utile decidere presto se includerli o escluderli.

Metodo	Comportamento del token di amministratore	Funziona in un gruppo di lavoro	Host Windows Home	Interrompe l’utente	Tramite Internet
RDP	Token completo, interattivo	Sì	`No host`	Sì, li disconnette	Con VPN
Remoting di PowerShell	Filtrato per gli amministratori locali	Con `TrustedHosts`	Sì	No	Raramente
`cmd` + `PsExec`	Filtrato. Usare `-h`.	Con correzione del Registro	Sì	No	No
winget	Non funziona con `WinRM`	Solo esecuzione in locale	Sì	No	No
Criteri di gruppo	SYSTEM, assegnati al computer	`No`, solo dominio	Solo dominio	No	No
HelpWire	Completo, con elevazione interattiva	Sì	Sì	No	Sì

Una cosa determina ogni metodo da riga di comando riportato di seguito: l’account con cui ti connetti. Un account di dominio del dominio della destinazione stessa, appartenente al gruppo Administrators, ottiene un token completo e funziona così com’è. Un normale account amministratore locale ottiene il token filtrato, quindi le sue copie su C$ e le chiamate PsExec restituiscono Access is denied, e il remoting di PowerShell o rifiuta la sessione o la esegue senza diritti di amministratore, finché non imposti LocalAccountTokenFilterPolicy a 1 sulla destinazione, come trattato nella sezione delle correzioni. RDP è l’eccezione, perché è un accesso interattivo piuttosto che di rete.

Desktop remoto è il modo più pulito per installare software in remoto su un altro computer, perché è una sessione interattiva che viene eseguita con un token di amministratore completo dopo aver confermato il prompt UAC. Connettiti, quindi installa come se fossi seduto davanti al computer.

Sul computer di destinazione, premi Win + R, digita SystemPropertiesRemote, e abilita Consenti connessioni remote a questo computer.
Sul tuo computer, apri Connessione Desktop remoto (mstsc.exe), inserisci il nome o l’IP di destinazione e accedi con un account che sia un amministratore locale su quella macchina.
Copia il programma di installazione tramite la sessione, oppure mappa un’unità locale in Risorse locali così da potervi accedere.
Esegui il programma di installazione. Quando compare la richiesta del Controllo dell’account utente (UAC), approvala all’interno della finestra RDP, quindi completa la procedura guidata.

È bene conoscerne i limiti prima di farvi affidamento. Le edizioni Windows Home non possono in alcun modo ospitare una sessione RDP. Possono solo eseguire il client. Nei sistemi Windows client conta una singola console, quindi la connessione disconnette l’utente connesso alla macchina. E un utente standard, privo di credenziali amministrative sulla macchina remota, non può comunque approvare il prompt, il che rimanda ai metodi da riga di comando riportati di seguito.

Per installare software da remoto usando PowerShell, ci si affida a Invoke-Command, ma ci sono due trappole in cui cadono quasi tutti. La sessione remota è non interattiva, quindi il programma di installazione deve essere completamente silenzioso, e la sessione può chiudersi prima che un programma di installazione che restituisce subito il controllo abbia finito, il che annulla l’installazione. Il ben noto approfondimento sulle installazioni remote di Kevin Marquette documenta entrambe, e la soluzione al secondo problema è Start-Process -Wait.

Sulla destinazione, abilita il remoting una volta. Da una finestra di PowerShell con privilegi elevati, esegui Enable-PSRemoting -Force.
Copia l’installer nella destinazione in modo che la sessione non debba mai accedere a un percorso di rete:
Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi"
Eseguilo in modalità silenziosa e attendi che finisca:
Invoke-Command -ComputerName PC01 -ScriptBlock {

Start-Process msiexec.exe -ArgumentList "/i C:\Windows\Temp\app.msi /qn /norestart" -Wait

}

Se ometti -Wait, il blocco di script può terminare mentre il programma di installazione sta ancora copiando i file e la chiusura della sessione interrompe l’installazione a metà scrittura. Se il programma di installazione mostra una finestra, si blocca, perché in una sessione non interattiva non c’è nulla che possa fare clic su di essa.

Uno script PowerShell itera su un elenco di computer, copia il programma di installazione su ciascuna macchina tramite la propria sessione, lo esegue e registra il codice di uscita, così sai cosa è stato installato su ciascuna macchina. Questo gestisce il problema del double-hop pre-copiando invece di accedere a una condivisione dall’interno della sessione.

$computers = Get-Content "C:\Installers\computers.txt" $source = "C:\Installers\app.msi" $results = @() foreach ($pc in $computers) { try { $s = New-PSSession -ComputerName $pc -ErrorAction Stop Copy-Item -Path $source -ToSession $s -Destination "C:\Windows\Temp\app.msi" $code = Invoke-Command -Session $s -ScriptBlock { $p = Start-Process msiexec.exe -ArgumentList "/i C:\Windows\Temp\app.msi /qn /norestart" -Wait -PassThru $p.ExitCode } $ok = @(0, 3010, 1641) -contains $code $results += [pscustomobject]@{ Computer = $pc; ExitCode = $code; Success = $ok } Remove-PSSession $s } catch { $results += [pscustomobject]@{ Computer = $pc; ExitCode = "N/D"; Success = $false } } } $results | Export-Csv "C:\Installers\install-report.csv" -NoTypeInformation

Considera 3010 e 1641 come successi, non come errori. Entrambi significano che l’installazione è riuscita: 3010 indica che è richiesto un riavvio per completare, e 1641 indica che il programma di installazione ha già avviato il riavvio. Molti script grezzi segnalano erroneamente questi come errori. Nota che Copy-Item -ToSession esegue una sessione alla volta, quindi la fase di copia è per macchina anche se Invoke-Command può diramarsi.

Evita la scorciatoia CredSSP che troverai suggerita per il double hop. La community se n’è allontanata perché memorizza in cache le tue credenziali di amministratore sull’host remoto, dove un aggressore può sottrarle. La pre-copia, come sopra, aggira completamente il problema.

Codici di uscita comuni di msiexec da verificare:

Codice di uscita	Significato
`0`	Operazione riuscita
`1603`	Errore fatale durante l’installazione
`1618`	Un’altra installazione è già in corso
`1619`	Impossibile aprire il pacchetto di installazione
`1638`	Un’altra versione del prodotto è già installata
`1641`	Operazione riuscita, riavvio avviato
`3010`	Operazione riuscita, riavvio richiesto

Per installare software da remoto utilizzando cmd, hai tre strade: PsExec, winget e il più vecchio comando WMIC, anche se solo i primi due sono affidabili sulle versioni attuali di Windows. Ognuno interagisce con il token di amministratore in modo diverso, quindi i flag contano più dello strumento.

Scarica PsExec da Microsoft Sysinternals ed estrailo. Apri cmd come amministratore, poiché PsExec installa un servizio (PSEXESVC) a ogni esecuzione, e ciò richiede privilegi elevati.
Copia il file MSI nella condivisione amministrativa del computer di destinazione:
copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\
Esegui l’installazione silenziosa con un token con privilegi elevati. Il flag -h è quello importante. Esegue il processo con il token elevato dell’account:
psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart

Evita il flag -i che le guide più vecchie copiano in giro. Obbliga l’interazione con il desktop, il che contrasta un’installazione silenziosa e può causare proprio i blocchi che stai cercando di evitare. Il comportamento di -h e l’elenco completo degli switch provengono direttamente dal riferimento PsExec. Se vedi Couldn't install PSEXESVC service: Access Denied, la causa abituale è un prompt locale non elevato, anche se una condivisione ADMIN$ bloccata o il token filtrato sulla destinazione producono lo stesso effetto. Se vedi Couldn't access <PC>: Access is denied su una macchina in workgroup, si tratta del filtraggio del token descritto nella sezione delle correzioni.

winget installa applicazioni localmente da cmd con una sola riga ed è il sostituto moderno degli strumenti legacy:

winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements

Eseguirlo da remoto è dove iniziano i problemi. In una sessione WinRM, winget spesso genera A specified logon session does not exist o segnala che winget non è riconosciuto, perché viene eseguito come app pacchettizzata che si aspetta un accesso interattivo. Un problema di lunga data di winget-cli tiene traccia di questo, e una segnalazione correlata mostra che una prima chiamata remota fallisce con 0x8a15000f finché un amministratore non esegue qualsiasi comando winget localmente su quella macchina almeno una volta. Su una macchina nuova, incontrerai anche 0x8a150042, un errore di prompt di input, a meno che non passi --accept-source-agreements. winget inoltre non supporta ufficialmente l’account SYSTEM e su Windows Server è supportato solo dal 2025 in poi, escludendo Server Core, con 2019 e 2022 non supportati ed esperimentali.

Il vecchio trucco wmic product call install non funziona più su Windows 11 24H2 e versioni successive. Secondo l’avviso di rimozione di WMIC di Microsoft, l’utilità è stata disabilitata per impostazione predefinita in Windows 11 23H2 e 24H2, rimossa durante l’aggiornamento a 25H2 e tolta da 24H2 e 25H2 con l’aggiornamento di anteprima di agosto 2026, con 26H1 distribuito senza di essa e senza alcuna Feature on Demand per ripristinarla. In tali versioni, gli script che richiamano wmic.exe restituiscono 'wmic' is not recognized. Microsoft ha limitato la rimozione a Windows 11, quindi WMIC è ancora incluso in Windows 10 e Windows Server per ora, ma l’indicazione ovunque è di passare a Get-CimInstance e Invoke-Command di PowerShell. La guida all’installazione da cmd di HelpWire illustra più nel dettaglio le opzioni della riga di comando.

Supporto degli strumenti da riga di comando per versione di Windows:

Funzionalità	Stato	Note
`WMIC`	Rimosso in `24H2`, `25H2`, `26H1`	Nessuna Funzionalità su richiesta da agosto 2026
`winget`	Win 10 `1809+`, Win 11, Server 2025 (non Core)	Nessun supporto per SYSTEM; Server 2019/2022 sperimentale
Host RDP	Pro, Enterprise, Education	Le edizioni Home eseguono solo il client

Le soluzioni superficiali fanno perdere ore perché trattano il sintomo, non il token filtrato sul lato remoto. Eseguire il tuo cmd come amministratore non cambia nulla, poiché il filtraggio avviene sulla destinazione, non sul tuo computer. Usare runas con un normale account amministratore apre una finestra che ha l’appartenenza al gruppo degli amministratori ma non è elevata, quindi le installazioni falliscono comunque.

Disabilitare completamente l’UAC con EnableLUA impostato a 0 consente l’installazione, ma lascia i diritti di amministratore non controllati e interrompe le app dello Store, motivo per cui Microsoft e la community lo sconsigliano. Nessuna di queste affronta la causa reale; la sezione successiva invece sì.

Inizia dal messaggio di errore, quindi vai alla sua correzione. Ciascuno dei seguenti è stato confermato nella documentazione Microsoft, nelle basi di conoscenza dei fornitori e nei thread della community.

Stringa di errore	Generato da	Causa principale
`Accesso negato`	`PsExec`, `net use`, `C$`	Token amministratore filtrato
`Impossibile installare il servizio PSEXESVC`	`PsExec`	Prompt locale non elevato, oppure destinazione `ADMIN$`/token bloccato
`0x80090322`	`WinRM`	Problema di gruppo di lavoro o SPN
`Accesso negato`	`Invoke-Command` a una condivisione	Doppio salto
`0x8a15000f`	`winget` tramite `WinRM`	Dati di origine mancanti
`1603`	`msiexec`	Errore di installazione fatale

Imposta un valore del Registro di sistema sul computer di destinazione per concedere agli account amministratore locali un token completo tramite la rete. Questa è la soluzione confermata da PDQ, Broadcom e innumerevoli thread di PsExec.

Sul sistema di destinazione, apri Editor del Registro di sistema (regedit) e vai a:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Crea un valore DWORD denominato LocalAccountTokenFilterPolicy e impostalo su 1. Oppure esegui questo da un prompt con privilegi elevati:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Riprova l’installazione. Per ripristinare in seguito, imposta nuovamente il valore su 0, che riattiva il filtraggio UAC remoto.

Non è necessario quando ti connetti con un account di amministratore di dominio dal dominio stesso dell’obiettivo, che già riceve un token completo. Microsoft ha progettato il filtraggio per bloccare gli attacchi di loopback, quindi disattivarlo aumenta la superficie di attacco. Configuralo deliberatamente e ripristinalo quando il lavoro è terminato.

Questo è quasi sempre un problema di elevazione locale, confermato su Microsoft Q&A.

Chiudi il prompt e riapri cmd o PowerShell come amministratore. PsExec installa il suo servizio a ogni esecuzione e non può farlo da un prompt standard.
Se continua a fallire, un psexecsvc.exe obsoleto può rimanere bloccato sulla destinazione. Controlla %windir% sulla macchina remota e rimuovi l’eventuale copia residua, quindi riprova.
Conferma che la condivisione ADMIN$ della destinazione sia raggiungibile e che la Condivisione file e stampanti (SMB su TCP 445) sia consentita tramite il suo firewall, poiché PsExec copia lì il servizio PSEXESVC per eseguirlo.

Il remoting di PowerShell in un gruppo di lavoro fallisce perché Kerberos non può autenticare un account locale, quindi aggiungi la destinazione a TrustedHosts e forzi NTLM. Il testo stesso dell’errore di WinRM indica il percorso di TrustedHosts.

Sul tuo computer, da una PowerShell con privilegi elevati, aggiungi la destinazione:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate
Connettiti con una credenziale locale esplicita in modo che Negotiate ripieghi su NTLM:
$cred = Get-Credential
Invoke-Command -ComputerName PC01 -Credential $cred -ScriptBlock { hostname }
Se l’errore persiste su un FQDN di dominio anziché in un gruppo di lavoro, si tratta di un problema di SPN. Microsoft KB 4549715 tratta le soluzioni alternative -IncludePortInSPN e spn_prefix.

Quando la sessione remota raggiunge un percorso UNC, non può autenticarsi, pre-copiare il file o ri-autenticarsi all’interno del blocco di script.

Preferibile: copiare prima il programma di installazione sulla destinazione, come nello script multi-computer, in modo che la sessione utilizzi solo un percorso locale.
Oppure mappa un’unità con una nuova credenziale all’interno della sessione. La chiamata New-PSDrive autentica una connessione al file server e l’avvio diretto tramite UNC qui sotto riutilizza tale connessione, quindi la credenziale viene mantenuta anche se il comando non fa mai riferimento all’unità mappata:
$cred = Get-Credential

Invoke-Command -ComputerName PC01 -ScriptBlock {

New-PSDrive -Name X -PSProvider FileSystem -Root "\\fileserver\share" -Credential $using:cred | Out-Null

Start-Process "\\fileserver\share\app.exe" -ArgumentList "/silent" -Wait

}

Entrambi gli errori derivano dal fatto che winget si aspetta un accesso interattivo di cui non dispone. La soluzione alternativa è documentata nel tracker di winget-cli.

Accedi alla destinazione una volta come amministratore ed esegui qualsiasi comando winget, ad esempio, winget list. Questo inizializza l’origine e azzera 0x8a15000f nelle chiamate remote successive.
Specifica sempre i flag di accettazione delle condizioni per evitare il 0x8a150042 prompt di input alla prima esecuzione:
winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements
Non fare affidamento su winget nel contesto SYSTEM. Il pacchetto App Installer che fornisce winget è registrato per utente, e tale registrazione di norma non è presente per l’account SYSTEM, quindi anche richiamando il percorso completo in C:\Program Files\WindowsApps spesso l’installazione comunque non riesce. Per la distribuzione nel contesto SYSTEM, usa msiexec tramite PsExec o, in alternativa, uno strumento per i pacchetti.

Il codice di uscita 1603 è un errore fatale generico, quindi la soluzione è sempre leggere il log dettagliato invece di indovinare. La risoluzione dei problemi di Microsoft sul 1603 indica lo stesso approccio.

Esegui nuovamente con registrazione dettagliata in un percorso scrivibile sul sistema di destinazione:
msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log"
Apri il log e cerca return value 3, che si trova subito dopo l’azione non riuscita. Le cause più comuni sono lo spazio su disco insufficiente, un’incoerenza tra proprietà a livello utente e a livello macchina, oppure un file bloccato.
Se il log non è risolutivo, riproduci l’installazione in modo interattivo sulla macchina di destinazione tramite RDP, dove un programma di installazione con interfaccia grafica può mostrare il vero errore, poiché un avvio nel contesto SYSTEM non ha un desktop su cui visualizzarlo.

HelpWire è un software di accesso remoto che ti consente di eseguire un programma di installazione su una macchina remota all’interno di una sessione interattiva in tempo reale dall’app (Operatore) sul tuo dispositivo. Ti connetti tramite un link e richiedi i diritti di amministratore sul lato remoto. Una volta concessi i diritti, l’app dell’utente remoto (Cliente) si riavvia così puoi eseguire direttamente i programmi di installazione.

Avvia una sessione e connettiti alla workstation remota. Consulta la guida ai privilegi di amministratore di HelpWire per la procedura completa.
Fai clic su Richiedi accesso amministratore nella barra degli strumenti dell’app Operator.
Il cliente fa clic su Concedi l’accesso, quindi su Sì nella richiesta di cambio dispositivo. L’app Client si riavvia con diritti di amministratore e la connessione viene ripristinata.
Con Accesso amministratore concesso visualizzato sulla barra degli strumenti, esegui il tuo programma di installazione tramite il desktop remoto come amministratore con privilegi completi.

Se disponi delle credenziali, usa il menu a discesa accanto a Richiedi accesso amministratore e scegli Amministratore con credenziali, quindi inserisci il nome utente e la password dell’account amministratore. L’utente remoto può anche elevare i privilegi dalla propria parte con Riavvia come amministratore nell’app Client.

Puoi inserire un programma di installazione direttamente nella sessione senza problemi di copia e incolla RDP, oppure trascinarlo sulla finestra di Operator. Quando una correzione richiede interventi successivi, l’accesso non presidiato ti consente di riconnetterti in seguito alla stessa macchina accesa senza la presenza dell’utente remoto.

L’elevazione dei privilegi avviene all’interno di un vero desktop interattivo, quindi i programmi di installazione e i relativi prompt UAC si comportano normalmente, senza modifiche al registro sul sistema di destinazione.

L’utente remoto mantiene il controllo. Ogni richiesta amministrativa richiede la sua approvazione e può revocare l’accesso in qualsiasi momento.

Dipende a chi mancano i diritti. Un’installazione per macchina che scrive in Program Files o in HKLM richiede diritti di amministratore sulla destinazione, quindi se sei tu ad avviarla fornisci le credenziali di amministratore oppure esegui l’elevazione tramite uno strumento che presenta un prompt all’utente. L’utente finale sulla destinazione non ha bisogno di diritti di amministratore quando un amministratore ha preconfigurato un meccanismo di distribuzione: le installazioni software assegnate al computer tramite Group Policy installano le app per macchina nel contesto SYSTEM all’avvio, senza alcuna elevazione da parte dell’utente. Anche le app per utente, come Google Chrome, si installano nel profilo utente senza diritti di amministratore.

Imposta LocalAccountTokenFilterPolicy su 1 sulla destinazione, quindi usa PsExec con -h oppure PowerShell con la macchina aggiunta a TrustedHosts. I computer in un gruppo di lavoro non hanno un dominio che fornisca token completi, quindi sono necessari sia il valore del Registro di sistema sia l’autenticazione NTLM con una credenziale locale esplicita.

Dipende dal metodo. Una connessione RDP disconnette la persona alla console, bloccando la sua sessione mentre i suoi programmi continuano a essere in esecuzione, mentre PsExec, il remoting di PowerShell e un’installazione silenziosa /qn vengono eseguiti in background senza disturbare l’utente. Anche uno strumento di assistenza remota che condivide il desktop attivo lascia l’utente al suo posto, il che è importante quando installi su una macchina di qualcuno nel bel mezzo della giornata lavorativa.

Controlla il codice di uscita dell’installer, non solo se il comando è terminato. Un 0 indica esito positivo, 3010 e 1641 indicano esito positivo con riavvio, e 1603 indica un errore fatale. Il codice di uscita è il segnale affidabile, quindi acquisiscilo con -PassThru in PowerShell. La maggior parte delle app MSI ed EXE che registrano un programma di disinstallazione compaiono anche sotto le chiavi di disinstallazione in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, nel relativo ramo WOW6432Node per le app a 32 bit, e in HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall per le installazioni per utente, anche se non tutte le app vi scrivono una voce. Le app MSIX e le altre pacchettizzate come AppX compaiono invece tramite Get-AppxPackage, indipendentemente dalla loro origine. Evita Get-CimInstance Win32_Product, poiché elenca solo i prodotti Windows Installer e la relativa query può attivare un lento controllo di consistenza MSI.

Come installare da remoto software su un altro computer

Perché le installazioni remote di software falliscono anche con un account amministratore

Come installare software da remoto: i tuoi metodi a confronto