Distribuire SysInternals Suite con Intune passo dopo passo

Perché Sysinternals Suite va trattata come un pacchetto, non come “un zip da copiare”

Sysinternals Suite non è un’applicazione classica con installazione guidata e chiavi di registro da inseguire. È un insieme di utilità portabili, spesso usate da admin e supporto per diagnosi rapide su processi, rete, autorun, servizi e storage. Con Intune, l’errore tipico è trattarla come una semplice distribuzione di file: funziona in laboratorio, poi in produzione si rompe tutto sul dettaglio che manca, cioè rilevazione, versioning, percorso di esecuzione e aggiornamento ordinato.

La strada corretta è confezionare la Suite in modo ripetibile, distribuirla come Win32 app, decidere dove posizionarla sul client, come verificare che sia presente e come sostituirla quando Microsoft aggiorna gli strumenti. Se l’obiettivo è dare agli operatori un set coerente di utility senza esporre il parco macchine a modifiche manuali, Intune è adatto. Se invece vuoi solo un archivio condiviso per uso sporadico, stai già scegliendo la soluzione sbagliata: meglio una sorgente controllata, ma non un deployment client-side.

Scelta architetturale: dove mettere i binari e cosa considerare “installato”

Sysinternals Suite è portabile, quindi non richiede installazione nel senso tradizionale. Questo cambia il modello mentale: il vero “install” è la presenza di una cartella ben definita sul disco locale, con i binari eseguibili e una regola di detection che dica a Intune: sì, questa versione è presente e pronta all’uso.

In pratica conviene usare un percorso stabile, per esempio C:\Program Files\Sysinternals oppure C:\Tools\Sysinternals. La prima opzione è più pulita lato governance; la seconda è spesso più semplice se vuoi evitare conflitti con protezioni o policy che guardano con sospetto le directory di sistema. Il punto non è il nome della cartella, ma la sua stabilità. Se la cambi a ogni release, Intune non può rilevare con affidabilità e tu perdi il vantaggio dell’automazione.

La detection migliore, in questo caso, non è un file qualunque ma un indicatore di versione: un file specifico della suite oppure un file manifesto che aggiorni tu nel pacchetto. Così eviti falsi positivi quando resta una vecchia copia della cartella. Se non hai un criterio di versione, rischi di distribuire aggiornamenti senza mai sapere con certezza quale build è realmente in uso.

Preparare il pacchetto Win32 per Intune

Intune gestisce bene i pacchetti Win32, quindi la procedura più robusta è: scaricare la Suite, estrarla in una cartella di staging, aggiungere eventualmente un file di marker e confezionare tutto nel formato richiesto. L’idea è semplice: Intune distribuisce un contenitore, non un link a un archivio esterno che può cambiare o sparire.

Una struttura di staging ragionevole può essere questa:

Staging\Sysinternals\
  PsExec.exe
  ProcessExplorer.exe
  Autoruns.exe
  procexp64.exe
  sysinternals-version.txt

Il file sysinternals-version.txt è utile se vuoi una detection molto esplicita. Dentro puoi mettere, per esempio, il numero di release o una data di build. Non è obbligatorio, ma rende più leggibile il controllo e riduce i casi in cui una detection basata solo sull’esistenza di un file binario diventa ambigua.

Per il packaging, il flusso tipico è questo: prepari la sorgente, converti in .intunewin e poi importi il pacchetto in Intune come app Win32. Il comando di packaging non cambia il contenuto, ma lo rende distribuibile nel canale corretto. Se usi script di automazione, tieni il sorgente in repository e versiona anche il file di detection scelto: è lì che si vede se stai gestendo un rilascio serio o solo spingendo file a mano.

Comando di packaging e struttura minima del deployment

Il tool standard per creare il pacchetto Win32 è IntuneWinAppUtil.exe. Un esempio pratico, da eseguire nella cartella di staging, è questo:

IntuneWinAppUtil.exe -c .\Staging\Sysinternals -s .\Staging\Sysinternals\sysinternals-version.txt -o .\Output

