Come installare il client SCCM su computer in workgroup

Installare il client Microsoft Configuration Manager (SCCM/MECM) su un computer in workgroup non è un’operazione “semplice ma senza dominio”: è un cambio controllato che sposta l’autenticazione dal trust Kerberos del dominio a un modello basato su certificati e HTTPS. Se questo passaggio viene sottovalutato, il client può anche installarsi, ma poi non registra correttamente il sito, non riceve policy o resta in stato inactive perché il canale di comunicazione non è coerente con la configurazione del management point.

La regola pratica è questa: un computer in workgroup può essere gestito da SCCM, ma non deve dipendere da autenticazione “implicita” di dominio. Serve un percorso esplicito di onboarding, con certificato client valido, management point in HTTPS o Enhanced HTTP dove compatibile, boundary e boundary group corretti, e una strategia per distribuire il client senza affidarsi a GPO o push classico basato su account di dominio.

Quando ha senso usare SCCM su un computer in workgroup

Ci sono casi in cui il workgroup è una scelta tecnica, non una stranezza: postazioni in DMZ, host temporanei, sistemi di laboratorio, macchine di fornitori, endpoint isolati da AD per policy di sicurezza, oppure ambienti ibridi in cui una parte del parco non può essere joinata al dominio. In questi scenari SCCM resta utile per inventario, compliance, distribuzione software e remediation, ma solo se l’architettura è progettata per supportare client non domain-joined.

Il punto da chiarire subito è che il client non “si adatta” da solo. Se il sito è configurato solo per client intranet domain-joined, il workgroup fallisce nei punti più banali: discovery, autenticazione, comunicazione con il management point, accesso al distribution point e download policy. Il problema non è il setup del client in sé; è il percorso di fiducia tra endpoint e infrastruttura SCCM.

Prerequisiti tecnici che evitano il 90% dei fallimenti

Prima di installare il client, conviene verificare l’infrastruttura dal lato server. Se manca uno di questi elementi, il client può installarsi ma non diventare operativo.

• Management point raggiungibile in HTTPS oppure in modalità supportata per client non domain-joined secondo la tua versione di Configuration Manager.
• Certificato client valido sul computer workgroup, rilasciato da una CA fidata dal server e dall’endpoint.
• Boundary e boundary group corretti, così il client sa a quale site assignment e distribution point riferirsi.
• DNS e connettività verso i FQDN usati da SCCM, inclusi eventuali alias del management point.
• Ora di sistema coerente con la CA e con l’infrastruttura, per evitare errori TLS non immediati.

Se uno di questi punti è incerto, non andare avanti “a tentativi”. Prima misura la raggiungibilità del management point e controlla se il certificato viene presentato correttamente. Un errore classico è installare il client con un comando formalmente corretto, ma puntarlo a un MP che risponde solo in HTTP o che usa un certificato non attendibile dal client.

Architettura minima consigliata per i workgroup

La configurazione più lineare è questa: site server e management point esposti in HTTPS, PKI operativa con template per client authentication, distribution point accessibili in modo coerente con il modello scelto, e client installati con certificato macchina. In alternativa, in ambienti moderni si può valutare Enhanced HTTP, ma va verificato con attenzione quali funzionalità e quali versioni sono coinvolte. Non è un dettaglio cosmetico: cambia il modo in cui il client viene autenticato e quanto dipende da PKI classica.

Per un endpoint in workgroup, il certificato client è il centro del problema. Senza un certificato adatto, il client può anche registrarsi parzialmente, ma non avrà una relazione stabile con il site. Il certificato deve essere installato nel computer locale, con chiave privata presente, EKU corretti e trust della CA radice/intermedia già sistemato.

Preparazione del computer in workgroup

Il computer deve avere un nome host stabile, connettività verso i sistemi SCCM e una configurazione di base pulita. Se il nome cambia dopo l’installazione, i log del client diventano più difficili da leggere e la registrazione può risultare incoerente. Per questo, prima del setup verifica hostname, DNS e data/ora.

1. Imposta il nome della macchina in modo definitivo, se non è già corretto.
2. Verifica che il DNS risolva i FQDN del management point e dell’eventuale distribution point.
3. Allinea l’ora con una sorgente attendibile.
4. Installa il certificato client nel computer locale.
5. Verifica che la CA sia fidata dal sistema.

