Correggere il controllo prerequisiti del Co-Management SCCM verso Intu

Il controllo prerequisiti va letto come una catena, non come un singolo flag

Quando il controllo prerequisiti del Co-Management in SCCM fallisce verso Intune, il problema raramente è “Intune non funziona”. Più spesso il blocco è in uno dei punti della catena: tenant Azure AD non allineato, enrollment non pronto, licenza mancante, policy di co-management non pubblicata, oppure client SCCM che non riesce a leggere correttamente la configurazione. La correzione giusta dipende da dove si interrompe il flusso, non dal messaggio finale che vedi nella console.

La regola pratica è semplice: prima osservi lo stato atteso e quello osservato, poi restringi il dominio del guasto. Nel caso del Co-Management, lo stato atteso è che il client Windows sia ibridamente pronto a parlare sia con Configuration Manager sia con Intune; lo stato osservato, quando qualcosa non torna, è un prerequisito che resta in errore o in sospeso e impedisce l’abilitazione del workload.

Stato atteso e stato osservato

Atteso: il dispositivo è registrato nel tenant corretto, il client SCCM vede la policy di Co-Management, l’enrollment verso Intune è consentito e i workload possono essere pilotati o spostati in modo controllato.

Osservato: il controllo prerequisiti segnala errore o non passa, e il dispositivo resta bloccato prima dell’abilitazione del co-management, spesso con sintomi diversi a seconda del punto di rottura: nessuna registrazione, enrollment incompleto, tenant mismatch, o policy non applicata.

Dove si rompe di solito la verifica

Le ipotesi più probabili, in ordine, sono queste:

1. Tenant o ambiente non coerente: SCCM punta a un tenant Intune diverso da quello in cui stai guardando il dispositivo. Si falsifica in pochi minuti controllando il tenant ID configurato nella console e confrontandolo con quello del portale.
2. Prerequisito di enrollment non soddisfatto: il device non è idoneo all’auto-enrollment o la GPO/MDM scope non lo consente. Si verifica in pochi minuti guardando lo stato di enrollment sul client e i log di registrazione.
3. Policy Co-Management non arrivata o non letta: la configurazione è corretta, ma il client non ha ancora ricevuto la policy o la riceve con errore. Si falsifica controllando i log del client e la presenza della policy nel ciclo di policy evaluation.

La chiave è non partire dal toggle del workload. Se il prerequisito fallisce, il workload non è ancora il problema. Prima devi capire se il dispositivo è nel tenant giusto, se è eleggibile all’enrollment e se il client riceve davvero la configurazione.

Controlli immediati sul tenant e sull’enrollment

Il primo taglio va fatto tra configurazione lato console e stato reale del device. In pratica: tenant, enrollment, device object e policy.

1. Verifica il tenant configurato in SCCM: nella console di Configuration Manager, apri le impostazioni di Co-Management e controlla l’ID tenant associato. Se hai più ambienti, questo è il punto in cui si sbaglia più spesso. Se il tenant non coincide con quello del portale Intune, il prerequisito fallisce anche se tutto il resto è corretto.
2. Controlla lo stato del device in Intune: nel portale Microsoft Intune verifica che il dispositivo compaia con lo stesso UPN, stesso device name o stesso object ID atteso. Se il device non esiste, il problema è a monte dell’enrollment. Se esiste ma è duplicato, c’è spesso una registrazione precedente da ripulire o una join condition incoerente.
3. Osserva il client Windows: sul dispositivo, apri il pannello di accesso lavoro/scuola e verifica se l’account è connesso correttamente. Se l’enrollment è ibrido, controlla anche che il dispositivo sia in uno stato coerente con Azure AD Join o Hybrid Azure AD Join, secondo il design scelto.

Se vuoi una verifica rapida da terminale, raccogli lo stato di registrazione e i log di MDM sul client. Non serve inventare: i file e le chiavi di stato sono lì proprio per questo.

Nel risultato, i campi da leggere sono quelli relativi a AzureAdJoined, DomainJoined, TenantId e MdmUrl. Se TenantId non coincide con quello atteso, hai già un indizio forte. Se MdmUrl è assente o incoerente, il device non sta andando verso il canale MDM previsto.

Per il lato enrollment, il punto di osservazione più utile è il registro eventi del client, non la console. I percorsi possono variare leggermente, ma il riferimento operativo è il canale DeviceManagement e i log di registrazione MDM. Se non sai dove guardare, il primo artefatto utile è sempre lo stato del servizio e gli eventi recenti di enrollment.

Correzione minima reversibile: allinea il prerequisito, non il workload

La correzione più sicura è una modifica minima e reversibile: riallineare il prerequisito che sta impedendo il passaggio, senza spostare subito i workload. Questo riduce il blast radius e ti permette di capire se il blocco è davvero lì.

1. Conferma il tenant corretto nella console SCCM. Se trovi un tenant errato, correggilo solo dopo aver esportato o annotato la configurazione corrente. Il rollback, in questo caso, è ripristinare il tenant precedente e riavviare il ciclo di policy sul client.
2. Verifica l’enrollment scope lato Intune. Se l’auto-enrollment non è consentito, correggi la policy di MDM enrollment o la join configuration in modo coerente con il design previsto. La modifica è reversibile: prima annota la policy corrente, poi applica il cambio e verifica la comparsa del device nel portale.
3. Forza una nuova valutazione della policy sul client. Dopo aver corretto il prerequisito, esegui un refresh controllato delle policy e verifica se il client scarica la configurazione di Co-Management. Se non cambia nulla, il problema non è il refresh ma la catena di autenticazione o di registrazione.

Se devi agire sul client, mantieni il rischio basso: non disinstallare componenti a caso, non forzare reset completi se non hai prima raccolto evidenze. Un reset dell’enrollment senza diagnosi può risolvere temporaneamente e lasciare il problema strutturale intatto.

Un esempio concreto: se il device compare in Intune ma il prerequisito SCCM continua a fallire, spesso il client ha una registrazione valida ma non sta leggendo la policy giusta. In quel caso il rollback è semplice: ripristini la configurazione precedente, attendi un nuovo ciclo di policy e confronti i log prima e dopo. Se invece il device non compare proprio in Intune, il rollback della policy SCCM non basta, perché il guasto è a monte.

Log e segnali che valgono più della console

Nel troubleshooting del Co-Management, i log del client contano più del messaggio sintetico in console. Il loro valore è che separano il problema di configurazione da quello di trasporto o registrazione. Se il prerequisito fallisce, devi capire se il client non riceve la policy, la riceve ma non la applica, o la applica ma non riesce a completare l’enrollment.

I punti da osservare sono tre: log di gestione MDM, log di Configuration Manager sul client e stato del device in Intune. Se uno dei tre è incoerente, hai già una direzione. Se tutti e tre sono coerenti ma il prerequisito resta fallito, allora il problema è probabilmente nella corrispondenza tra tenant, oggetto device e modalità di join.

Nel visualizzatore eventi, cerca gli errori recenti legati alla registrazione MDM e alla gestione del device. L’obiettivo non è leggere tutto, ma trovare il primo errore a monte, non il sintomo finale. La sequenza temporale dei log è fondamentale: spesso l’errore reale arriva minuti prima del messaggio che vedi in console.

Quando la causa è il design, non il singolo client

Se il problema si ripete su più dispositivi, smetti di trattarlo come incidente isolato. A quel punto il difetto è quasi sempre nel design: scope di enrollment troppo stretto, tenant sbagliato in una parte dell’ambiente, device group non coerenti, oppure prerequisiti di join non allineati con il parco macchine reale.

Qui la correzione strutturale non è “riprovare finché passa”, ma rendere il prerequisito verificabile in modo esplicito. Per esempio: documentare quale tenant è autorizzato, quali device group devono entrare nel co-management, quale tipo di join è supportato e quale log usare come fonte di verità. Senza questa disciplina, ogni nuovo device diventa una scommessa.

Nel mondo Microsoft, un errore comune è confondere la presenza del device in Entra ID con il fatto che sia pronto per il co-management. Sono due cose correlate, non equivalenti. Il device può esistere nel tenant e restare comunque fuori dal flusso corretto di MDM o SCCM.

Sequenza operativa che uso per chiudere il caso senza fare danni

1. Raccolgo evidenze: tenant SCCM, stato device in Intune, output di dsregcmd /status, ultimi eventi MDM sul client.
2. Isolo il punto di rottura: tenant mismatch, enrollment assente, policy non letta, oppure oggetto device duplicato o incoerente.
3. Applico una sola modifica: correzione tenant, scope enrollment o refresh policy. Niente cambi multipli insieme.
4. Verifico l’effetto: il prerequisito passa, il device compare correttamente, e il controllo Co-Management cambia stato in modo osservabile.
5. Conservo il rollback: snapshot della configurazione precedente, così se il comportamento peggiora ripristini senza inseguire effetti collaterali.

Questa sequenza funziona perché evita il classico errore di toccare subito il workload. Prima fai passare il prerequisito, poi abiliti il resto. È più lento di un click impulsivo, ma molto più prevedibile.

Controllo finale: come sapere che hai davvero risolto

Hai chiuso il problema solo quando il device mostra coerenza su tre livelli: il tenant è quello giusto, il device è visibile e allineato in Intune, e il client SCCM vede la policy di Co-Management senza errori di prerequisito. Se uno di questi tre punti manca, la correzione è solo parziale.

Il controllo finale non è una schermata “verde” isolata. È la convergenza tra console, portale e client. Se vuoi una prova pratica, esegui una nuova valutazione della policy e confronta gli eventi prima e dopo. L’assenza del vecchio errore e la comparsa dello stato atteso sono il segnale buono; tutto il resto è rumore di interfaccia.

Assunzione operativa: il problema parte da un prerequisito di Co-Management su SCCM verso Intune e non da un guasto generale di rete o di infrastruttura.