Distribuire Remote Desktop Client con SCCM e ConfigMgr

Con SCCM e ConfigMgr il punto non è “installare il client”, ma renderlo ripetibile, verificabile e reversibile. Per Remote Desktop Client conviene trattarlo come qualsiasi altro software enterprise: sorgente controllata, installazione silenziosa, detection robusta, requisiti chiari e un piano di aggiornamento che non dipenda dall’operatore di turno.

Il primo errore che vedo spesso è confondere il pacchetto con il risultato. Un’app distribuita bene in ConfigMgr non è solo un setup che parte: è un oggetto applicativo che risponde in modo prevedibile a tre domande semplici. È installato? È la versione giusta? Posso rimuoverlo senza lasciare residui critici? Se una di queste risposte è vaga, prima o poi il deployment diventa rumoroso.

Scelta del metodo: Application, non Package, nella maggior parte dei casi

Per Remote Desktop Client la scelta corretta, quasi sempre, è Application Model. Il vecchio modello Package/Program funziona ancora, ma ti lascia meno controllo su detection, supersedence, requisiti e reporting. Se devi distribuire una versione moderna del client, o vuoi gestire aggiornamenti successivi, l’Application Model ti evita parecchi compromessi.

Il criterio pratico è questo: se vuoi sapere con certezza chi ha quale versione, e se vuoi poter fare rollback o sostituzione con criterio, usa Application. Se hai un installer minimale, senza logica di stato, e il requisito è un deployment lineare su una base omogenea, puoi anche partire da Package, ma è una scorciatoia che paga poco nel medio periodo.

Preparare il sorgente: file, versioni e struttura

Prima di aprire la console, prepara una cartella sorgente pulita e versionata. Il contenuto minimo dovrebbe includere il file di installazione, eventuali dipendenze e un file di log o note operative. Una struttura semplice aiuta anche quando devi fare troubleshooting mesi dopo.

Un esempio pratico:

\SCCM-Sources\RemoteDesktopClient\1.0.0\
  setup.exe
  install.cmd
  uninstall.cmd
  detection-notes.txt

Se il prodotto arriva da MSI, ancora meglio: hai GUID, proprietà pubbliche e una detection più semplice. Se invece è un EXE, devi essere più rigoroso con i parametri silenziosi e con il controllo post-installazione. In entrambi i casi, evita di usare il file originale “così com’è” senza prima testare comportamento, exit code e log.

Parametri silenziosi e comportamento dell’installer

Il cuore della distribuzione è la riga di comando. Remote Desktop Client, come molti software desktop, può cambiare comportamento in base a opzioni del setup, presenza di componenti già installati e contesto utente. Il lavoro non è indovinare il parametro giusto, ma validarlo su una macchina di test con logging attivo.

Per un MSI la base è semplice:

msiexec /i "RemoteDesktopClient.msi" /qn /norestart /l*v C:\Windows\Temp\rdc-install.log

Per un EXE, la sintassi varia. Il punto non è memorizzare una formula universale, ma verificare con il vendor o con una prova controllata quale switch abilita il silent mode. Se il pacchetto non ha logging nativo, aggiungi almeno il wrapper CMD per tracciare l’uscita e il codice di ritorno.

@echo off
start /wait setup.exe /silent /norestart
exit /b %errorlevel%

Qui il controllo vero è il codice di uscita. Se il setup restituisce 0 ma il client non appare, non hai finito: hai solo scoperto che il programma non usa l’errore come segnale affidabile. In quel caso la detection diventa ancora più importante.

Detection method: il punto che decide se il deployment è affidabile

In ConfigMgr la detection method deve essere più precisa di “il file esiste”. Per un client desktop è meglio verificare una combinazione di versione, chiave di registro o presenza del binario corretto. Il file esiste anche quando è vecchio, corrotto o sostituito da una release precedente; la detection deve evitare falsi positivi.

Le opzioni più solide sono tre:

Per esempio, su un client installato correttamente puoi verificare così:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "Remote Desktop Client"

Oppure, se conosci il path del binario principale, controlli versione e presenza:

powershell -NoProfile -Command "(Get-Item 'C:\Program Files\Remote Desktop Client\rdclient.exe').VersionInfo.FileVersion"

Se la detection si basa su un valore fragile, il sintomo tipico è questo: l’app viene reinstallata a ogni ciclo di policy oppure risulta installata quando non lo è. In entrambi i casi il problema non è il client, ma la regola di rilevamento.

Creare l’application in ConfigMgr

Nel console flow, la sequenza è lineare: creare l’application, definire il deployment type, impostare content location, install command, uninstall command, detection e requirements. Se il client è destinato a più versioni di Windows, conviene separare i requisiti dal comando di installazione, così il pacchetto resta leggibile.

La logica operativa è questa:

Se il client deve essere disponibile per l’utente finale senza richiedere privilegi elevati, l’installazione va eseguita in System context. È il caso più comune. Se invece l’app dipende da profilo utente, associazione di file o impostazioni per-user, devi valutare con attenzione se il deployment in system ha senso o se serve una fase separata di post-installazione per il profilo.