Il parametro -s indica il file sorgente che Intune userà come punto di riferimento del pacchetto. In molti casi si usa un file eseguibile o uno script di installazione; qui può essere anche un file di marker, purché la logica di installazione sia descritta correttamente nella app Win32. Se preferisci una procedura più tradizionale, puoi includere uno script install.cmd o install.ps1 che copia i file nella directory finale e poi fai puntare il packaging a quello.

Un’architettura pulita è questa: un pacchetto contiene i binari, uno script di installazione li copia nella cartella target, uno script di detection verifica presenza e versione, e uno script di uninstall rimuove solo la cartella dedicata. È semplice, ma è proprio la semplicità a ridurre gli errori operativi.

Script di installazione: copia locale, permessi e tracciabilità

Per una suite di utilità portabile, lo script di installazione non deve inventare nulla: crea la directory, copia i file, scrive il marker di versione e termina con un exit code chiaro. Se il contesto è enterprise, evita di appoggiarti a percorsi utente come Downloads o Desktop; il target deve essere comune e stabile per tutti i device gestiti.

@echo off
setlocal
set TARGET=C:\Program Files\Sysinternals
if not exist "%TARGET%" mkdir "%TARGET%"
xcopy /E /I /Y ".\*" "%TARGET%\"
echo 2025.05 > "%TARGET%\sysinternals-version.txt"
exit /b 0

Questo esempio è volutamente lineare. In ambienti più controllati, meglio usare PowerShell con logging esplicito, così puoi tracciare con precisione fallimenti di copia o problemi di permessi. Se il device non consente scrittura in Program Files al contesto scelto, il problema non va mascherato: va corretto il modello di esecuzione o il target path.

Per chi vuole ridurre attrito, un’alternativa è distribuire la Suite in una cartella dedicata sotto C:\ProgramData. È meno elegante dal punto di vista “installazione software”, ma spesso più pratica se il contenuto è usato da più account locali e non vuoi dipendere da privilegi elevati per la sola esecuzione degli strumenti.

Detection rule: il dettaglio che separa un deployment affidabile da uno fragile

La detection rule è il punto in cui molti deployment Intune diventano poco affidabili. Per Sysinternals Suite, la regola minima è verificare un file presente nella directory target e, se possibile, la sua versione. Se il file c’è ma la versione è vecchia, Intune deve considerare la app non conforme alla release attesa e re-distribuire il pacchetto.

Una scelta pratica è usare un file come ProcessExplorer.exe o PsExec.exe e confrontare la versione del file con quella pubblicata nel pacchetto. In alternativa, il file sysinternals-version.txt è più facile da leggere e ti consente una detection molto esplicita. Il rovescio della medaglia è che dipende dal tuo script di installazione: se quello fallisce nel creare il file, la detection fallirà a sua volta. In questo caso, però, è esattamente il comportamento desiderato.

Se usi il portale Intune, la configurazione della detection va impostata nella sezione della app Win32. Il criterio deve essere coerente con il percorso scelto e con il modo in cui la suite viene aggiornata. Non mescolare file diversi per versioni diverse senza una logica precisa, altrimenti rischi di considerare “installata” una release vecchia solo perché un binario secondario non è stato sostituito.

Assegnazione, scope e blast radius

Qui serve disciplina. Sysinternals Suite non è un software che va a tutti per default solo perché “può servire”. In una tenant seria, la distribuzione va assegnata a un gruppo pilota, poi estesa a gruppi operativi ben definiti. Il blast radius è basso se il pacchetto è solo una raccolta di utility, ma non è zero: stai comunque introducendo binari eseguibili su endpoint gestiti e devi sapere chi li vede, chi li avvia e con quali permessi.

Se vuoi limitare l’esposizione, preferisci assegnazioni per gruppi di device o utenti tecnici, non un’assegnazione globale. In Intune, questo ti consente di verificare feedback reali prima di ampliare la distribuzione. La logica è semplice: prima validi su un gruppo piccolo, osservi detection, install success e eventuali blocchi di Defender o SmartScreen, poi allarghi.

