Microsoft MD-102: Co-gestione e ambienti ibridi — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #md-102 #certification #exam-prep #study-guide

Fa parte della Microsoft Endpoint Administrator Associate MD-102 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La co-gestione e gli ambienti ibridi consentono di combinare Configuration Manager (ConfigMgr) con Microsoft Intune per modernizzare la gestione di Windows al proprio ritmo. La co-gestione abilita una transizione carico di lavoro per carico di lavoro, mentre l’aggiunta ibrida ad Azure AD crea un’identità unificata del dispositivo sia in Active Directory on-premise sia in Azure AD. Azure AD Connect sincronizza identità e dispositivi, e le funzionalità di collegamento al cloud come il Cloud Management Gateway (CMG) e il collegamento del tenant estendono ConfigMgr al cloud e al centro di amministrazione di Intune per la gestione via Internet e una console unificata. La pianificazione deve tenere conto dei prerequisiti, dell’identità, della sincronizzazione, della precedenza dei criteri tra Criteri di gruppo e MDM di Intune, e del passaggio graduale dei carichi di lavoro per evitare conflitti.

Architettura e registrazione della co-gestione

La co-gestione integra il client di ConfigMgr con l’MDM di Intune su Windows 10/11. Richiede ConfigMgr current branch (1710+; utilizzare una versione recente supportata), una sottoscrizione Intune con l’autorità MDM impostata su Microsoft Intune, un tenant di Azure AD collegato al sito di ConfigMgr e Windows 10 versione 1709 o successiva oppure Windows 11. I dispositivi dovrebbero avere un’aggiunta ibrida ad Azure AD o un’aggiunta ad Azure AD, in modo che il client di ConfigMgr possa acquisire token di Azure AD.

Il flusso di registrazione per i client ConfigMgr esistenti utilizza la procedura guidata di co-gestione nella console di ConfigMgr per connettere il sito al tenant di Azure AD e configurare la registrazione MDM automatica per una raccolta di destinazione. Il client riceve i criteri con le informazioni del tenant, utilizza la sua identità di dispositivo Azure AD per richiedere un token di registrazione MDM e si registra in Intune senza interazione da parte dell’utente. Questa registrazione automatica supporta dispositivi con o senza affinità utente; non richiede che l’utente finale avvii la registrazione. Assicurarsi che:

Azure AD Connect stia sincronizzando gli oggetti dispositivo e le identità utente come appropriato.
La registrazione MDM automatica sia configurata nelle impostazioni di mobilità di Azure AD e le licenze di Intune siano assegnate.
Il dispositivo abbia visibilità diretta dei domain controller almeno una volta per completare l’aggiunta ibrida ad Azure AD, o sia stato aggiunto ad Azure AD tramite provisioning.

Dopo la registrazione, il dispositivo ha due canali di gestione: il client di ConfigMgr e il canale MDM di Intune. Si controlla quali aree funzionali (carichi di lavoro) sono gestite da quale servizio. Utilizzare raccolte pilota per la convalida prima di spostare tutti i dispositivi. Mantenere un modello chiaro di proprietà della configurazione per evitare l’applicazione duplicata delle policy.

CMG e il collegamento del tenant sono complementari ma indipendenti. Il CMG fornisce connettività client basata su Internet per ConfigMgr, mentre il collegamento del tenant carica i metadati dei dispositivi di ConfigMgr nel cloud ed espone azioni in tempo reale nel centro di amministrazione di Intune. Entrambi fanno parte di una strategia di collegamento al cloud che riduce la dipendenza dalla raggiungibilità della rete on-premise.

Carichi di lavoro, strategia di passaggio e domini dei criteri

I carichi di lavoro rappresentano domini di gestione che possono essere controllati da ConfigMgr o Intune. È possibile impostare ogni carico di lavoro su:

ConfigMgr: ConfigMgr è il proprietario e applica i criteri.
Intune pilota: Una raccolta pilota definita è gestita da Intune; le altre rimangono con ConfigMgr.
Intune: Tutti i dispositivi in co-gestione sono gestiti da Intune per quel carico di lavoro.

