• Cloud, Guide, Microsoft 365, Sicurezza
• 7 Novembre 2026

Durante le sessioni tecniche dei miei corsi e nei panel delle conferenze dedicate a Microsoft Intune, questa è senza dubbio una delle domande che mi sento rivolgere più spesso: cosa succede quando la stessa identica impostazione viene configurata sia tramite una cara vecchia Group Policy di dominio sia attraverso un profilo moderno distribuito dal cloud? La preoccupazione è legittima, perché vedere un client rimbalzare tra due configurazioni opposte è l’incubo di ogni amministratore di sistema.

Il punto di partenza fondamentale che dovete sempre tenere a mente riguarda il comportamento predefinito del sistema operativo. Se non intervenite manualmente sulle impostazioni di risoluzione dei conflitti, le Group Policy vincono sempre sui criteri MDM. Windows 10 e Windows 11 nascono infatti con una gerarchia rigida in cui il motore locale delle GPO ha la precedenza assoluta, lasciando soccombere il Configuration Service Provider (CSP) di Intune.

Questo meccanismo di fallback tutela la stabilità iniziale ma, nella vita reale dei vostri ambienti di produzione, crea una forte discrepanza tra ciò che configurate a pannello su Intune e ciò che il client applica realmente. Sebbene le due tecnologie scrivano in rami di registro del tutto separati (le GPO storicamente sotto SOFTWARE \Policies e Intune sotto l’albero di SOFTWARE\Microsoft\PolicyManager) il sistema operativo continuerà a dare priorità di lettura alle impostazioni di Active Directory, lasciando i profili cloud apparentemente ignorati o non operativi. Capite bene che trovarsi con policy MDM distribuite ma silenti complica notevolmente la gestione e rende frustrante qualsiasi attività di troubleshooting sulle macchine dei vostri utenti.

A proposito, avete già dato un’occhiata alla mia guida Funzionamento delle Group Policy (GPO) in Windows Server: facciamo un po’ di chiarezza – ICT Power?

Per fortuna non siete costretti a subire passivamente questa gerarchia predefinita, perché Microsoft mette a disposizione una leva specifica pensata proprio per ribaltare questo equilibrio e dare pieno potere al cloud.

Figura 1: Percorso nel Registro di sistema di Windows per i criteri MDM/Intune

Il criterio MDMWinsOverGP e la configurazione via Intune

Per consentirvi di gestire la transizione senza dover azzerare di colpo le policy esistenti, Microsoft ha introdotto all’interno del Policy CSP un’impostazione specifica denominata ControlPolicyConflict/MDMWinsOverGP. Il funzionamento di questo switch logico è lineare ma radicale: per impostazione predefinita il valore è 0, assegnando la vittoria alla GPO; se invece impostate il parametro su 1, istruite il motore locale di Windows a invertire l’ordine di valutazione. Nel momento in cui il sistema operativo rileva una collisione sullo stesso parametro, il criterio MDM prende il sopravvento e l’elaborazione della Group Policy concorrente viene formalmente bloccata sul client locale.

Prima di passare alla configurazione, conviene chiarire subito il perimetro di questa impostazione. MDMWinsOverGP è un parametro che si applica a livello di dispositivo (scope Device) e non è disponibile per le assegnazioni a livello utente. È supportato a partire da Windows 10 versione 1803. Inoltre non copre qualsiasi voce del Policy CSP, ma solo quelle che hanno una Group Policy equivalente, cioè le impostazioni ADMX-backed o mappate: è soltanto in questi casi che Windows riesce a collegare una policy MDM alla relativa GPO e a bloccarla. L’elenco completo è nella pagina Microsoft Policies in Policy CSP supported by Group Policy.

A questo punto vi starete chiedendo: perché attivare questo override da Intune e non configurarlo direttamente tramite una Group Policy di Active Directory? Il motivo è puramente architetturale. Questa impostazione nasce e risiede esclusivamente all’interno del Policy CSP di Windows, e Microsoft non ha implementato alcun template amministrativo (.admx) per esporla nel motore classico delle GPO. La decisione è strategica: per sancire il passaggio di consegne verso la gestione moderna, è indispensabile che sia il controller cloud a reclamare la titolarità della configurazione, evitando che una policy locale di dominio possa inavvertitamente disattivare o manomettere la precedenza assegnata a Intune.

Per distribuire questa direttiva vi basta accedere al portale di Microsoft Intune admin center e creare un profilo di configurazione basato sul Settings Catalog per dispositivi Windows 10 e successivi. All’interno del catalogo delle impostazioni cercate la categoria Control Policy Conflict e selezionate la voce MDM Wins Over GP, impostandola sull’opzione The MDM policy is used and the GP policy is blocked. Una volta assegnato il profilo al gruppo di dispositivi target, le macchine cominceranno ad applicare la preferenza al primo ciclo di sincronizzazione utile.

Figura 2: Configurazione per bloccare l’elaborazione delle Group Policy

