Come abilitare e configurare l'Assistenza Remota in SCCM

In SCCM l’Assistenza Remota non si “accende” con un singolo switch e basta: va preparata la catena completa, dal sito alla client settings, fino ai permessi operativi e alla rete. Se salti un passaggio, ti ritrovi con richieste che partono ma non si connettono, oppure con sessioni che si aprono senza controllo reale su chi può assistere chi.

Il punto da tenere fermo è questo: SCCM non sostituisce il sistema di assistenza remota di Windows, lo governa. Quindi la configurazione corretta nasce da un allineamento tra funzionalità del client, ruoli di sicurezza in console, policy di sito e raggiungibilità delle porte. L’errore tipico è trattarlo come una semplice opzione di compliance. Non lo è: è una funzione operativa con impatto su supporto, sicurezza e audit.

Prerequisiti da verificare prima di toccare la console

Prima di abilitare la funzione, controlla che l’ambiente sia coerente con il modo in cui vuoi usarla. Se il tuo obiettivo è il supporto helpdesk, devi sapere chi può chiedere assistenza, chi può rispondere, e se la richiesta deve passare da approvazione dell’utente o da flusso automatico. Se invece stai pensando a un uso di tipo amministrativo, il rischio è di aprire troppo la superficie di accesso senza un vero controllo operativo.

Verifica almeno questi punti:

• Il client SCCM è installato e riceve policy dal site.
• Gli utenti hanno il client attivo e non bloccato da GPO o hardening locale.
• Le porte e i firewall consentono il traffico richiesto dalla modalità di assistenza usata.
• Hai deciso se l’assistenza deve essere permessa solo a gruppi specifici o a tutti gli utenti gestiti.
• Hai un criterio per auditing e tracciamento delle sessioni.

Se manca uno di questi elementi, non inventare il comportamento: chiudi prima il gap. Per esempio, se non sai quali porte siano richieste nel tuo scenario, verifica la documentazione del tuo build SCCM e della versione di Windows client in uso, poi conferma con un test di connettività controllato. La differenza tra “configurato” e “funzionante” in questo caso è tutta lì.

Dove si abilita davvero l’Assistenza Remota in SCCM

La parte centrale sta nelle Client Settings del Configuration Manager. È lì che definisci se la funzione è disponibile per i client e con quali regole. In console, il percorso tipico è Administration → Client Settings. Puoi modificare le impostazioni globali o creare una policy dedicata da applicare a una collection specifica. In produzione, la seconda strada è quasi sempre quella più pulita.

Il motivo è semplice: non tutti i device devono ricevere lo stesso profilo. Un laptop di utenti standard, un PC di un team tecnico e una postazione di laboratorio non hanno lo stesso rischio né lo stesso bisogno di supporto. Separare le policy riduce gli effetti collaterali e ti permette di fare rollback su un perimetro piccolo.

Dentro la client settings cerca la sezione relativa a Remote Tools o Remote Control, a seconda della versione e della lingua della console. Qui abiliti la funzione e imposti il comportamento base: consenti o no il controllo remoto, mostrare o meno la richiesta all’utente, livello di visibilità della sessione e eventuali restrizioni per gli operatori.

Configurazione operativa: cosa impostare e perché

Una configurazione sensata non parte dall’idea “abilita tutto”, ma da una sequenza precisa. Prima decidi il modello di autorizzazione, poi il livello di interazione, infine l’audit. Se inverti i passaggi, ti ritrovi con un sistema che funziona ma non è governabile.

1. Abilita l’Assistenza Remota nella client settings. Senza questo, il client non riceve la policy necessaria. Se vuoi fare un test, applica la modifica solo a una collection di laboratorio o a un gruppo ristretto di client pilota.
2. Definisci chi può offrire supporto. Assegna i ruoli solo a gruppi AD o gruppi SCCM ben delimitati. Evita assegnazioni a utenti singoli quando il processo deve essere scalabile e auditabile.
3. Stabilisci il livello di consenso dell’utente. In alcuni ambienti l’utente deve approvare ogni sessione, in altri la richiesta può essere automatizzata. Il primo modello è più sicuro, il secondo è più rapido. La scelta dipende dal tuo processo di supporto e dalle policy interne.
4. Imposta le opzioni di visualizzazione. Se l’utente deve vedere cosa succede sul desktop, mantieni la sessione visibile. Se hai casi d’uso particolari, valuta le opzioni di privacy e registrazione disponibili nella tua versione.
5. Configura eventuali limiti di controllo. Alcune organizzazioni permettono solo visualizzazione iniziale e poi elevazione con consenso; altre consentono controllo pieno. Qui la regola pratica è non lasciare ambiguità tra helpdesk e security.