Carichi di lavoro chiave e linee guida:

Criteri di conformità: Spostare questo carico di lavoro nelle fasi iniziali su Intune, in modo che la conformità del dispositivo sia valutata in Intune e possa essere utilizzata con l’Accesso condizionale di Azure AD. Definire le impostazioni di conformità (es. PIN, crittografia, versione del sistema operativo) e la correzione tramite Intune. Non configurare baseline di conformità sovrapposte in ConfigMgr per le stesse condizioni.
Configurazione del dispositivo: Copre i profili MDM come restrizioni del dispositivo, VPN, Wi-Fi, certificati e impostazioni basate su ADMX. Quando si passa a Intune, rimuovere o disabilitare le baseline di configurazione di ConfigMgr sovrapposte per i dispositivi pilota per evitare instabilità. Utilizzare il Catalogo delle impostazioni o i Modelli in Intune e preferire i profili di sicurezza degli endpoint per i controlli di sicurezza.
Protezione degli endpoint: Coordina Windows Defender Antivirus, Firewall, SmartScreen e BitLocker. Utilizzare i criteri di sicurezza degli endpoint di Intune quando il carico di lavoro è con Intune. Se ConfigMgr distribuiva in precedenza la gestione di Endpoint Protection o BitLocker, ritirare tali criteri per i dispositivi pilota e confermare che esista una singola autorità per ogni controllo.
App client (Win32) e App di Microsoft 365: Se si sposta la distribuzione di app Win32 su Intune, assicurarsi che l’Estensione di gestione di Intune sia presente e utilizzare i requisiti e le dipendenze delle app per controllare l’ordine. Evitare di indirizzare la stessa app da entrambi ConfigMgr e Intune. Per le App di Microsoft 365, gestire la configurazione dell’installazione e degli aggiornamenti da un’unica autorità per prevenire conflitti di canale.
Aggiornamenti software e criteri di Windows Update: Se gli Aggiornamenti software rimangono con ConfigMgr, il client continua a eseguire la scansione rispetto a WSUS/SUP e può utilizzare il CMG su Internet. Se si passa a Intune, configurare i criteri di Windows Update per le aziende (WUfB) in Intune e disabilitare gli Aggiornamenti software di ConfigMgr per tali dispositivi. Non combinare gli aggiornamenti di ConfigMgr con WUfB sullo stesso dispositivo.
Accesso alle risorse: I profili VPN, Wi-Fi ed e-mail dovrebbero essere di proprietà di un unico sistema. Intune è solitamente preferito per un provisioning cloud-first basato sull’identità dei profili di risorse.

Eseguire il passaggio per fasi. Iniziare con Conformità, poi Configurazione del dispositivo o Protezione degli endpoint, quindi App e Aggiornamenti. Utilizzare raccolte pilota e generare report su deviazioni e conflitti prima di spostare “Tutti”.

Hybrid Azure AD Join e Azure AD Connect

L’Hybrid Azure AD Join crea un’identità di dispositivo unica, rappresentata sia nell’AD on-premise che in Azure AD. È necessario per l’SSO trasparente, per i criteri di accesso condizionale basati su dispositivo per i computer aggiunti a un dominio e per la registrazione alla co-gestione tramite le credenziali del dispositivo. I prerequisiti includono:

Una foresta AD on-premise e un tenant di Azure AD.
Azure AD Connect configurato per sincronizzare gli oggetti dispositivo e le impostazioni di registrazione dei dispositivi richieste.
Uscita di rete verso gli endpoint di registrazione dei dispositivi di Azure AD e visibilità diretta di un domain controller durante la registrazione iniziale per Windows 10/11.
Configurazione corretta dei suffissi UPN e DNS in modo che i dispositivi possano autenticarsi ad Azure AD.

Azure AD Connect è il motore di sincronizzazione tra l’AD on-premise e Azure AD. Considerazioni principali sulla configurazione:

Ambito e filtraggio: Utilizzare il filtraggio basato su OU o attributi per includere utenti, gruppi e dispositivi che devono esistere in Azure AD. Mantenere l’ambito minimo e ben definito.
Metodo di accesso:
- Sincronizzazione degli hash delle password (PHS): Gli hash vengono sincronizzati a intervalli regolari. Azure AD convalida gli accessi utilizzando l’hash sincronizzato. Questa è l’opzione più resiliente e con la minore complessità; supporta il single sign-on trasparente e fornisce un fallback di autenticazione cloud se l’infrastruttura on-premise non è disponibile.
- Autenticazione pass-through (PTA): Un agente leggero installato su uno o più server valida le password direttamente con l’AD on-premise in tempo reale. Utilizzare la PTA se i criteri vietano la memorizzazione degli hash delle password nel cloud o se è necessario applicare i criteri di accesso on-premise. Distribuire più agenti per l’alta disponibilità.
- Federazione (AD FS): Da utilizzare solo se si richiedono regole di attestazione (claim) avanzate o scenari con smartcard/MFA di terze parti non supportati da PHS/PTA. Introduce maggiore complessità e dipendenze.
Registrazione dei dispositivi: In Azure AD Connect, abilitare la procedura guidata delle opzioni del dispositivo per configurare l’Hybrid Azure AD Join per la propria foresta. Assicurarsi che il punto di connessione del servizio (SCP) sia impostato in AD in modo che i dispositivi individuino il tenant di Azure AD. I prerequisiti per i sistemi operativi di livello inferiore non sono necessari per Windows 10/11.
Staging e HA: Considerare la modalità di staging per i server di backup e utilizzare l’esportazione/importazione per la configurazione. Monitorare lo stato della sincronizzazione tramite Azure AD Connect Health.

Un join ibrido configurato correttamente garantisce che i dispositivi possano acquisire i token di dispositivo di Azure AD, abilitando la registrazione automatica per la co-gestione e l’applicazione dei criteri basati su cloud.

Precedenza dei criteri: Group Policy vs Intune MDM

Quando gli Oggetti Criteri di gruppo (GPO) e i criteri MDM di Intune hanno come target la stessa impostazione, la precedenza predefinita varia a seconda dell’impostazione e dell’implementazione. In generale, i GPO tradizionali prevalgono per le impostazioni basate su registro che si sovrappongono, perché vengono applicati dal motore di Criteri di gruppo a intervalli di aggiornamento. Per supportare la gestione moderna, Windows 10 versione 1709 e successive hanno introdotto il criterio ControlPolicyConflict per preferire l’MDM per le aree Policy CSP supportate.

Pratiche chiave per gestire la precedenza ed evitare conflitti:

Stabilire la proprietà per ogni impostazione. Non configurare la stessa impostazione sia in GPO che in Intune. Migrare in blocchi e dismettere i GPO una volta che i criteri MDM equivalenti sono stati implementati.
Utilizzare il controllo “MDM wins over GPO” (l’MDM prevale sul GPO) quando disponibile. Distribuire l’impostazione Policy CSP ControlPolicyConflict (MDMWinsOverGP) tramite Intune per istruire Windows a preferire il Policy CSP dell’MDM rispetto al GPO per le categorie supportate. Molte impostazioni basate su ADMX esposte tramite i modelli amministrativi di Intune rispettano questo controllo, ma non tutte.
Preferire i criteri di sicurezza degli endpoint in Intune per Defender, Firewall e BitLocker perché utilizzano CSP supportati con gestione e reporting chiari dei conflitti.
Convalidare con la diagnostica. Utilizzare il Report di diagnostica MDM integrato (ms-settings:workplace, poi Esporta) e GPResult/Insieme dei criteri risultante per identificare le sovrapposizioni. Rivedere il report per singola impostazione di Intune e le baseline di conformità di ConfigMgr/GPO per rilevare i conflitti.
Sequenziare la migrazione. Iniziare spostando la configurazione del dispositivo che ha una mappatura 1:1 con un CSP, abilitare “MDM wins over GPO” per quelle categorie, verificare il risultato, quindi scollegare o disabilitare i GPO corrispondenti.

