Distribuire WinSCP con Intune: guida passo passo

Se devi portare WinSCP su un parco Windows gestito con Intune, la strada più lineare è trattarlo come un’app Win32: pacchetto .intunewin, installazione silenziosa, regole di detection sensate e disinstallazione ripetibile. Il punto non è solo “farlo installare”, ma evitare falsi positivi, conflitti tra versioni e ticket inutili quando l’agente risulta installato ma l’utente non lo trova nel punto atteso.

Perché WinSCP con Intune conviene gestirlo come app Win32

WinSCP è un caso tipico da gestione centralizzata: utility molto usata, aggiornamenti frequenti, necessità di controllo sulle impostazioni e, spesso, richiesta di distribuirla solo a gruppi specifici. Se la carichi come semplice MSI dove possibile, perdi parte del controllo operativo che Intune offre per le app Win32: detection personalizzata, comandi di installazione e rimozione, requirement rules e targeting più preciso.

La scelta Win32 è utile anche quando vuoi standardizzare il comportamento. Non sempre il pacchetto ufficiale esposto dal vendor coincide con il formato più comodo per il tuo processo: a volte hai un EXE, altre un MSI, altre ancora vuoi incapsulare un installer con parametri specifici. Intune, con il formato .intunewin, permette di mettere ordine senza complicare la vita agli endpoint.

Prima di partire: cosa verificare sul pacchetto WinSCP

Prima di costruire il deployment, conviene fissare tre punti: quale installer usi, quali opzioni vuoi applicare e come riconosci in modo affidabile che l’app è presente. Con WinSCP questo è importante perché il nome del prodotto, il percorso di installazione e la presenza di componenti a 32 o 64 bit possono cambiare a seconda della versione e del tipo di installazione.

Il flusso corretto è: scaricare l’installer ufficiale, testare a mano l’installazione silenziosa su una macchina pilota, poi impacchettare. Saltare il test iniziale è il modo più rapido per scoprire troppo tardi che il comando di setup non è davvero silent o che la detection non aggancia il prodotto giusto.

Se hai dubbi sul formato disponibile, chiudi il gap controllando la pagina di download del vendor e il comportamento dell’installer con un test locale. L’obiettivo è ottenere un comando verificabile, non fidarsi di parametri presi a memoria.

Installazione silenziosa: il primo test va fatto fuori da Intune

Prima di toccare Intune, testa il setup in locale con privilegi amministrativi. In questo modo separi i problemi dell’installer dai problemi di distribuzione. Se l’installer è MSI, il riferimento classico resta msiexec; se è EXE, dipende dal vendor e dal pacchetto specifico.

Un esempio di verifica utile è questo: avvii l’installer con il parametro silent previsto dal produttore, controlli che non apra finestre interattive e poi verifichi la presenza del software nel sistema. Se il comando restituisce 0 ma non trovi nulla sul disco o nel registro, il problema non è Intune ma il pacchetto o i parametri.

msiexec /i WinSCP-x64.msi /qn /norestart

Se usi un EXE, il comando esatto dipende dal pacchetto scaricato. Qui non conviene inventare switch “magici”: apri il log del setup, leggi la documentazione del vendor o l’help del pacchetto e ricava i parametri supportati. Il punto operativo è semplice: prima dimostri che l’installazione silenziosa funziona in locale, poi la porti in Intune.

Preparare il contenuto da caricare in Intune

Per le app Win32, Intune richiede il wrapper .intunewin. La logica è sempre la stessa: metti installer e file necessari in una cartella di staging, esegui il tool di preparazione, poi carichi il pacchetto risultante nel portale. Tieni il contenuto minimale: meno file metti dentro, meno rischi hai di versioni duplicate o dipendenze dimenticate.

Una struttura ordinata può essere questa:

C:\IntuneSource\WinSCP\
  WinSCP-x64.msi
  install.ps1
  uninstall.ps1

Il pacchetto di preparazione si esegue con lo strumento ufficiale Microsoft. Il comando esatto può variare in base a dove hai salvato l’utility, ma la logica è sempre: source folder, file di setup, output folder. Se il pacchetto non si genera, la prima cosa da controllare è il path di input e la presenza del file indicato come “setup file”.

IntuneWinAppUtil.exe -c C:\IntuneSource\WinSCP -s WinSCP-x64.msi -o C:\IntuneOutput

Creare l’app Win32 nel portale Intune

Nel portale di Intune vai su Apps, poi Windows, quindi Add e scegli Win32 app. Qui carichi il file .intunewin creato prima. La parte importante non è il click iniziale, ma la coerenza tra install command, uninstall command e detection rule.

Nel campo di installazione inserisci il comando testato sul client. Se stai distribuendo WinSCP da MSI, il pattern tipico è msiexec con installazione silenziosa. Se hai creato uno script wrapper, il comando può puntare a PowerShell o a un batch che normalizza eventuali controlli pre/post.

Per esempio, se vuoi usare uno script PowerShell come orchestratore, il comando di installazione può essere simile a questo:

powershell.exe -ExecutionPolicy Bypass -File .\install.ps1

La disinstallazione va trattata con la stessa disciplina. Se il pacchetto è MSI, usa il ProductCode o il comando di rimozione previsto. Se usi uno script, assicurati che sia idempotente: deve fallire in modo pulito se il prodotto non c’è più, non deve lasciare residui e non deve richiedere conferme.

Detection rule: il punto dove molti deployment si rompono

La detection rule è la parte che decide se Intune considera l’app installata o no. Se sbagli qui, ottieni due problemi opposti: installazioni ripetute all’infinito oppure app distribuite ma mai riconosciute. Per WinSCP, la detection più robusta è quella basata su registro o file version, non su un semplice controllo del nome nel menu Start.