Se hai bisogno di un approccio più prudente, crea una policy dedicata per una sola collection, applicala a pochi client e osserva il comportamento per qualche ciclo di policy. È il modo più rapido per capire se il problema è nella configurazione o nella distribuzione della policy.

Permessi e ruoli: l’errore che rompe tutto senza far rumore

La funzione può essere abilitata lato client, ma se i ruoli in console non sono coerenti gli operatori vedranno opzioni mancanti o sessioni negate. In SCCM i permessi non sono ornamentali: controllano chi può avviare, accettare, monitorare o terminare una sessione. Questo è il punto in cui molti ambienti si fermano a metà.

Controlla i ruoli amministrativi e le security scopes associate. Se un operatore helpdesk non vede il device o non riesce ad avviare l’assistenza, spesso il problema non è la rete ma il perimetro di sicurezza della console. Verifica che l’oggetto target sia visibile nel relativo scope e che il ruolo abbia le autorizzazioni necessarie per i tool remoti.

Un controllo rapido lato console consiste nel verificare che il gruppo usato per gli operatori sia assegnato a un ruolo adeguato e che il device sia incluso nella collection giusta. Se il device è fuori collection, la policy può anche esistere, ma non arriverà mai dove deve.

Flusso consigliato per un rollout controllato

Il rollout va fatto come un change, non come un click di configurazione. La sequenza corretta è piccola, reversibile e osservabile. Se lo fai così, quando qualcosa non funziona sai esattamente dove guardare.

1. Crea una client settings dedicata per test, senza modificare la policy globale.
2. Applica la policy a una collection pilota con pochi endpoint rappresentativi.
3. Aspetta il ciclo di policy o forza il machine policy retrieval su un client di test.
4. Verifica la presenza delle impostazioni sul client e la visibilità del componente di assistenza.
5. Simula una sessione da un account autorizzato e controlla accettazione, visualizzazione e chiusura corretta.
6. Estendi il rollout solo dopo aver confermato che log e comportamento corrispondono all’atteso.

Per forzare una ricezione policy sul client puoi usare la console o, dove consentito, un refresh del machine policy cycle. In ambiente Windows, il punto di verifica più utile non è il “sembra attivo”, ma il log del client e lo stato della policy effettivamente ricevuta. Se non trovi evidenza nel client, non hai ancora configurato nulla di verificabile.

Verifiche lato client: cosa guardare prima di aprire ticket

Quando la sessione non parte, non partire dalla rete a caso. Prima verifica che il client abbia ricevuto la policy e che il componente sia attivo. La diagnostica più utile è quella che separa il problema di distribuzione dal problema di connettività.

Controlli utili:

1. Verifica che il client sia online e in policy refresh.
2. Controlla i log del client SCCM nella directory dei log applicativi del Configuration Manager, in particolare quelli relativi a policy e remote tools.
3. Conferma che il device appartenga alla collection corretta.
4. Verifica che l’utente abbia ricevuto la richiesta e che non la stia bloccando con notifiche, UAC o policy locali.
5. Controlla eventuali software di sicurezza endpoint che possano bloccare il canale remoto.

Se vuoi un test minimale, usa un client pilota e confronta il comportamento con un client che sai essere funzionante. La differenza nei log è spesso molto più chiara di una verifica manuale in console.

Comandi e verifiche rapide sul client Windows

Per una verifica di base puoi controllare la presenza del client, lo stato dei servizi e la capacità di raggiungere il management point o comunque il tuo backend SCCM. I comandi sotto non risolvono l’Assistenza Remota da soli, ma ti dicono se stai lavorando su un client vivo o su un endpoint già fuori dal perimetro.

Get-Service CcmExec
Get-ChildItem 'C:\Windows\CCM\Logs\' | Select-Object Name, LastWriteTime | Sort-Object LastWriteTime -Descending | Select-Object -First 10