Un punto spesso ignorato riguarda l’uso di strumenti come PsExec. Anche se la Suite è legittima e ampiamente usata, alcuni ambienti la trattano con cautela perché certe utility vengono anche abusate in scenari offensivi. Non è un problema da nascondere: va gestito con policy chiare, logging e controllo degli amministratori autorizzati. Se un tool è distribuito, deve esserlo per chi ha un motivo operativo concreto, non per comodità indistinta.

Aggiornamenti: sostituzione del pacchetto e rollback

La Suite viene aggiornata nel tempo, quindi la tua app Intune deve prevedere una strategia di sostituzione. Il metodo più pulito è versionare il pacchetto, aggiornare lo script o il marker di versione, e pubblicare una nuova revisione con detection allineata. Quando la nuova versione è pronta, i device la installeranno solo se la detection della precedente non è più soddisfatta o se la nuova revisione è assegnata come sostitutiva.

Il rollback deve essere banale: tornare al pacchetto precedente o distribuire un uninstall che rimuove la directory dedicata. Non toccare percorsi condivisi con altri strumenti, non lasciare file sparsi in System32, non appoggiarti a shortcut creati a mano. Più il deployment è isolato, più il rollback è affidabile.

Un rollback sensato, in pratica, è questo: disassegni la nuova release, riattivi quella precedente, controlli che la detection torni coerente e verifichi che i binari attesi siano tornati alla versione nota. Se hai usato un file marker, il controllo è immediato; se hai usato la versione del binario, confronti la proprietà file nel target path.

Verifiche dopo il deployment: non basta “installed” nel portale

Il portale Intune che mostra “Installed” non chiude il caso. Devi verificare almeno tre cose: presenza dei file nel path previsto, apertura effettiva del tool da un contesto utente autorizzato e assenza di blocchi nei log di Windows Defender o di AppLocker, se presenti. Se uno di questi punti fallisce, la distribuzione non è davvero utilizzabile, anche se Intune la considera riuscita.

Una verifica rapida lato client può essere fatta così:

dir "C:\Program Files\Sysinternals"
wmic datafile where name="C:\\Program Files\\Sysinternals\\ProcessExplorer.exe" get Version /value

Il primo comando conferma la presenza dei file, il secondo ti restituisce la versione del binario. Se il percorso non coincide con il tuo target, stai già osservando una deviazione da correggere prima di attribuire problemi a Intune. In ambienti più moderni, PowerShell resta più leggibile per interrogare proprietà file e scrivere output strutturato nei log locali.

Errori tipici che fanno perdere tempo

Il primo errore è distribuire l’archivio estratto senza uno script di installazione coerente. L’effetto collaterale è che la detection cerca un file in una cartella che non è mai stata creata. Il secondo è basare tutto sull’esistenza di un file qualsiasi: funziona la prima volta, poi smetti di capire quando hai davvero aggiornato. Il terzo è ignorare il contesto di esecuzione: un pacchetto che scrive in un percorso protetto può fallire se lo script gira nel contesto sbagliato.

Un altro errore comune è dimenticare che la Suite contiene strumenti con comportamenti molto diversi. Alcuni sono innocui da eseguire, altri richiedono attenzione perché interagiscono con processi, servizi o sessioni remote. Distribuire i binari è una cosa; autorizzare l’uso operativo è un’altra. Se il tuo processo di change non distingue le due cose, prima o poi avrai un incidente evitabile.

Modello consigliato in sintesi operativa

Se devi farlo bene e senza complicarti la vita, il modello è questo: pacchetto Win32, directory target stabile, script di installazione che copia i file e scrive una versione, detection basata su file/versione, assegnazione a un gruppo pilota, verifica sul client, poi estensione. È un flusso lineare, facile da mantenere e soprattutto leggibile da chi prenderà in mano il progetto dopo di te.

La parte importante non è “riuscire a distribuire Sysinternals”, ma farlo in modo che tra sei mesi tu sappia ancora dire quale versione è in uso, dove risiede, chi la riceve e come la rimuovi senza lasciare residui. In ambito endpoint management, questa è la differenza tra una soluzione di facciata e una gestione realmente operativa.

Assunzione: il tenant è già configurato per la distribuzione di app Win32 e il target sono endpoint Windows gestiti da Intune.