Una verifica ragionevole è cercare la chiave di uninstall nel registro. Su sistemi 64 bit e 32 bit, il punto dove trovare il prodotto può cambiare, quindi va testato sul client reale. Se il setup è MSI, spesso conviene usare la detection per ProductCode o per chiave di uninstall. Se il setup è EXE, usa un path file o una chiave di registro stabile, meglio se legata alla versione.

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall /s | findstr /i winscp

Se trovi una voce coerente, usa quel riferimento. Se non compare, non forzare una detection fragile: apri il registro, individua la chiave corretta e poi definisci il criterio in Intune. È meglio perdere cinque minuti in più qui che ricevere ticket ogni volta che un device viene considerato “Not installed”.

Rilevamento per file, registro o MSI: quando scegliere cosa

La detection per MSI è la più pulita quando il pacchetto è davvero un MSI e il ProductCode è stabile. È la scelta da preferire se vuoi ridurre ambiguità. La detection per file funziona bene quando sai che un eseguibile o una DLL si trova sempre in un path preciso e la versione del file cambia in modo coerente con il rilascio. La detection per registro è utile quando il vendor scrive una chiave affidabile con versione o install path.

Per WinSCP, il criterio migliore dipende dal pacchetto scelto. Se distribuisci una build MSI, parti dal registro di uninstall. Se distribuisci un EXE o una struttura portabile, verifica il path reale del binario e il file version. Non usare il nome del collegamento desktop come prova di installazione: è un dettaglio cosmetico, non un indicatore di stato.

Requirement rules: evitare di installare dove non serve

Le requirement rules servono a evitare che l’app venga offerta a macchine incompatibili o fuori perimetro. In un contesto enterprise, WinSCP può essere richiesto solo su device aziendali, solo su Windows 10/11, solo su macchine con spazio disco sufficiente o solo a gruppi di utenti specifici. La compatibilità minima va definita prima di pubblicare l’app in massa.

Se vuoi limitare la distribuzione, usa assegnazioni a gruppi Azure AD e, se necessario, requirement script. Il vantaggio è duplice: riduci il rumore e hai una policy più leggibile in audit. Se un device non riceve l’app, la diagnosi parte dalle assegnazioni e poi passa alle rule di requisito, non dal pacchetto in sé.

Esperienza utente: dove finisce WinSCP dopo l’installazione

Distribuire un client SFTP non significa solo installarlo. Devi anche sapere dove l’utente lo troverà, se compare nel menu Start, se crea collegamenti desktop e se le impostazioni iniziali sono coerenti con il profilo aziendale. Se il tuo obiettivo è minimizzare il supporto, conviene standardizzare anche i parametri iniziali o distribuire un file di configurazione controllato.

Qui serve prudenza: non inserire segreti in chiaro nei pacchetti o nelle configurazioni. Se devi preconfigurare accessi, usa meccanismi aziendali appropriati e separa le credenziali dalla distribuzione dell’app. La regola operativa è semplice: il pacchetto distribuisce il client, non le password.

Disinstallazione e rollback: il piano che ti salva quando qualcosa va storto

Ogni distribuzione seria deve avere un rollback. Se WinSCP crea conflitti con una versione precedente, se una detection è sbagliata o se il gruppo target non è quello giusto, devi poter rimuovere il pacchetto senza lasciare residui. In Intune questo significa avere un uninstall command verificato e, idealmente, un gruppo di test separato prima del rollout ampio.

Prima di passare in produzione, prova tre casi: installazione pulita, reinstallazione su macchina già presente e disinstallazione. Se uno dei tre fallisce, non pubblicare ancora. Il controllo va fatto su un endpoint pilota, non sulla prima macchina dell’utente finale.

msiexec /x {PRODUCT-CODE} /qn /norestart

Se usi uno script di rimozione, verifica che restituisca un exit code coerente con Intune. Un errore di exit code può far risultare fallita una disinstallazione che in realtà è avvenuta correttamente, oppure il contrario. Anche qui conta la verifica pratica, non la sola intenzione del comando.

Controlli finali dopo il deployment

Dopo l’assegnazione, controlla almeno tre cose: stato di installazione nel portale Intune, presenza reale dell’app sul client e riscontro nei log dell’endpoint. Se il portale dice “Installed” ma l’utente non trova WinSCP, il problema è quasi sempre nella detection o in un pacchetto che non ha creato l’entry attesa.

I log utili sono quelli del client Intune e quelli del sistema Windows, oltre ai log dell’installer se il pacchetto li genera. La verifica minima è: il device riceve la policy, scarica il contenuto, esegue il comando e chiude con successo. Se uno di questi passaggi manca, hai già il punto dove intervenire.

In una distribuzione ben fatta, il risultato non è solo “WinSCP installato”, ma “WinSCP installato, riconosciuto, disinstallabile e tracciato”. È questa la differenza tra un test riuscito e una gestione operativa che regge nel tempo.

Checklist pratica da usare prima del rollout

Prima di assegnare l’app a gruppi ampi, verifica questa sequenza:

• installer testato in locale con esito pulito;
• pacchetto .intunewin creato senza errori;
• install command coerente con il test locale;
• detection rule verificata su un client reale;
• uninstall command provato e con rollback disponibile;
• targeting limitato a un gruppo pilota prima della diffusione.

Se uno di questi punti non è verificabile, non andare oltre. Il gap va chiuso prima con un comando, un path o un controllo di registro, non con supposizioni. È il modo più semplice per evitare che una distribuzione apparentemente banale diventi una coda di problemi di supporto.

Assunzione operativa: il pacchetto distribuito è un installer standard di WinSCP testato in ambiente Windows moderno e gestito tramite Intune come app Win32.