Installare il client SCCM su computer Linux

Installare il client SCCM su Linux: cosa è realistico aspettarsi

Su Linux non si installa il classico client SCCM/MECM come su Windows. Il punto da chiarire subito è questo: in ambiente Linux si parla di gestione dell’inventario e della conformità tramite Microsoft Endpoint Configuration Manager con supporto Linux, non del client completo con tutte le funzionalità Windows. In pratica, la parte che interessa davvero è il client per dispositivi Linux che parla con l’infrastruttura Configuration Manager per inventario hardware/software e alcune azioni di gestione, a seconda della versione e della distribuzione supportata.

Se l’obiettivo è “vedere il server Linux dentro SCCM”, ci si deve muovere su un perimetro preciso: distribuzione supportata, prerequisiti di rete corretti, time sync, certificati se richiesti, account con permessi adeguati e pacchetto giusto per la release. Se uno di questi tasselli manca, l’installazione sembra andare a buon fine ma il client non si registra oppure resta invisibile nel console.

Compatibilità: il primo filtro che evita tempo perso

Prima di scaricare qualsiasi pacchetto, bisogna verificare che la distro sia realmente supportata dalla versione di Configuration Manager in uso. Questo è il primo bivio: molte guide online mischiano versioni vecchie del client Linux, branch diversi di MECM e distribuzioni non più allineate. Il risultato è un pacchetto che magari si installa, ma non si connette correttamente al management point.

Controlli minimi da fare:

1. Versione di Configuration Manager lato Microsoft.
2. Distro e release Linux del nodo target.
3. Architettura hardware: quasi sempre x86_64.
4. Presenza di repository ufficiale o pacchetto fornito da Microsoft per quella release.

Se non hai la matrice di supporto sotto mano, fermati qui e chiudilo con una verifica documentale: apri la console, controlla la build del site e incrociala con la documentazione Microsoft per il supporto Linux. È un gap da chiudere prima di procedere, non dopo.

Prerequisiti di sistema e rete

Il client Linux non vive isolato: deve raggiungere il management point, spesso anche il distribution point o i servizi usati per policy e inventory. Il problema classico non è il pacchetto, ma la rete. Firewall locale, proxy aziendale, DNS incompleto, NTP fuori sync o certificati non coerenti sono i punti che rompono la registrazione più spesso del software stesso.

Verifiche rapide lato host:

hostname -f
cat /etc/os-release
uname -m
timedatectl status

Atteso: FQDN corretto, release supportata, architettura compatibile e orologio sincronizzato. Se il tempo è sfasato di minuti, la parte TLS e l’autenticazione verso l’infrastruttura Microsoft diventano fragili o falliscono del tutto.

Verifiche di connettività verso il management point, prendendo come esempio il nome host del server SCCM:

getent hosts sccm-mp.example.local
curl -vk https://sccm-mp.example.local/
ss -tulpn | grep -E '(:80|:443|:8530|:8531)'
openssl s_client -connect sccm-mp.example.local:443 -servername sccm-mp.example.local

Qui non stai cercando solo “risponde o non risponde”. Stai verificando DNS, reachability, porta, certificato e SNI. Se il management point espone HTTPS con certificato interno, il client Linux deve fidarsi della CA corretta. In caso contrario il sintomo tipico è un install apparentemente concluso ma nessuna registrazione utile nei log.

Pacchetto giusto e dipendenze: installazione pulita

La modalità più sicura è partire dal pacchetto ufficiale previsto per la distribuzione. Non conviene “adattare” un pacchetto di una release diversa sperando che basti: su Linux le dipendenze cambiano e il bootstrap può fallire per librerie mancanti o versioni incompatibili.

In molte installazioni il flusso è simile: si aggiunge il repository o si scarica il pacchetto RPM/DEB, si installano i prerequisiti, poi si lancia il setup del client. Esempio generico su sistemi Debian/Ubuntu:

sudo apt update
sudo apt install -y curl ca-certificates openssl libicu-dev
sudo dpkg -i ./mecm-client-linux.deb

Esempio generico su sistemi RHEL/Rocky/Alma:

sudo dnf install -y curl ca-certificates openssl compat-openssl11
sudo rpm -ivh ./mecm-client-linux.rpm

La lista esatta delle librerie dipende dalla versione del client e dalla distro. Se il pacchetto segnala dipendenze mancanti, non forzarle con workaround ciechi: leggi l’errore, installa il pacchetto richiesto dal repository ufficiale e ripeti. Se il repository non esiste per quella release, è molto probabile che la combinazione non sia supportata.

Registrazione del client: il punto che distingue “installato” da “gestito”

Installare il binario non basta. Il passaggio critico è la registrazione verso l’infrastruttura SCCM/MECM. Qui entrano in gioco parametri come nome del management point, site code, eventuale tenant o gateway, certificati e credenziali di bootstrap. La sintassi varia in base alla versione del client, quindi va letta la documentazione della release specifica.

Concettualmente il processo è questo:

1. Installi il pacchetto client.
2. Imposti i parametri di connessione al site.
3. Avvii il servizio o il demone del client.
4. Verifichi i log locali.
5. Controlli la comparsa del device nella console.

Se il client richiede un file di configurazione, trattalo come un asset sensibile. Non mettere segreti in chiaro dentro script condivisi o repository. Se serve un token o una password di bootstrap, usalo in forma temporanea, limita i permessi del file e ruotalo appena terminato il deployment.

Esempio di bootstrap concettuale

La forma esatta del comando dipende dal pacchetto, quindi qui va inteso come schema operativo, non come sintassi universale:

sudo /opt/microsoft/mecm/client/bin/clientsetup \
  --mp sccm-mp.example.local \
  --sitecode ABC \
  --register

Se il tuo pacchetto usa un installer diverso, cerca il file README incluso nel bundle o il manuale Microsoft relativo al client Linux. Il punto operativo resta lo stesso: il client deve conoscere il management point e il site code, altrimenti resta locale e inutile per la console.

Log da guardare subito quando qualcosa non torna

Qui si fa troubleshooting vero, non ipotesi astratte. I log del client sono la fonte primaria. Il path esatto cambia con la versione, ma in genere si trovano sotto una directory del prodotto, spesso in area /var/opt o /opt/microsoft. Se non sai dove siano, cerca i file più recenti subito dopo il tentativo di installazione.

sudo find /var /opt -type f \( -name '*.log' -o -name '*.txt' \) 2>/dev/null | grep -iE 'mecm|sccm|configmgr|client'

Cerca questi segnali:

• errore di TLS o certificato non trusted;
• DNS che risolve a un host errato;
• timeout verso il management point;
• fallimento di autenticazione o registrazione;
• mancanza di permessi sul percorso di installazione o sui file di stato.

Se il client espone un servizio systemd, controlla anche lo stato del demone:

systemctl status mecm-client
journalctl -u mecm-client -b --no-pager

Atteso: servizio attivo e nessun loop di restart. KO tipico: restart continuo, segnale di configurazione incompleta o dipendenza non soddisfatta.

Verifica lato console SCCM/MECM

Una volta completata la registrazione, il controllo va fatto lato console. Non basta vedere il processo in esecuzione sul server Linux. Il device deve comparire con il nome corretto, la versione del client e lo stato aggiornato.

Controlli pratici:

1. Il device compare nella collection prevista.
2. Il nome host corrisponde al FQDN atteso.
3. La data dell’ultimo heartbeat o inventory è recente.
4. La policy assegnata è quella giusta.

Se il device non appare, il problema è quasi sempre prima della console: rete, certificati, registrazione o time sync. Se appare ma resta “vecchio”, allora il nodo comunica in modo intermittente o il canale inventory ha errori nei log.

Problemi tipici e come isolarli in pochi minuti

Il vantaggio di una diagnosi ordinata è che evita di toccare il server a caso. Le cause più frequenti sono poche e ripetitive.

1. DNS sbagliato: il client risolve il management point su un IP vecchio o interno non raggiungibile. Falsificazione rapida: getent hosts e nslookup sul nome del MP.
2. Certificato non fidato: il client rifiuta il canale HTTPS. Falsificazione rapida: openssl s_client e controllo della CA installata nel trust store.
3. Firewall o proxy: la connessione parte ma si ferma su handshake o timeout. Falsificazione rapida: curl -vk e test porta con ss o nc -vz.
4. Versione non supportata: il pacchetto installa ma la registrazione fallisce. Falsificazione rapida: verifica matrice di supporto Microsoft e release del client.

Se devi scegliere una sola cosa da controllare per prima, controlla la connettività verso il management point con il certificato. È il punto in cui si sommano DNS, TLS e rete. Quando quello è sano, metà dei problemi sparisce.

Procedura consigliata, in ordine operativo

Questa è la sequenza che riduce gli errori operativi e mantiene il blast radius basso. Non richiede modifiche invasive e ti permette di fermarti appena trovi il collo di bottiglia.

1. Conferma supporto della distro e della versione di Configuration Manager.
2. Verifica FQDN, time sync e reachability verso il management point.
3. Installa dipendenze ufficiali del client per quella distribuzione.
4. Installa il pacchetto client corretto.
5. Configura bootstrap, site code e management point.
6. Avvia il servizio del client.
7. Controlla log locali e comparsa in console.

Se un passaggio fallisce, non andare avanti “per vedere se dopo si sistema”. Fermati sul primo errore, annota il log e correggi quello. Su questi client, i problemi a cascata sono la norma.

Hardening minimo: permessi, segreti e manutenzione

Anche se il client Linux non espone una superficie enorme, va trattato come software di gestione privilegiato. I file di configurazione devono stare con permessi stretti, i token temporanei non devono finire in shell history e il trust store va mantenuto aggiornato. Se il client usa certificati interni, pianifica la rotazione prima della scadenza, non dopo il down.

Controlli utili:

ls -l /opt/microsoft 2>/dev/null
sudo update-ca-certificates 2>/dev/null || sudo update-ca-trust

Se il client usa un account di servizio locale o credenziali per l’onboarding, limita la durata e conserva il materiale sensibile in un vault o in un secret manager. Niente password in chiaro dentro note operative o script condivisi.

Quando conviene fermarsi e aprire un ticket

Ci sono casi in cui insistere sul nodo non serve. Se la distro è fuori supporto, il management point non risponde correttamente, il certificato è emesso da una CA non distribuita o il pacchetto ufficiale non esiste per quella release, la strada giusta è fermarsi e allineare l’infrastruttura. È molto più economico correggere il perimetro che mantenere un client “quasi funzionante”.

Apri un ticket verso chi gestisce l’infrastruttura SCCM/MECM quando hai già in mano almeno questi elementi: output di hostname -f, timedatectl status, verifica DNS, prova curl -vk verso il management point e estratto dei log del client. Così la diagnosi non parte da zero e si evita il ping-pong tra team.

In sintesi operativa

Installare il client SCCM su Linux non è un’operazione “clicca e via”. È una sequenza disciplinata: supporto della distro, prerequisiti, rete, certificati, bootstrap, log e verifica in console. Se uno di questi anelli manca, il client può risultare installato ma non gestito. La regola pratica è semplice: prima osserva, poi modifica, poi verifica. È il modo più veloce per arrivare a un nodo realmente inventariato e non a un’installazione cosmetica.