1 11/10/2026 11 min

Compatibilità reale prima dell’installazione

Su macOS Big Sur l’installazione del client Microsoft ConfigMgr non va trattata come un semplice “doppio clic sul pacchetto”. Prima di partire conviene chiarire tre punti: versione del client supportata, modalità di distribuzione prevista e tipo di gestione che vuoi ottenere sul Mac. In molti ambienti il client viene usato per scenari di inventory, compliance o distribuzione software, ma su macOS la copertura funzionale non è identica a quella di Windows. Se ti aspetti parità totale, il problema non è l’installazione: è il modello di gestione.

Big Sur introduce anche vincoli di sicurezza più rigidi rispetto a release precedenti: autorizzazioni privacy, estensioni di sistema e controlli su app firmate. Questo significa che una procedura “vecchia scuola” può completarsi senza errori e lasciare comunque il client non operativo o non autorizzato. Il criterio giusto è semplice: installazione riuscita non equivale a enrollment riuscito.

Prerequisiti da verificare sul Mac

Prima di toccare il pacchetto, verifica il contesto locale. Ti servono almeno privilegi amministrativi, connettività verso i servizi ConfigMgr previsti dal tuo design e un certificato o meccanismo di autenticazione coerente con la tua infrastruttura. Se il client deve parlare con un MP, un CP o un endpoint interno, i DNS devono risolvere correttamente e il traffico deve uscire senza proxy che riscrivano o blocchino TLS.

Controlla anche la versione del sistema operativo e l’architettura della macchina. Big Sur gira sia su Intel sia, in alcuni casi di migrazione/ambiente misto, su Apple Silicon con Rosetta per componenti legacy. Se il pacchetto che hai scaricato è pensato per Intel-only, devi sapere prima se il tuo scenario lo ammette. Un errore qui si traduce spesso in installazione apparentemente ok ma agent che non parte o non registra i componenti attesi.

Un set minimo di controlli iniziali utile è questo:

sw_vers
uname -m
scutil --dns | grep -i nameserver
ping -c 2 <FQDN-MP-O-ENDPOINT>
curl -I https://<endpoint>/

Se uno di questi controlli fallisce, non ha senso proseguire con l’installer. La diagnosi va fatta prima su rete, DNS o certificati, non dopo aver “sporcato” il sistema con una installazione incompleta.

Che cosa installa davvero il client su macOS

Il client ConfigMgr per macOS non si comporta come l’agente Windows con i classici servizi e cicli di policy equivalenti. In genere installa componenti applicativi, file di configurazione e meccanismi che consentono la comunicazione con il backend Microsoft previsto per macOS. Per questo motivo è importante sapere dove vengono scritti i file, quali binari vengono aggiunti e quale log devi leggere quando qualcosa non torna.

In un troubleshooting serio, il punto non è “si è installato?” ma “ha creato i file corretti e ha contattato il servizio previsto?”. I log e le directory dell’app sono la prima fonte di verità. Se non hai ancora standardizzato i path nel tuo ambiente, prendili dal pacchetto o dalla documentazione del vendor e verifica direttamente sul Mac con ls e find. Non dare per scontato che il nome del file di log sia identico tra release diverse.

Installazione del pacchetto PKG

La modalità più pulita resta il pacchetto .pkg firmato, distribuito in modo controllato. Se lo stai testando localmente, lavora su una macchina di laboratorio o su un utente pilota. Evita installazioni manuali su sistemi di produzione senza una verifica preventiva del percorso di rollback. Un client male configurato non rompe solo il Mac, ma può produrre inventario incompleto, status falsati o errori ripetuti nei log centralizzati.

Per installare da terminale puoi usare installer, così da avere un output leggibile e automatizzabile:

sudo installer -pkg /path/to/ConfigMgrClient.pkg -target /

Se il pacchetto richiede parametri aggiuntivi, non improvvisare con variabili non documentate: estrai i metadati del pkg e controlla gli script di preinstallazione o postinstallazione. Per esempio:

pkgutil --expand /path/to/ConfigMgrClient.pkg /tmp/cmgclient_pkg
ls -la /tmp/cmgclient_pkg
find /tmp/cmgclient_pkg -maxdepth 2 -type f

Se l’installazione fallisce, il primo indizio utile è l’output di installer. Cerca errori di firma, permessi, script interrotti o dipendenze mancanti. Se il pacchetto termina con successo ma il client non appare, passa subito ai log dell’applicazione e non perdere tempo a rilanciare l’installer alla cieca.

Enrollment e registrazione del client

Su macOS l’installazione non basta: il nodo va anche registrato nel modo previsto dal tuo ambiente. Qui spesso nasce l’equivoco più costoso. Se il tuo processo prevede un enrollment manuale, un token, un file di provisioning o una configurazione iniziale fornita dal team infra, devi applicarlo subito dopo l’installazione e non rimandarlo a un secondo momento.

La regola operativa è: prima identifichi il metodo di registrazione, poi verifichi che il client lo abbia consumato. Se il pacchetto deposita un file di configurazione in una directory nota, controlla che sia stato scritto correttamente e che i permessi siano coerenti con l’account che esegue il client. Se l’app richiede un profilo o un certificato, verifica che il profilo sia installato nel posto giusto e non sia scaduto.

Un controllo utile è interrogare i certificati e i profili installati:

profiles list
security find-identity -p codesigning -v
security find-certificate -a -c <nome-certificato>

Se il client dipende da un certificato client-auth, controlla anche la catena completa. Un certificato presente ma non trusted produce errori ambigui: il software sembra installato, ma il servizio remoto rifiuta la sessione. In quel caso il problema è nel trust store, non nell’installer.

Verifiche post-installazione che valgono davvero

Dopo l’installazione devi confermare almeno quattro cose: presenza dei binari, presenza della configurazione, avvio del processo e comunicazione verso l’endpoint. Senza questi quattro segnali il risultato è incompleto anche se il pacchetto ha restituito zero.

Parti dai processi:

ps aux | grep -i -E 'configmgr|cmg|client' | grep -v grep
launchctl list | grep -i -E 'configmgr|cmg|client'

Se sai quale servizio o agente viene registrato, controlla il suo stato con launchctl. Su macOS è un passaggio fondamentale perché molti problemi non sono “software rotto” ma semplicemente un job che non è partito dopo il primo boot o dopo un cambio di permessi.

Poi verifica i log. Se il vendor ha un path documentato, usa quello. In assenza di indicazioni precise, cerca nel contenitore dell’app o in /Library/Logs. Un controllo generico efficace è:

sudo find /Library/Logs -maxdepth 3 -type f | grep -i -E 'configmgr|cmg|client|microsoft'
sudo log show --last 1h --predicate 'eventMessage CONTAINS[c] "configmgr" OR eventMessage CONTAINS[c] "cmg" OR eventMessage CONTAINS[c] "client"'

Il secondo comando è utile quando il problema è recente e non vuoi perdere tempo a navigare a mano tra file storici. Se non trovi nulla, non forzare conclusioni: significa che il client non sta scrivendo dove ti aspetti o che il nome del processo/log è diverso. In quel caso il gap si chiude con la documentazione del pacchetto o con un find più ampio sulla macchina.

Autorizzazioni macOS: il punto che blocca più spesso

Big Sur è severo su privacy e sicurezza. Se il client deve accedere a elementi protetti, può chiedere autorizzazioni che non vengono concesse automaticamente. Il sintomo classico è un’app installata ma parzialmente cieca: inventario incompleto, accesso a cartelle limitato, attività che falliscono senza un errore immediatamente comprensibile.

Quando serve, verifica i permessi concedibili via profilo MDM o con il pannello Privacy & Sicurezza. In ambienti gestiti, preferisci la via centralizzata: meno eccezioni locali, meno drift. Se il tuo processo usa un profilo di configurazione, controlla che non sia stato bloccato da un conflitto con un profilo precedente o da una restrizione del tenant.

Dal lato operativo, la verifica minima è guardare se l’app compare tra quelle autorizzate e se il profilo è installato. Se il comportamento resta anomalo, conviene rimuovere solo il componente coinvolto, non l’intero sistema, e reinstallarlo con i permessi corretti. Su macOS la pulizia selettiva è molto più sicura di un reset totale.

Risoluzione dei problemi più comuni

Se il client non si installa, le cause più probabili sono: pacchetto non compatibile, firma/certificato del pkg non valido, spazio disco insufficiente o policy di sicurezza che blocca lo script di installazione. I test rapidi sono semplici: controlla il return code di installer, verifica lo spazio con df -h e conferma che il file sia firmato e non corrotto.

df -h /
spctl -a -vv /path/to/ConfigMgrClient.pkg
pkgutil --check-signature /path/to/ConfigMgrClient.pkg

Se l’installazione va a buon fine ma il client non comunica, le prime tre ipotesi sono quasi sempre rete, DNS o certificato. Falsificale in pochi minuti con curl verso l’endpoint, test di risoluzione e verifica della chain TLS. Se il traffico passa da proxy o ispezione TLS, controlla che il certificato del proxy sia trusted dal sistema e dall’utente che esegue il client, non solo nel browser.

Se il client comunica ma non produce dati utili, il problema è spesso di autorizzazione o di configurazione incompleta. In quel caso cerca i file di configurazione e confrontali con un host sano. Il confronto diretto è spesso più veloce di qualunque teoria:

diff -u /path/on/bad/mac/config.plist /path/on/good/mac/config.plist

Se il file non è in formato plist ma in JSON, XML o testo semplice, il principio non cambia: confronta il contenuto reale, non il nome del file. Molti problemi nascono da un parametro mancante o da un endpoint scritto male di una singola lettera.

Ripristino e rollback pulito

Ogni installazione su un endpoint utente va pensata con un rollback. Prima di modificare, salva il pacchetto, la configurazione e l’elenco dei componenti installati. Se qualcosa va storto, devi poter tornare allo stato precedente senza inseguire residui sparsi nel filesystem.

Il rollback minimo consiste nel fermare il processo, rimuovere il pacchetto applicativo secondo le istruzioni del vendor e ripristinare eventuali profili o certificati solo se erano stati aggiunti per il test. Evita di cancellare a mano directory casuali senza sapere quali sono i path canonici: su macOS puoi lasciare preferenze residue o rompere il comportamento di altri agenti collegati.

Se devi disinstallare, cerca prima lo script ufficiale o il comando previsto. Se non esiste, documenta esattamente cosa rimuovi e fai un backup del contenuto prima del delete. Un esempio prudente di preparazione al rollback è:

sudo tar -czf /tmp/cmgclient-backup.tgz /Library/Application\ Support/<vendor> /Library/Logs/<vendor> 2>/tmp/cmgclient-backup.err

Se il backup fallisce, non andare avanti: prima capisci il motivo, poi rimuovi. Questo approccio riduce il blast radius e ti lascia una traccia concreta per il ripristino o per un’analisi post-mortem.

Sequenza consigliata in pratica

Se devi fare tutto in modo ordinato, usa questa sequenza. È la più efficace quando lavori su un singolo Mac o su un piccolo gruppo pilota:

  1. Verifica versione di macOS, architettura e connettività verso gli endpoint previsti.
  2. Controlla firma e integrità del pacchetto PKG.
  3. Installa con installer e conserva l’output completo.
  4. Applica enrollment o configurazione iniziale secondo il tuo standard.
  5. Verifica processi, log e comunicazione verso il backend.
  6. Conferma eventuali profili, certificati e permessi privacy.
  7. Solo dopo, estendi a un lotto più ampio di endpoint.

Questa sequenza evita la trappola più comune: distribuire rapidamente il client e accorgersi solo dopo che metà parco macchine non è realmente gestibile. Su macOS il costo del test iniziale è basso; il costo di una correzione di massa è molto più alto.

Dettagli che conviene standardizzare nel tuo ambiente

Se questo client deve essere distribuito con continuità, standardizza almeno tre cose: naming dei pacchetti, percorso dei log e procedura di verifica. Un runbook con comandi esatti vale più di dieci note sparse in chat. Inserisci nel runbook il nome del file PKG, il checksum, il comando di installazione e il comando di verifica post-installazione.

Conviene anche definire un controllo di conformità minimo, per esempio la presenza del processo, la raggiungibilità dell’endpoint e la versione installata. Se hai un sistema di inventory o un MDM, puoi usarlo per validare lo stato del client senza dover accedere manualmente a ogni macchina. In ambienti piccoli basta un controllo via SSH o con uno script locale; in ambienti grandi serve automazione, altrimenti perdi il vantaggio della gestione centralizzata.

Infine, non dimenticare il tema aggiornamenti. Se il vendor pubblica una nuova release del client, verifica prima la compatibilità con Big Sur e con il tuo backend. Aggiornare il client senza verificare la compatibilità del server è un errore classico: il nuovo agente si installa, ma poi parla con un servizio che non supporta ancora quel livello di versione.

Quando fermarsi e chiedere un dato in più

Se non hai il nome esatto del pacchetto, il metodo di enrollment o i path dei log, non conviene andare a tentoni. Il punto di chiusura del gap è sempre lo stesso: recupera dal vendor o dal tuo team infra il file PKG corretto, la procedura di registrazione e il log path ufficiale. Senza questi tre elementi, qualunque guida rischia di diventare troppo generica per essere affidabile.

Nel caso specifico di ConfigMgr Agent su macOS Big Sur, l’approccio giusto è trattarlo come un componente gestito, non come una normale app utente. Installazione, permessi e enrollment sono tre fasi distinte. Se una sola delle tre manca, il risultato finale non è un client funzionante ma un’installazione incompleta che prima o poi ti torna indietro come ticket.