Se il servizio CcmExec non è in esecuzione, la prima anomalia è lì. Se i log non si aggiornano, il problema può essere un client fermo, una policy non ricevuta o un errore più a monte nella comunicazione con il site. In quel caso non ha senso insistere con l’assistenza remota finché non hai ripristinato la base del client management.

Per un controllo rete minimo, verifica che il client esca verso i componenti SCCM e che non ci siano blocchi firewall locali o di rete. Se usi un proxy o segmentazione forte, il fatto che SCCM sia “installato” non dice nulla sulla raggiungibilità reale.

Problemi tipici e come leggerli senza perdere tempo

Ci sono alcuni guasti ricorrenti. Il primo è la policy che arriva ma la sessione non si apre: spesso è un tema di permessi o di consenso utente. Il secondo è il contrario: i permessi ci sono, ma il client non riceve la configurazione perché la collection è sbagliata o il refresh non è avvenuto. Il terzo è il caso più subdolo: tutto sembra a posto, ma un prodotto di endpoint protection blocca il traffico o l’iniezione necessaria al controllo remoto.

Una lettura corretta dei sintomi aiuta a non fare troubleshooting infinito. Se il problema è uniforme su tutti i client, sospetta policy o ruoli. Se colpisce solo alcuni segmenti di rete, guarda firewall, routing o proxy. Se riguarda un solo utente o un solo device, spesso è un problema locale di stato client, membership di collection o software di sicurezza.

Audit, sicurezza e aspetti da non lasciare impliciti

Ogni funzione di controllo remoto aumenta la superficie operativa. Per questo conviene definire in anticipo chi può avviare la sessione, come viene notificato l’utente, se la sessione è registrata o tracciata e dove finiscono gli eventi di audit. Se lasci questi dettagli alla configurazione predefinita, di solito il risultato è o troppo permissivo o troppo opaco.

Dal punto di vista della sicurezza, la regola è semplice: privilegia gruppi dedicati, scope ristretti e logging minimo sufficiente per ricostruire chi ha fatto cosa. Non salvare credenziali in chiaro nei flussi operativi e non affidarti a eccezioni manuali per il supporto quotidiano. Se devi fare un’eccezione temporanea, documentala e rimuovila subito dopo il test.

Se il tuo ambiente è soggetto ad audit, conserva evidenza della modifica alla client settings, del perimetro applicato e della data di rollout. In pratica: esporta o annota la policy, conserva il nome della collection pilota e tieni traccia del ticket di change. È il minimo per non dover ricostruire tutto a posteriori.

Rollback: come tornare indietro senza lasciare residui

Il rollback deve essere banale. Se hai usato una client settings dedicata, basta disassociare la collection o riportare la policy allo stato precedente. Se hai modificato la global client settings, il rollback è più delicato perché impatta tutti i client e può richiedere un nuovo ciclo di policy.

1. Rimuovi la collection pilota dalla policy di test, se usata.
2. Disabilita l’opzione di Assistenza Remota nella client settings dedicata o ripristina il profilo precedente.
3. Forza un refresh policy sui client interessati e verifica che la funzione sparisca dalla UI o non sia più disponibile.
4. Controlla i log client per confermare l’assenza di nuove richieste di remote tools.

Il backup minimo, prima di cambiare la configurazione, è una schermata o esportazione della client settings e l’elenco delle collection coinvolte. Senza questo, il rollback diventa memoria operativa, che in produzione è il modo più veloce per sbagliare.

Schema pratico da usare in un ambiente reale

Se vuoi una sequenza che funzioni senza teatrini, usa questa: crea una policy dedicata, applicala a un gruppo ristretto, verifica i log client, testa una sessione con un account helpdesk autorizzato, poi estendi il perimetro. È più lenta di un click globale, ma ti evita di dover spiegare a tutta l’azienda perché il supporto remoto è sparito o è diventato troppo permissivo.

La vera qualità della configurazione non è “si vede il pulsante”, ma “so chi lo può usare, su quali endpoint, con quali log e con quale rollback”. Se riesci a rispondere a queste quattro domande, l’Assistenza Remota in SCCM è sotto controllo. Se no, è solo una funzione accesa a metà.