Distribution point, boundary group e contenuto

Molti problemi attribuiti al client sono in realtà problemi di distribuzione contenuti. Se il package non è davvero presente sul DP corretto, il client non installa e ConfigMgr ti restituisce un errore che sembra applicativo ma non lo è. Prima di inseguire il setup, verifica che il contenuto sia stato distribuito e che i boundary group siano coerenti con le sedi degli endpoint.

La verifica minima è doppia: lato console e lato client. In console controlla lo stato del content distribution; sul client verifica i log di download e policy. I file log tipici da guardare sono quelli del client ConfigMgr, in particolare i log relativi a download, policy e application enforcement. Se il contenuto non arriva, il problema non è l’installer ma la catena di distribuzione.

Un controllo utile sul client è osservare se l’Application è stata valutata e se il contenuto è stato richiesto. Se non hai visibilità sui log, stai lavorando alla cieca. In quel caso la prima correzione non è cambiare il pacchetto, ma abilitare la diagnostica minima.

Distribuzione verso collection di test e pilot

Non mandare il client in produzione subito. Prima usa una collection di test con pochi endpoint rappresentativi: almeno una macchina pulita, una già con software simile e una macchina che assomigli al profilo più problematico della tua base utenti. Se il client funziona solo sulla macchina “perfetta”, non hai una distribuzione, hai una demo.

Per il pilot, imposta una deadline ragionevole e un comportamento non aggressivo. L’obiettivo è osservare: percentuale di successo, tempi di installazione, eventuali reboot richiesti, impatti su sessioni attive e compatibilità con policy di sicurezza. Se il cliente è usato in orari lavorativi, considera il rischio di interruzione e pianifica la finestra di deployment.

Log da controllare quando qualcosa non torna

La diagnosi seria parte dai log, non dalle supposizioni. Su ConfigMgr, il client registra abbastanza informazioni per capire se il problema è detection, download, installazione o compliance. Se il setup parte ma fallisce, controlla il log dell’installer. Se il deployment non parte proprio, guarda i log del client e il reporting della console.

Quando vuoi ridurre il tempo di diagnosi, fai tre domande in ordine:

Se la risposta alla prima è no, non serve toccare il pacchetto. Se la seconda è no, il problema è di content distribution o boundary. Se la terza è no, il problema è nell’installer o nei parametri. Questa sequenza evita di passare un’ora a inseguire sintomi casuali.

Rollback e supersedence

Ogni distribuzione seria deve prevedere il rollback. In ConfigMgr il modo più pulito è usare supersedence quando la nuova versione sostituisce la precedente, oppure mantenere un deployment separato con uninstall esplicito se devi tornare indietro rapidamente. Il rollback non deve dipendere da una correzione manuale su ogni endpoint.

Se il client nuovo introduce regressioni, la strada corretta è disabilitare il deployment problematico, rimettere in priorità la versione precedente e, se necessario, forzare una valutazione di compliance. Prima di fare qualsiasi modifica, salva la configurazione dell’application o esporta il riferimento del deployment type. Il blast radius è la collection target, non solo la singola macchina.

Un rollback ben gestito deve avere tre elementi: versione precedente ancora disponibile sui DP, detection distinta o supersedence configurata correttamente e comunicazione operativa chiara su chi è stato toccato. Senza questi tre pezzi, il rollback diventa una corsa manuale contro il tempo.

Hardening minimo del pacchetto

Distribuire un Remote Desktop Client significa anche ridurre la superficie di errore. Tieni il pacchetto pulito, evita script con segreti in chiaro e non incorporare credenziali nel deployment. Se il client necessita di configurazioni sensibili, usa meccanismi nativi di policy o storage protetto, non variabili lasciate in log o in file CMD.

Dal punto di vista operativo, conviene documentare almeno questi elementi:

Questo non è burocratese. È il materiale minimo per non perdere contesto quando il pacchetto viene rivisto da un altro admin tra sei mesi.

Esempio di flusso operativo completo

Un flusso solido per distribuire Remote Desktop Client con SCCM e ConfigMgr può essere sintetizzato così:

Se uno di questi passaggi non è ripetibile, il deployment non è ancora pronto. Il vantaggio di ConfigMgr è proprio questo: ti obbliga a formalizzare ciò che altrimenti resterebbe implicito. E nel software desktop, ciò che resta implicito prima o poi si rompe.

Checklist finale prima del rilascio

Prima di andare in produzione, verifica che:

Se vuoi un criterio semplice per capire se il lavoro è fatto bene, usa questo: un secondo admin, leggendo solo la documentazione del pacchetto e guardando la console, deve poter capire cosa succede senza aprire ticket interni. Se non ci riesce, la distribuzione è ancora troppo fragile.

Assunzione: il client sia distribuito in ambiente Windows gestito da ConfigMgr con endpoint domain-joined e accesso ai distribution point già configurato.