Per i dispositivi co-gestiti, assicurarsi anche che le baseline di configurazione di ConfigMgr o le impostazioni di Endpoint Protection non duplichino gli stessi controlli dei criteri di Intune. Un’unica fonte autorevole per ogni controllo evita risultati imprevedibili.

Collegamento al cloud: CMG e collegamento del tenant

Cloud Management Gateway (CMG) consente a ConfigMgr di gestire i client basati su Internet senza richiedere una VPN. Il CMG viene eseguito in Azure come servizio PaaS (preferibilmente su Virtual Machine Scale Sets) e funge da proxy per la comunicazione dei client verso il sito on-premise tramite il punto di connessione CMG. Le funzionalità includono policy per i client, inventario hardware/software, distribuzioni di app, script, CMPivot e aggiornamenti software (Software Updates) quando i client sono configurati per la gestione basata su Internet. Requisiti principali e punti di progettazione:

Sottoscrizione e gruppo di risorse Azure, con il sito ConfigMgr collegato al tenant di Azure AD.
Certificati e autenticazione: utilizzare l’autenticazione di Azure AD per i client quando i dispositivi sono aggiunti in modalità ibrida ad Azure AD (hybrid/Azure AD–joined) e il sito utilizza l’HTTP avanzato (Enhanced HTTP). I certificati di autenticazione client PKI rimangono supportati ma aumentano la complessità.
Ruoli on-premise: distribuire un punto di connessione CMG e assicurarsi che il punto di connessione del servizio (service connection point) sia online per la connettività al cloud.
Costo e capacità: dimensionare le istanze in base alle connessioni simultanee previste e al throughput dei contenuti; monitorare l’utilizzo per ottimizzare i costi.
Contenuti: utilizzare il CMG per le policy e la scansione degli aggiornamenti. Per la distribuzione dei contenuti, combinarlo con i punti di distribuzione cloud (cloud distribution points) o abilitare i contenuti tramite CMG, se supportato dalla versione del sito.

Il collegamento del tenant (tenant attach) espone l’inventario dei dispositivi e le azioni di ConfigMgr nel centro di amministrazione di Microsoft Intune senza richiedere la co-gestione. Quando si abilita l’opzione “Carica nel centro di amministrazione di Microsoft Endpoint Manager” (Upload to Microsoft Endpoint Manager admin center), i dispositivi appaiono sotto “Dispositivi” (Devices) nel portale di Intune con ConfigMgr come autorità di gestione. È possibile eseguire azioni come:

Eseguire query CMPivot e script
Visualizzare dati simili a quelli di Esplora risorse (Resource Explorer) e la timeline del dispositivo
Installare applicazioni disponibili da ConfigMgr
Avviare azioni client (in base alla versione e alle autorizzazioni)

Il collegamento del tenant integra il RBAC di Azure AD/Intune con il RBAC di ConfigMgr. Per i client Internet, le azioni in tempo reale richiedono il CMG; per i client intranet, le azioni passano attraverso i punti di gestione on-premise. Il collegamento del tenant completa la co-gestione fornendo una console cloud unificata e abilitando le attività di helpdesk senza concedere l’accesso alla console di ConfigMgr.

Scenario pratico

Contoso, Ltd. ha 5.000 dispositivi Windows 10/11 gestiti da Configuration Manager in più siti. Il lavoro da remoto è aumentato e molti dispositivi si connettono raramente alla VPN. Contoso vuole applicare l’accesso condizionale (Conditional Access) basato sulla conformità dei dispositivi, spostare i controlli di sicurezza nel cloud e gestire i dispositivi basati su Internet senza dipendere dalla VPN, evitando al contempo una migrazione “big-bang”.

Stabilire le fondamenta per identità e dispositivi

Abilitare l’hybrid Azure AD join tramite Azure AD Connect per tutti i dispositivi aggiunti al dominio e verificare gli oggetti dispositivo in Azure AD. Scegliere la sincronizzazione degli hash delle password (Password Hash Synchronization) per un accesso resiliente e a bassa manutenzione e abilitare il Seamless SSO.
Perché: l’hybrid join fornisce l’identità del dispositivo in Azure AD e i token necessari per la registrazione automatica in co-gestione (co-management auto-enrollment) e per l’accesso condizionale (Conditional Access). La PHS (Password Hash Synchronization) semplifica le operazioni e fornisce un fallback sul cloud.