Per controllare rapidamente la presenza del certificato sul sistema Windows puoi usare PowerShell. Il target non è “vedere un certificato qualsiasi”, ma trovare quello giusto per autenticazione client.

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, NotAfter, Thumbprint

Se il certificato non compare in `LocalMachine\My`, non è adatto all’uso come client certificate per SCCM. In quel caso il problema non è il client SCCM, ma la distribuzione del certificato o il template PKI. Chiudi il gap lì, non dopo.

Installazione del client: metodo manuale controllato

Il metodo manuale è quello più utile per i primi test, perché ti permette di vedere esattamente quale parametro rompe il flusso. In un ambiente workgroup, l’installazione da console o da GPO non è il punto di partenza: prima vuoi un endpoint che si iscriva correttamente, poi automatizzi.

Il comando tipico usa `ccmsetup.exe` e punta al management point o ai parametri di site assignment. Un esempio realistico, da adattare al tuo ambiente, è il seguente.

ccmsetup.exe /mp:mp01.contoso.local SMSSITECODE=ABC CCMHOSTNAME=mp01.contoso.local /USEPKICERT /NOSMSCONFIGURATION

Attenzione al significato dei parametri: non tutti sono necessari in ogni scenario e alcuni dipendono dalla versione e dalla configurazione del sito. L’obiettivo non è copiare una stringa “magica”, ma garantire che il client sappia dove andare e con quale identità presentarsi. Se il tuo ambiente richiede HTTPS puro, il comando deve riflettere quel modello; se stai usando meccanismi diversi, verifica la sintassi supportata dalla tua release.

Durante l’installazione, i log da guardare sono `C:\Windows\CCMSetup\Logs\ccmsetup.log` e, dopo l’avvio del client, `C:\Windows\CCM\Logs\ClientIDManagerStartup.log`, `LocationServices.log`, `ClientLocation.log` e `CcmMessaging.log`. Sono loro a dirti se il problema è download del setup, discovery del site, registrazione o trasporto HTTPS.

Verifica del canale HTTPS e del certificato client

Il primo controllo serio è capire se il client riesce a parlare con il management point senza ambiguità. Un test rapido è una richiesta HTTPS verso il FQDN del MP, con attenzione al certificato presentato e al comportamento del server. Non basta che la porta risponda: serve che il TLS sia valido e che il nome coincida.

curl -vk https://mp01.contoso.local/ccm_system/request

Se il server risponde con errore di certificato, hostname mismatch o catena non fidata, il client SCCM farà lo stesso percorso di fallimento, solo più silenzioso. Nel caso di Windows puro puoi anche verificare la connettività con PowerShell e il dettaglio TLS con strumenti di sistema o con il viewer dei certificati. Il punto non è “pingare il server”, ma confermare la fiducia crittografica.

Se usi certificati emessi da CA interna, controlla che la root e le intermedie siano installate nel computer locale. In un workgroup non hai la comodità della distribuzione automatica via dominio, quindi va previsto un metodo esplicito di importazione, ad esempio tramite provisioning iniziale o script di onboarding.

Boundary, site assignment e discovery: il client deve sapere dove stare

Una delle cause più frequenti di “client installato ma non gestito” è la mancanza di boundary corretti. SCCM non lavora per intuito: se l’IP della macchina non appartiene a un boundary assegnato al site, il client può non trovare il posto giusto nell’infrastruttura. Questo è particolarmente evidente quando si spostano macchine in DMZ o su VLAN dedicate senza aggiornare i boundary group.

La verifica va fatta lato console SCCM e lato client. Lato console controlla il boundary group associato al segmento IP. Lato client, `LocationServices.log` ti dice quale site assignment è stato trovato e quale management point è stato scelto.

findstr /i "boundary site assignment management point" C:\Windows\CCM\Logs\LocationServices.log

Se il log mostra assenza di site assignment o MP non valido, non forzare subito il reinstall. Correggi prima il boundary group o il lookup del site. È un fix reversibile, più pulito e più veloce da validare.

Installazione tramite script: quando serve automatizzare

Quando i computer in workgroup sono molti, l’onboarding manuale diventa fragile. A quel punto conviene usare uno script locale, una sequenza di provisioning o un tool di distribuzione che depositi il certificato, lanci `ccmsetup`, e raccolga i log. L’automazione deve però mantenere il principio di reversibilità: se qualcosa va storto, devi poter disinstallare il client e ripartire senza lasciare lo stato sporco.

Un esempio minimale di pre-check in PowerShell può essere questo: verifica che il certificato sia presente prima di avviare l’installazione.

$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -match "CN=WorkgroupClient" }
if (-not $cert) { throw "Certificato client mancante" }

Questo tipo di controllo evita installazioni “cieche” che poi finiscono in ticket inutili. Se il certificato è mancante, il problema si chiude prima del setup SCCM; se è presente, puoi procedere con il comando di installazione e monitorare `ccmsetup.log` in tempo reale.

Errori tipici e come leggerli senza perdere tempo

Nel caso di workgroup, gli errori ricorrenti sono abbastanza prevedibili. Il vantaggio è che spesso li riconosci dal log giusto, senza dover fare tentativi a tappeto.

1. Errore di certificato: il log indica problemi di trust, EKU o validità. Verifica `LocalMachine\My`, chain di trust e nome del server.
2. Management point non raggiungibile: il client non completa la registrazione. Controlla DNS, firewall, porta HTTPS e FQDN.
3. Boundary assente: il client non trova site assignment. Correggi boundary group lato console.
4. Download del client fallito: il Distribution Point non è raggiungibile o non serve il contenuto corretto. Verifica accesso al DP e contenuto pubblicato.
5. Policy assente: il client è installato ma non riceve configurazioni. Guarda `PolicyAgent.log` e `ClientIDManagerStartup.log`.

Un errore che confonde spesso è il client “online” ma apparentemente inattivo. In quel caso il setup è terminato, ma la comunicazione non è davvero stabile. La differenza la fanno i log di policy e messaging, non la sola presenza del servizio `CcmExec`.

Hardening minimo da non saltare

Su un computer in workgroup la superficie d’attacco va tenuta più stretta del solito, perché manca il controllo centralizzato del dominio. Il client SCCM deve parlare solo con gli endpoint necessari, e il certificato non deve diventare un oggetto riutilizzabile in modo improprio. Se il certificato è esportabile senza motivo, o il privato è copiabile altrove, stai aprendo una falla inutile.

• Esponi solo i servizi SCCM necessari verso l’endpoint.
• Usa certificati con scopo limitato e durata coerente con la policy.
• Evita account condivisi per il provisioning, se non strettamente necessari.
• Rimuovi credenziali temporanee subito dopo l’onboarding.
• Registra i passaggi di installazione in un log operativo interno.

Se il client viene installato in una rete poco fidata, considera anche il filtraggio a livello firewall per limitare chi può raggiungere il management point e il distribution point. SCCM non dovrebbe diventare un canale laterale più permissivo del resto dell’infrastruttura.

Sequenza pratica consigliata

Se devi partire da zero, questa è la sequenza che riduce i falsi positivi.

1. Conferma che il site SCCM supporti client non domain-joined nel modello scelto.
2. Prepara PKI, trust chain e certificato client.
3. Verifica boundary e boundary group per il segmento IP della macchina.
4. Controlla che il management point risponda in HTTPS con certificato valido.
5. Installa il client con `ccmsetup.exe` e parametri coerenti con il sito.
6. Leggi `ccmsetup.log` e poi i log del client in `C:\Windows\CCM\Logs`.
7. Solo dopo valida policy, inventory e download contenuti.

Questa sequenza evita il classico errore di installare il client e poi scoprire che il site non è assegnabile, il certificato è mancante o il DP non è raggiungibile. In pratica, separa il problema di installazione dal problema di gestione.

Verifica finale: cosa deve essere vero per dire che funziona

Considera l’installazione riuscita solo se puoi verificare questi punti con evidenza concreta: servizio `CcmExec` attivo, client registrato sul site, policy scaricate, hardware inventory o machine policy in aggiornamento, e log senza errori di autenticazione o boundary. Se uno di questi manca, il lavoro non è finito: il client è solo presente, non operante.

sc query ccmexec

Il controllo del servizio non basta da solo, ma è una prima conferma utile. Poi vai sui log: se `LocationServices.log` mostra site assignment valido e `PolicyAgent.log` riceve policy, sei nel punto giusto. Se invece il client resta senza policy o senza MP, torna indietro ai prerequisiti: quasi sempre il problema è lì.

Assunzione: l’ambiente usa Microsoft Configuration Manager con infrastruttura PKI o modello HTTPS equivalente supportato dalla tua versione, e i computer in workgroup devono essere gestiti senza join al dominio.