Un aspetto da tenere presente riguarda il ripristino dello stato iniziale. Se riportate il valore di MDMWinsOverGP a 0 oppure eliminate la policy, Windows rimuove il blocco sulle Group Policy e ripristina quelle che aveva messo da parte, così il motore locale delle GPO torna a far valere le impostazioni di dominio.

Il comportamento è quindi reversibile e non lascia i dispositivi senza configurazione. Diverso è il caso in cui revochiate l’assegnazione del profilo o rimuoviate del tutto il dispositivo dalla gestione Intune: il ritorno al comportamento standard dipende da come la policy viene effettivamente rimossa sul client. Prima di una dismissione su larga scala vi consiglio quindi di provare su una macchina di test, verificando che il valore sotto la chiave ControlPolicyConflict sia tornato a 0 o sia scomparso e che le GPO risultino di nuovo applicate (ad esempio con gpupdate /force seguito da gpresult /r). Maggiori info sono disponibili alla pagina ControlPolicyConflict Policy CSP | Microsoft Learn

Dove MDMWinsOverGP non arriva: il caso Windows Update

Attenzione, però: MDMWinsOverGP non risolve tutti i conflitti. Funziona solo sulle impostazioni del Policy CSP che hanno una GPO equivalente. Tutto quello che passa da altri CSP, come BitLocker, Windows Defender Firewall o Defender, resta fuori e segue regole proprie. Se in un progetto di migrazione vi sembra che l’override “non funzioni”, molto spesso il motivo è questo.

Il caso che incontro più spesso è Windows Update for Business. Se gestite gli aggiornamenti tramite anelli di distribuzione (Update Rings) su Intune e contemporaneamente avete attive delle vecchie GPO che puntavano a un server WSUS on-premises o imponevano finestre di manutenzione legacy, affidarsi a MDMWinsOverGP è un errore. Microsoft documenta chiaramente che ControlPolicyConflict non si applica all’Update Policy CSP.

Per risolvere alla radice il problema su Windows Update dovete invece ricorrere al parametro dedicato presente nell’Update Policy CSP, denominato IgnoreWindowsUpdateGroupPolicies (documentato da Microsoft nella guida ufficiale al Policy CSP – Update). Configurando questo valore tramite Intune, ordinate esplicitamente all’agente di aggiornamento locale di ignorare qualsiasi Group Policy di dominio relativa a Windows Update, assicurando che i tempi di deferral, le scadenze e i canali qualitativi stabiliti su Intune abbiano efficacia immediata e senza interferenze da parte di Active Directory.

Occhio ai requisiti: il parametro è supportato da Windows 11 24H2 con l’aggiornamento KB5101684 (build 26100.8973) o successivi. Su Windows 10 o su build più vecchie non produce alcun effetto, quindi controllate la versione dei client prima di dare la colpa alla configurazione.

Per distribuirlo, dall’Intune admin center andate in Devices > Windows > Configuration e create una nuova policy per Windows 10 and later con profilo Settings Catalog. Cliccate su Add settings, cercate Ignore Windows Update Group Policies, selezionate la categoria Windows Update for Business e portate il valore su Enabled.

Dopo aver completato l’assegnazione al gruppo di computer desiderato, al primo check-in utile il client Windows scriverà il valore 1 nella chiave di registro HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update\IgnoreWindowsUpdateGroupPolicies. Da quel momento in poi, l’agente di Windows Update ignorerà completamente le impostazioni legacy presenti sotto il percorso HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate, lasciando il controllo esclusivo agli anelli di aggiornamento gestiti da Intune.

C’è da aggiungere però che l’agente di Windows non elimina le GPO né le chiavi di registro e non ferma l’aggiornamento delle policy: Windows Update semplicemente non le legge. Se disattivate il bypass, tornano valide. Questo ha un peso pratico nel troubleshooting, perché le chiavi sotto Policies restano visibili nel registro anche quando sono ignorate.

Figura 3: Configurazione del parametro “Ignore Windows Update Group Policies” all’interno del Settings Catalog di Microsoft Intune

Verifica sul campo e troubleshooting: dove guardare sul client

Una volta distribuite le policy tramite Intune e completato il ciclo di sincronizzazione sulla macchina di test, vorrete sicuramente toccare con mano l’effettiva applicazione del blocco senza dover aspettare anomalie sul campo. Per verificare che il client stia effettivamente premiando Intune, avete a disposizione due strumenti principali: il Registro di sistema e il Visualizzatore eventi di Windows.

Nel Registro di sistema potete osservare direttamente come Windows gestisce l’assegnazione dei criteri MDM. Visualizzate la chiave HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\ControlPolicyConflict, troverete il valore DWORD denominato MDMWinsOverGP impostato a 1. Questo valore certifica che il motore di gestione locale ha recepito l’ordine di ribaltamento della priorità. Allo stesso modo, se avete configurato il blocco dedicato agli aggiornamenti, sotto il percorso HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update vedrete comparire la chiave IgnoreWindowsUpdateGroupPolicies con valore 1.

Figura 4: Verifica nel Registro di sistema dell’avvenuta applicazione del criterio