Configurare la co-gestione con registrazione graduale

In ConfigMgr, eseguire la procedura guidata di co-gestione (Co-management wizard) per connettere il sito al tenant di Azure AD e definire una raccolta pilota per la registrazione MDM automatica in Intune.
Perché: la co-gestione aggiunge il canale MDM di Intune senza richiedere il reimaging o l’intervento dell’utente, consentendo a Contoso di spostare i carichi di lavoro gradualmente.

Spostare il carico di lavoro delle policy di conformità (Compliance policies) su Intune (Pilota → Tutti)

Creare policy di conformità in Intune che riflettano le baseline di Contoso (crittografia, Defender, versioni del sistema operativo) e abilitare le policy di accesso condizionale (Conditional Access) che richiedono dispositivi conformi per Microsoft 365.
Perché: Intune è l’autorità di conformità che si integra con l’accesso condizionale di Azure AD; spostare questo carico di lavoro abilita un controllo degli accessi sicuro.

Distribuire la sicurezza degli endpoint (Endpoint security) tramite Intune; ritirare le policy EP di ConfigMgr sovrapposte

Creare policy di sicurezza degli endpoint per Defender Antivirus, Firewall e BitLocker in Intune e spostare il carico di lavoro di protezione degli endpoint (Endpoint protection) su Intune per il gruppo pilota. Disabilitare le impostazioni antimalware e BitLocker equivalenti di ConfigMgr per la raccolta pilota.
Perché: la sicurezza degli endpoint di Intune utilizza CSP ottimizzati per la gestione moderna e fornisce report chiari e allineamento con l’accesso condizionale (CA).

Migrare la configurazione dei dispositivi su Intune con controllo dei conflitti

Creare profili dal catalogo delle impostazioni (Settings Catalog) per restrizioni dei dispositivi, Wi-Fi e certificati. Distribuire la policy di controllo MDMWinsOverGP dove supportata, convalidarla sui piloti, quindi scollegare le GPO corrispondenti.
Perché: assicura una transizione di proprietà pulita ed evita il “policy churn” (conflitti e sovrascritture) causato dalla sovrapposizione di GPO e MDM.

Implementare il Cloud Management Gateway

Distribuire il CMG utilizzando l’autenticazione di Azure AD e l’HTTP avanzato (Enhanced HTTP), e aggiungere un punto di connessione CMG. Verificare che i client basati su Internet ricevano policy, inventario e aggiornamenti software.
Perché: il CMG fornisce la gestione e gli aggiornamenti di ConfigMgr via Internet per i dispositivi che non utilizzano la VPN, mantenendo la continuità durante la migrazione.

Abilitare il collegamento del tenant per operazioni unificate

Configurare l’opzione “Carica nel centro di amministrazione di Microsoft Endpoint Manager” per rendere visibili i dispositivi di ConfigMgr nel portale di Intune. Concedere al personale dell’helpdesk i ruoli Intune appropriati per eseguire CMPivot e installare app.
Perché: il collegamento del tenant consolida le azioni quotidiane in una console web, riducendo la dipendenza dalla console completa di ConfigMgr e migliorando la risoluzione dei problemi da remoto.

Espandere i carichi di lavoro e dismettere i controlli legacy

Spostare la configurazione dei dispositivi (Device configuration) e le app client (Client apps) su Intune in più fasi. Per Windows Update, valutare il passaggio a Windows Update for Business o mantenere gli aggiornamenti software (Software Updates) in ConfigMgr dove il CMG è sufficiente. Rimuovere le GPO e le baseline di ConfigMgr sovrapposte man mano che la proprietà viene trasferita.
Perché: un approccio graduale riduce i rischi, mantiene i dispositivi sicuri durante tutto il processo e si allinea con gli obiettivi cloud-first di Contoso, preservando al contempo le funzionalità on-premise necessarie durante la transizione.

← Identità · Tutti i domini · Ciclo di vita di Windows e gestione degli aggiornamenti →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →