Distribuire Sophos Endpoint Protection con SCCM

Distribuzione di Sophos Endpoint Protection con SCCM: cosa conviene preparare prima

La distribuzione di Sophos Endpoint Protection tramite SCCM funziona bene quando la parte più noiosa è già stata chiarita prima del deployment: versione del pacchetto, architettura supportata, modalità di installazione, prerequisiti del client e criteri di rilevamento. Il punto non è solo “pubblicare un software”, ma evitare che il client scarichi un installer che poi si ferma per un conflitto con un altro antivirus, per una mancata elevazione o per un detection method troppo debole.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

In pratica conviene trattare Sophos come un’applicazione con impatto sulla sicurezza: la distribuzione va verificata su un gruppo pilota, i log vanno controllati subito e il rollback deve essere chiaro. Se stai lavorando in produzione, considera sempre che un endpoint senza protezione o con protezione parziale è un rischio operativo, non un semplice “errore di installazione”.

1. Verificare il pacchetto Sophos da distribuire

Prima di creare l’applicazione in SCCM, identifica con precisione il formato fornito da Sophos: spesso il vendor mette a disposizione un installer offline, uno script di deployment o un pacchetto che include già i parametri per l’attivazione e l’assegnazione alla console. Il dettaglio importante è che il pacchetto deve essere ripetibile e silenzioso, altrimenti SCCM non può gestirlo in modo affidabile.

Se il pacchetto è un eseguibile, verifica che supporti l’installazione unattended e che il comportamento sia coerente con l’architettura del client. Se invece hai un MSI, la strada è più lineare, perché puoi basarti su proprietà standard e detection method più puliti. In ogni caso, conserva il file originale in una share protetta, ad esempio in una struttura simile a \\server\Sources\Applications\Sophos\, con permessi di sola lettura per i server di distribuzione.

2. Preparare la source directory e i prerequisiti

La source directory deve contenere solo ciò che serve davvero per l’installazione. Evita di copiare materiale superfluo, perché aumenta tempi di distribuzione, consumo di spazio sui Distribution Point e confusione in fase di manutenzione. Se il vendor fornisce un setup con file di supporto, mantieni la struttura originale, ma documenta chiaramente quale file è il punto di ingresso.

Prima di pubblicare l’applicazione, controlla i prerequisiti tipici:

• versione supportata di Windows client o server, se Sophos lo consente sul target;
• assenza di altri endpoint security agent incompatibili, o piano di rimozione coordinato;
• spazio disco sufficiente per staging e installazione;
• connettività verso i servizi Sophos richiesti dal tuo modello di gestione;
• permessi amministrativi locali del contesto di esecuzione scelto in SCCM.

Se hai un dubbio su un prerequisito, il modo corretto per non improvvisare è testarlo su una macchina campione: installazione manuale in un ambiente controllato, raccolta dei log e verifica del risultato prima di costruire il deployment di massa.

3. Creare l’applicazione in SCCM

In Configuration Manager conviene usare il modello Application invece del vecchio Package, perché hai detection method, requisiti e supersedence più gestibili. Il percorso tipico è Software Library → Application Management → Applications → Create Application. Da lì puoi scegliere il tipo di installer in base al formato del pacchetto Sophos.

Se il setup è un MSI, SCCM può leggere molte informazioni in modo automatico. Se invece è un EXE, spesso conviene definire manualmente nome, produttore, versione e comando di installazione. In questo caso la precisione del detection method diventa essenziale, perché SCCM deve capire in modo univoco se Sophos è già presente oppure no.

Un esempio di comando silenzioso, da adattare al pacchetto effettivo del vendor, può essere simile a questo:

setup.exe /quiet /norestart

Il comando reale dipende dalla release di Sophos che stai distribuendo. Non dare per scontato che un parametri standard funzioni su tutte le versioni: verifica sempre la documentazione del pacchetto specifico o il log generato dal setup.

4. Definire detection method affidabile

La detection è il punto dove molti deployment si rompono in silenzio. Se il metodo è troppo generico, SCCM può considerare installato un prodotto incompleto; se è troppo stretto, il client tenterà reinstallazioni inutili. Per Sophos conviene usare una combinazione di controlli, quando possibile: chiave di registro, presenza di file/versione, oppure query WMI se il vendor espone un identificatore stabile.

Un approccio prudente è basare la detection su una chiave di registro nota del prodotto installato e su un valore di versione coerente con la release distribuita. Ad esempio, puoi controllare una path simile a HKLM\SOFTWARE\... oppure HKLM\SOFTWARE\WOW6432Node\..., ma la chiave esatta va presa dalla documentazione Sophos o dai log di installazione della tua build. Se non hai quel dato, non inventarlo: ricavalo da una macchina già installata e valida.

Se vuoi una detection più robusta, aggiungi un secondo indicatore, come la presenza di un servizio specifico o di un file binario con versione coerente. L’obiettivo è distinguere un’installazione completa da una installazione parziale o corrotta.

5. Impostare requisiti, dipendenze e supersedence

Per evitare problemi sui client non idonei, usa i Requirements di SCCM. Puoi limitare il deployment a sistemi operativi specifici, architetture compatibili e, se serve, a raccolte ben definite. Questo evita di spingere il pacchetto su macchine fuori target, riducendo errori e rumore nei log.

Se stai sostituendo una versione precedente di Sophos o un agente diverso, valuta Supersedence. È utile quando vuoi migrare da una release vecchia a una nuova senza gestire manualmente uninstall e reinstall. In quel caso la regola va testata con attenzione: una supersedence scritta male può rimuovere più del previsto o lasciare residui che interferiscono con il nuovo agent.

Le dipendenze vanno usate solo se davvero necessarie. Se Sophos dipende da un componente aggiuntivo o da un prerequisito locale, documenta chiaramente l’ordine di installazione. In caso contrario, il deployment deve restare il più semplice possibile.

6. Distribuire prima a un gruppo pilota

Non partire mai direttamente con la produzione completa. Distribuisci prima a una collection pilota composta da macchine rappresentative: almeno un endpoint standard, uno con carico applicativo reale e, se esiste, un profilo che in passato ha mostrato problemi di compatibilità. Il pilota serve a scoprire i casi sporchi, non a confermare quello che già sai.

Durante il pilot osserva tre segnali:

1. stato di installazione in SCCM, che deve passare da In Progress a Success o Failed con motivazione leggibile;
2. log lato client, per capire se il setup parte davvero e con quali parametri;
3. presenza del prodotto installato e attivo, non solo “presente nel software center”.

Se il client fallisce, non alzare subito il volume del deployment. Prima recupera il log e verifica se il problema è nel pacchetto, nella detection, nei permessi o in un conflitto locale.

7. Log da controllare quando qualcosa non torna

In SCCM la diagnostica parte quasi sempre dai log. Sul client, i file più utili dipendono dal flusso di installazione, ma per il troubleshooting applicativo e di deployment conviene controllare almeno i log legati a AppEnforce e AppDiscovery. Sul server, se la distribuzione non parte proprio, può essere utile verificare anche i log del Management Point e dello stato del content distribution.

Un controllo rapido lato client può essere questo, adattato al percorso effettivo del tuo setup:

type C:\Windows\CCM\Logs\AppEnforce.log

In un ambiente reale è spesso più utile aprire il file con CMTrace o un viewer equivalente, perché puoi leggere timestamp, exit code e sequenza delle azioni. Se il log mostra un exit code non previsto, confrontalo con la documentazione del setup Sophos o con i codici del vendor.

Se il problema è la detection, controlla se SCCM vede il prodotto come installato anche quando non lo è, oppure il contrario. In entrambi i casi la correzione non è “rifare tutto”, ma correggere il criterio di rilevamento.

8. Gestire conflitti con altri endpoint security

Il caso più delicato è la presenza di un altro antivirus o di un altro EDR. Molti prodotti non amano convivere, o richiedono una sequenza precisa di disinstallazione e riavvio. Se Sophos deve sostituire un agente esistente, il deployment va progettato come una migrazione, non come una semplice installazione.

In questi scenari è utile definire uno script di pre-check che verifichi il software presente prima di tentare l’installazione. Se il conflitto è noto, meglio bloccare il deployment e far emergere il caso in un report, invece di forzare un tentativo che finirà in errore o, peggio, lascerà il sistema in uno stato ambiguo.

Se devi rimuovere un prodotto precedente, fallo in modo controllato: prima collection pilota, poi finestra di manutenzione, poi installazione Sophos. Il rollback, in questo caso, deve prevedere il ripristino del vecchio stato solo se l’ambiente lo consente davvero e se hai una procedura testata.

9. Validare che l’endpoint sia davvero protetto

La verifica finale non è “l’app è installata”. Devi controllare che il servizio sia in esecuzione, che la console Sophos riceva l’endpoint e che l’agent sia in uno stato coerente con la policy assegnata. Se il prodotto compare installato ma non comunica, il problema può essere di rete, autenticazione, policy o servizi locali.

Un buon criterio operativo è questo: installazione completata, detection positiva, servizio attivo, evento o stato registrato lato console. Se uno di questi quattro elementi manca, il deployment va considerato incompleto fino a prova contraria.

Quando possibile, fai un controllo a campione su più endpoint del pilota e confronta i risultati. Se la stessa anomalia si ripete su macchine simili, il problema è quasi sempre nel pacchetto o nella configurazione SCCM; se è isolato, guarda il client specifico.

10. Rollback e manutenzione del deployment

Il rollback deve essere previsto prima della distribuzione, non dopo. Se il pacchetto Sophos crea problemi, il ripristino tipico consiste nel disabilitare il deployment, ritirare la collection interessata e, se necessario, tornare alla versione precedente del pacchetto o a un altro agente di sicurezza approvato. Conserva sempre una copia della versione precedente del contenuto e della configurazione SCCM associata.

Per le modifiche future, tieni traccia di tre elementi: versione del pacchetto, comando di installazione e detection method. Senza questi dati, dopo qualche mese non sarà più chiaro perché un deployment ha funzionato e un altro no. Una documentazione minima ma precisa vale più di dieci note informali sparse in chat.

Assunzione operativa: il pacchetto Sophos usato in SCCM è un installer silenzioso supportato dal vendor, i client sono Windows gestiti da Configuration Manager e il deployment passa prima da una collection pilota.