Figura 5: Verifica nel Registro di sistema dell’avvenuta applicazione del criterio

Per avere la certezza assoluta che una Group Policy concorrente sia stata formalmente intercettata e scartata, il vostro punto di riferimento è il registro eventi dedicato all’MDM. Aprite l’Event Viewer e navigate fino al percorso Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Operational.

All’interno di questo log operativo troverete eventi registrati con Event ID 831 e Event ID 832. Nel dettaglio del messaggio, Windows descrive chiaramente il conflitto rilevato, specificando il nome della policy, l’identificativo dell’area e indicando esplicitamente che la Group Policy di dominio è stata ignorata in favore dell’impostazione distribuita via MDM.

NOTA: questi due eventi vengono generati solo e soltanto nel momento esatto in cui si verifica una collisione reale tra una GPO applicata e una policy MDM concorrente.

Per verificare che la policy sia stata applicata potete navigare in Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin e cercare l’ Event ID 2215.

Figura 6: l’Event ID 2215 conferma che il client ha recepito la direttiva da Intune impostando il valore di MdmWinsOverGp su 0x1

Un altro metodo rapido e molto pulito per ottenere un quadro completo consiste nell’esportazione dell’MDM Diagnostic Report. Dalle Impostazioni di Windows, spostandovi in Account > Accedi all’azienda o all’istituto di istruzione, vi basta cliccare sul vostro account, entrare in Informazioni e premere il pulsante Crea report. Aprendo il file HTML generato (salvato di default sotto C:\Users\Public\Documents\MDMDiagnostics\MDMDiagReport.html), potrete consultare una comoda tabella riassuntiva che elenca tutte le direttive CSP applicate, confermandovi a colpo d’occhio che i profili cloud risultano attivi e operativi.

Figura 7: Nel report diagnostico MDM (MDMDiagReport.html) la sezione ControlPolicyConflict mostra il parametro MDMWinsOverGP applicato con successo al target device con valore 1

Usare Group Policy Analytics per una migrazione pulita

Sebbene abilitare MDMWinsOverGP e IgnoreWindowsUpdateGroupPolicies rappresenti una soluzione tecnica impeccabile per disinnescare i conflitti nell’immediato, non dovete considerare questi override come una configurazione definitiva da mantenere a vita. Lasciare che due motori di gestione continuino a contendersi l’assegnazione delle policy sul client introduce complessità inutile, appesantisce le attività di diagnostica e va contro il principio stesso di una gestione moderna snella.

Il vostro obiettivo finale deve rimanere la dismissione progressiva delle vecchie policy on-premises a favore dei soli profili cloud. Per guidarvi in questo passaggio senza procedere alla cieca, la console di Microsoft Intune mette a disposizione uno strumento fondamentale: Group Policy Analytics.

Questo strumento vi consente di esportare il report XML delle vostre Group Policy (tasto destro sulla GPO › Salva report) direttamente dalla console di gestione di Active Directory (GPMC) e caricarli all’interno del portale di Intune. Il motore di analisi esamina ogni singola voce presente nei file e restituisce un report dettagliato indicando la percentuale esatta di compatibilità con i moderni CSP di Windows, evidenziando se il parametro è supportato nativamente nel Settings Catalog, se richiede configurazioni alternative o se risulta ormai deprecato per i moderni client.

Trovate maggiori dettagli nella mia guida Microsoft Intune – Migrare le Group Policy con Group Policy Analitycs – ICT Power

Figura 8: La dashboard di Group Policy analytics in Microsoft Intune

Una volta mappati i criteri e creati i corrispettivi profili di configurazione su Intune, la procedura corretta per chiudere il cerchio consiste nell’isolare l’ambito di applicazione delle GPO legacy. Potete farlo rimuovendo progressivamente i computer migrati dalle Unità Organizzative (OU) storiche di Active Directory, oppure sfruttando il filtraggio di sicurezza basato su gruppi per negare l’applicazione delle GPO alle macchine già gestite in cloud. In questo modo eliminerete la sovrapposizione alla radice, liberando i vostri endpoint dalla dipendenza dalle policy di dominio e completando una transizione trasparente, ordinata e priva di disservizi per gli utenti.

Conclusioni

Gestire la coesistenza tra Active Directory locale e Microsoft Intune richiede consapevolezza dell’architettura sottostante di Windows. Sapere che di default la Group Policy ha sempre la priorità vi permette di comprendere immediatamente anomalie apparentemente inspiegabili sui client, mentre l’adozione consapevole di MDMWinsOverGP e del parametro dedicato agli aggiornamenti IgnoreWindowsUpdateGroupPolicies vi fornisce gli strumenti tecnici necessari per governare la fase di transizione senza subire blocchi operativi.

Ricordate sempre che questi override rappresentano un ponte, non la destinazione finale: sfruttate gli strumenti di analisi come Group Policy Analytics per ripulire progressivamente la vostra infrastruttura legacy, pianificate il disaccoppiamento a livello di OU e puntate a una gestione interamente cloud-native per garantire scalabilità, semplicità e sicurezza ai vostri endpoint.