Da Group Policy a Intune — Una guida alla migrazione della gestione dispositivi per le PMI

«La finestra di supporto del server è scaduta, quindi stiamo pianificando una sostituzione. Ma abbiamo perso la fiducia che dovremmo comprare un altro server AD e far girare il dominio e Group Policy per un altro ciclo (cinque anni).» «La Group Policy che abbiamo deciso in ufficio non si applica mai ai portatili usati per il lavoro da remoto. Se si applica solo quando si connettono alla VPN, possiamo davvero dire che li stiamo gestendo?» — Negli ultimi anni, questo tipo di consulenza dai clienti delle piccole e medie imprese è aumentato in modo costante.

Lo sfondo è un cambio nel modo di lavorare. Active Directory (AD) on-premises e Group Policy (GPO) sono un meccanismo che assume «il PC è sulla LAN aziendale e può sempre raggiungere un domain controller». Ora che i PC portati a casa e il lavoro da remoto sono la norma, è quella assunzione che si è rotta. Sopra a questo, WSUS — a lungo il default per la gestione degli aggiornamenti — è stato deprecato a settembre 2024,¹ e il baricentro della gestione dispositivi Microsoft si è spostato su Entra ID più Intune (MDM).

flowchart TB
    accTitle: L'assunzione rotta e lo spostamento del baricentro
    accDescr: AD e GPO assumono che il PC è sulla LAN aziendale e può sempre raggiungere un domain controller, ma i PC portati a casa e il lavoro da remoto come norma hanno rotto quella assunzione, e con WSUS deprecato il baricentro della gestione si è spostato su Entra ID e Intune
    adgpo["AD on-prem e GPO"] -.-> premise["Assunzione: il DC è sempre raggiungibile"]
    work["PC portati a casa e lavoro da remoto come norma"] --> broken["È l'assunzione che si è rotta"]
    premise --> broken
    wsus["WSUS è deprecato"] --> shift["Il baricentro si sposta su Entra ID+Intune"]
    broken --> shift

Figura 1: L’assunzione AD+GPO che «il PC è sulla LAN aziendale» si è rotta al cambiare dei modi di lavorare, e il baricentro della gestione si è spostato su Entra ID+Intune.

Detto questo, la migrazione non è tutto o niente. I PC gestiti con Entra join più Intune e i PC che sono domain-joined AD più GPO possono coesistere nella stessa azienda,² e una migrazione a stadi è possibile: lasciare AD per il file server, e passare i PC nuovi alla gestione Intune. Rivolto al personale IT e ai titolari delle piccole e medie imprese, questo articolo organizza — ancorato a fonti primarie come Microsoft Learn ad agosto 2026 — le differenze di come funzionano GPO e MDM, le configurazioni prerequisito, le licenze, come inventariare le GPO attuali, uno scenario di migrazione a stadi e le insidie.

1. Prima di tutto, la conclusione

• GPO si applica quando il PC è connesso alla rete di dominio; Intune (MDM) sincronizza su internet. Il problema di «le impostazioni non arrivano mai a un PC di casa» non nasce strutturalmente con MDM. La sincronizzazione a regime è circa ogni 8 ore, e gira anche una sincronizzazione guidata da notifica quando la policy cambia.³
• La migrazione non è tutto o niente; una migrazione a stadi che assume la coesistenza è la risposta realistica. Microsoft stessa raccomanda di fare Entra-join dei PC nuovi, e di lasciare i PC domain-joined esistenti come hybrid join e sostituirli sul ciclo di rinnovo hardware.²
• Potete sottoscrivere Intune da sola, ma per le piccole e medie imprese il percorso realistico è usare Intune Plan 1 incluso in Microsoft 365 Business Premium (ad agosto 2026). La composizione dei piani continua a cambiare, quindi confermate sempre le fonti primarie prima di firmare.⁴⁵
• Per inventariare le GPO attuali, usate Group Policy analytics incorporato in Intune. Importate un export XML di GPO e ogni impostazione viene classificata per se può migrare; le impostazioni che hanno un corrispondente si possono convertire in una policy Settings catalog.⁶
• I lavori principali dell’era GPO hanno quasi tutti un corrispondente Intune. I Administrative Templates mappano al Settings catalog,⁷ WSUS a Windows Update for Business, le chiavi di recupero BitLocker all’archiviazione in Entra ID,⁸ le password di amministratore locale a Windows LAPS,⁹ e la distribuzione di app a Win32 apps (.intunewin)¹⁰ e Microsoft Store apps (basate su winget).¹¹
• Le cose classiche che non si spostano così come sono sono gli script di logon, le mappe unità e la distribuzione delle stampanti. Le sostituite con la distribuzione di script PowerShell,¹² Remediations (un tempo Proactive remediations),¹³ trasformando il lavoro in un’app, o «fermare quella pratica».
• Non distribuite la stessa impostazione sia da GPO sia da MDM. Per default GPO vince un conflitto. Impostare MDMWinsOverGP a 1 fa vincere MDM, ma si applica solo alle impostazioni Policy CSP.¹⁴
• Le macchine domain-joined e le macchine Entra-joined possono coesistere, e una macchina Entra-joined può accedere a un file server on-premises. Il ritiro immediato di AD non è una condizione della migrazione.²

In una frase: la domanda «dovremmo sostituire il server AD per un altro ciclo» andrebbe riformulata come «per i prossimi cinque anni, cosa useremo per gestire i PC che stanno fuori dall’ufficio» e decisa su quella base.

flowchart LR
    accTitle: Riformulare la domanda su cui dovreste decidere
    accDescr: La domanda se sostituire il server AD per un altro ciclo andrebbe riformulata come la domanda di cosa userete per gestire i PC fuori sede per i prossimi cinque anni
    q1["Sostituire il server AD per un altro ciclo?"] -->|Riformulare| q2["Per i prossimi 5 anni, cosa gestisce i PC fuori sede?"]

Figura 2: Riformulate la domanda di sostituzione del server come «per i prossimi cinque anni, cosa useremo per gestire i PC che stanno fuori dall’ufficio» e decidete su quella base.

2. Come differiscono GPO e MDM — Confrontare i meccanismi di applicazione

Prima, confrontate i due sullo stesso campo. Il meccanismo GPO in sé (l’ordine di applicazione LSDOU, come confermare con gpupdate/gpresult) è coperto in profondità in «Una guida pratica a Group Policy (GPO)», quindi qui restringiamo alle differenze che contano per la decisione di migrazione.

Le righe più importanti per la decisione di migrazione sono la prima e la terza. Che GPO non raggiunga un PC di casa non è un bug — è che l’assunzione di progetto «il PC sta dove può raggiungere un domain controller» non coincide più con come le persone lavorano oggi. Potete tenere GPO in vita forzando always-on VPN su ogni dipendente, ma quello è anche una scelta di prendersi in carico il mantenimento di un pezzo di infrastruttura a parte: la piattaforma VPN.

flowchart TB
    accTitle: La scelta tra tenere GPO in vita e migrare a MDM
    accDescr: Che GPO non raggiunga un PC di casa è perché l'assunzione di progetto non coincide più con come le persone lavorano oggi, e il percorso di forzare always-on VPN per tenere GPO in vita è una scelta di prendersi in carico il mantenimento di un pezzo di infrastruttura a parte, la piattaforma VPN
    gap["L'assunzione di progetto non coincide più con come le persone lavorano"] --> sel{"Come rispondete?"}
    sel -->|Tenetela in vita con always-on VPN| vpn["Continuare GPO"]
    sel -->|Migrate a MDM| mdm["Gestire su internet"]
    vpn --> cost["Vi prendete in carico il mantenimento di altra infrastruttura"]

Figura 3: Il percorso di tenere GPO in vita con always-on VPN è anche una scelta di prendersi in carico il mantenimento di un pezzo di infrastruttura a parte: la piattaforma VPN.

Dall’altro lato, l’intervallo di sincronizzazione MDM (circa 8 ore) è più grosso del refresh periodico di GPO (circa 90 minuti), e la sensazione di «la distribuisci e si applica subito» non si porta dietro. Quando assegnate o cambiate una policy viene inviata una notifica al dispositivo e sincronizza in modo relativamente pronto,³ ma i controlli che richiedono immediatezza (un blocco di emergenza, e simili) vanno progettati intorno all’intervallo di sincronizzazione.

flowchart TB
    accTitle: Come GPO e MDM applicano la policy
    accDescr: GPO si applica solo quando il PC può connettersi a un domain controller interno, quindi un PC di casa dipende dalla VPN; Intune sincronizza su internet circa ogni 8 ore e sincronizza anche su una notifica quando la policy cambia, quindi raggiunge un PC ovunque sia
    officepc["Un PC interno"] --> dc["Domain controller"]
    officepc -.-> when["Avvio e accesso"]
    when -.-> when2["più refresh periodico"]
    homepc["Un PC di casa"] --> vpn{"Raggiunge il DC su VPN?"}
    vpn -->|Sì| dc
    vpn -->|No| miss["La policy non arriva mai"]
    anypc["Un PC ovunque sia"] --> intune["Servizio Intune"]
    anypc -.-> every["Sincronizzazione circa ogni 8h"]
    intune -.-> notify["Cambio guidato da notifica"]
    dc ~~~ homepc
    miss ~~~ anypc

Figura 4: GPO si applica solo quando il PC può raggiungere un domain controller; Intune sincronizza su internet indipendentemente dalla posizione.

3. Riordinare i prerequisiti — Le tre forme: Domain Join, Hybrid Join e Entra Join

Ci sono tre forme di «come un PC Windows si unisce all’azienda», e quale scegliete determina quali strumenti di gestione potete usare.²

Hybrid join è una forma per «dare a un PC già domain-joined un’identità cloud», e vi consente di iniziare a usare Intune e Conditional Access tenendo gli asset esistenti. Microsoft, però, raccomanda di non fare di hybrid join l’obiettivo finale, e di fare Entra-join dei PC nuovi e di sostituzione.²

C’è un vincolo da interiorizzare qui. Non c’è un modo supportato da Microsoft per convertire un PC già domain-joined (incluso hybrid join) in Entra join; è richiesto un reset Windows (wipe). Per questo Microsoft raccomanda anche di passare a Entra join al momento del rinnovo hardware o della reinstallazione OS.²

flowchart TB
    accTitle: Le tre forme di join e i percorsi di migrazione
    accDescr: Un PC solo domain-joined AD può essere registrato anche in Entra ID e diventare hybrid join, ma non c'è un modo per convertirlo direttamente in Entra join e serve un wipe, quindi si raccomanda di fare Entra-join dei PC nuovi e di sostituzione
    adonly["Solo domain join AD （GPO）"] -->|Registrate anche in Entra ID| hybrid["hybrid join （GPO e Intune）"]
    hybrid -.->|Nessun percorso di conversione diretta| wipe["È richiesto un wipe （reset）"]
    wipe --> entra["Entra join （Intune）"]
    newpc["PC nuovi e di sostituzione"] -->|Raccomandato| entra

Figura 5: Non c’è un modo supportato per convertire una macchina già domain-joined in Entra join; il pattern consolidato è passare dai PC nuovi e di sostituzione.

Da quanto sopra, un obiettivo realistico per una piccola o media impresa si può mettere così.

1. Gestire i PC nuovi e di sostituzione con Entra join più Intune
2. Lasciare i PC domain-joined esistenti così e lasciarli sostituire naturalmente sul ciclo di rinnovo hardware
3. Lasciare AD per il momento per i ruoli restanti come l’autenticazione del file server, e svuotare i contenuti di GPO a stadi

flowchart TB
    accTitle: Una configurazione di coesistenza durante la migrazione a stadi
    accDescr: Le macchine Entra-joined e le macchine domain-joined possono coesistere nello stesso ambiente aziendale; le prime sono gestite con Intune e le seconde con GPO, mentre AD è lasciato per i ruoli restanti e solo i contenuti di GPO vengono svuotati a stadi
    env["Lo stesso ambiente aziendale"] --> ejoin["Macchine Entra-joined"]
    env --> djoin["Macchine domain-joined"]
    ejoin --> intune["Gestite con Intune"]
    djoin --> gpo["Gestite con GPO"]
    gpo -.-> shrink["Svuotare i contenuti a stadi"]
    env -.-> ad["Lasciare AD per i ruoli restanti"]

Figura 6: Le macchine Entra-joined e le macchine domain-joined possono coesistere nello stesso ambiente aziendale, e AD è lasciato per il momento per i ruoli restanti.

Le macchine Entra-joined e le macchine domain-joined possono coesistere nello stesso ambiente, e una macchina Entra-joined può accedere ad asset interni come un file server on-premises.² Quel single sign-on, però, ha due prerequisiti. (1) L’utente è un’identità ibrida sincronizzata da AD on-prem con Entra Connect (o Cloud Sync) (un utente che esiste solo nel cloud non può ottenere credenziali Kerberos/NTLM AD), e (2) il PC ha raggiungibilità di rete verso un domain controller (da fuori sede, è richiesta una VPN o simile).¹⁵ Nel piano di migrazione, confermate prima che non ci siano utenti o scenari di uso che falliscono questi due punti.

flowchart TB
    accTitle: Prerequisiti per l'SSO da una macchina Entra-joined agli asset on-premises
    accDescr: Per accedere a un file server on-premises da una macchina Entra-joined, devono essere soddisfatti due prerequisiti: un'identità ibrida sincronizzata con Entra Connect o simile, e la raggiungibilità di un domain controller
    pc["Macchina Entra-joined"] --> cond1{"Identità ibrida?"}
    cond1 -->|Sì| cond2{"Può raggiungere un DC?"}
    cond1 -->|No| ng1["Non può ottenere credenziali AD"]
    cond2 -->|Sì| ok["SSO verso il file server"]
    cond2 -->|No| ng2["Da fuori sede, è richiesta una VPN o simile"]

Figura 7: L’SSO da una macchina Entra-joined agli asset on-premises ha due prerequisiti: un’identità ibrida e la raggiungibilità di un domain controller.

4. Licenze e costo — Quali piani includono Intune (ad agosto 2026)

La licenza Intune di base è Microsoft Intune Plan 1, offerta sia come abbonamento standalone sia raggruppata in vari piani Microsoft 365.⁴

Ciò che conta per le piccole e medie imprese è che Microsoft 365 Business Premium, fino a 300 utenti, include Intune Plan 1.⁵ Business Premium include anche Microsoft Entra ID P1 e Microsoft Defender for Business, quindi la configurazione policy di conformità più Conditional Access descritta più avanti si può completare dentro questo piano. Business Standard/Basic, invece, non includono Intune. Quando passate da un contratto solo mail-e-Office alla gestione dispositivi, il costo di upgrade a Business Premium è il costo effettivo di introdurre Intune.

flowchart TB
    accTitle: Come i piani PMI si relazionano a Intune
    accDescr: Business Premium fino a 300 utenti include Intune Plan 1, Entra ID P1 e Defender for Business e completa fino a Conditional Access, ma Business Standard/Basic non includono Intune
    bp["Business Premium"] -.-> cap["Fino a 300 utenti"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["Completa fino a Conditional Access"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["Non include Intune"]

Figura 8: Business Premium include Intune Plan 1 e Entra ID P1; Business Standard/Basic non includono Intune.

Ci sono due avvertenze.

• La composizione dei piani cambia spesso. Anche nel 2026, sono in corso cambi che ridistribuiscono funzionalità Intune Suite in piani Microsoft 365 più alti (E3/E5 e simili), e le revisioni di cosa è raggruppato continuano.⁴ Trattate questa sezione come ad agosto 2026, e prima di firmare confermate sempre le informazioni più recenti sulle pagine di licensing e prezzi Microsoft.
• Alcune funzionalità che potete aprire dalla UI Intune richiedono una licenza a parte. L’esempio rappresentativo è Remediations, descritto più avanti: richiede una licenza di classe Windows Enterprise E3/E5 (raggruppata in Microsoft 365 E3/E5 e simili) e non è disponibile nell’ambito di Business Premium.¹³

Il confronto di costo non è «costo di abbonamento Intune» contro «zero». Sul lato GPO state già pagando per la sostituzione hardware del server AD, le licenze Windows Server e le CAL, il costo di build, cinque anni di manutenzione, backup e risposta agli incidenti. Il confronto corretto è mettere il preventivo di sostituzione del server accanto a cinque anni di Business Premium, e poi fattorizzare la differenza di capacità di «la gestione raggiunge i PC fuori sede».

flowchart TB
    accTitle: Il modo giusto di pensare il confronto di costo
    accDescr: Anche il lato GPO incorre in costi come sostituzione del server AD, licenze e cinque anni di manutenzione, quindi mettete il preventivo di sostituzione del server accanto a cinque anni di Business Premium e poi decidete con la differenza di capacità se la gestione raggiunge i PC fuori sede fattorizzata
    gpocost["Costo di continuare GPO"] --> hw["Sostituzione server, licenze, CAL"]
    gpocost --> ops["Build, manutenzione, backup"]
    bpcost["Costo di migrare a Intune"] --> sub["Cinque anni di Business Premium"]
    hw --> diff["Mettete la differenza di cinque anni affiancata"]
    ops --> diff
    sub --> diff
    diff --> ability["Fattorizzate se la gestione raggiunge i PC fuori sede"]

Figura 9: Mettete il preventivo di sostituzione del server accanto a cinque anni di Business Premium, e decidete con la differenza di capacità di gestire i PC fuori sede fattorizzata.

5. Come fare in Intune ciò che facevate con GPO

Per ciascuno dei lavori principali delle operazioni GPO, il corrispondente Intune è mostrato in una tabella di mappatura.

Alcune note.

• Il Settings catalog è una schermata che corrisponde a «l’edizione cloud dell’editor GPO», e Microsoft stessa lo posiziona come «la destinazione di migrazione naturale quando volete configurare nello stesso modo fine-grained di una GPO on-premises». Include policy supportate da ADMX (l’edizione MDM di impostazioni definite in ADMX), e c’è anche una funzionalità (preview) per importare ADMX di terze parti.⁷
• Policy di conformità più Conditional Access è un’idea che GPO non aveva. Definite condizioni di conformità come «BitLocker acceso, OS aggiornato, Defender in esecuzione» e potete bloccare l’accesso a Microsoft 365 dai dispositivi che non le soddisfano. Conditional Access è una funzionalità Entra ID P1 ed è inclusa in Business Premium.¹⁶
• Remediations è stato rinominato da Proactive remediations. È un meccanismo che esegue periodicamente una coppia detect-script più remediate-script, e può sostituire il tipo di operazioni GPO che «sistemano qualcosa a ogni logon», ma come notato richiede una licenza di classe Windows Enterprise E3/E5.¹³ Nell’ambito di Business Premium, il sostituto realistico è combinare platform scripts (eseguiti quando lo script o l’assegnazione cambiano, e ritentati in caso di fallimento)¹² con regole di rilevamento Win32-app.
• Le scelte dettagliate per la gestione degli aggiornamenti (decidere tra WUfB, Autopatch e continuare WSUS) sono coperte in «Gestione di Windows Update dopo la deprecazione di WSUS», e il progetto di BitLocker e LAPS in «Guida pratica a BitLocker» e «Una guida pratica a Windows LAPS» rispettivamente.

flowchart TB
    accTitle: Il flusso di una policy di conformità e Conditional Access
    accDescr: Una policy di conformità giudica solo lo stato di conformità di un dispositivo rispetto alle condizioni di conformità; solo quando una policy Conditional Access richiede un dispositivo conforme i dispositivi conformi sono consentiti e quelli non conformi sono bloccati
    policy["Definite le condizioni di conformità"] -.-> cond["BitLocker acceso, OS aggiornato e simili"]
    policy --> state["Giudicate lo stato di conformità del dispositivo"]
    state --> ca["Conditional Access richiede la conformità"]
    ca -->|Conforme| allow["Accesso Microsoft 365 consentito"]
    ca -->|Non conforme| block["Accesso bloccato"]

Figura 10: Giudicare lo stato di conformità è il lavoro di una policy di conformità; bloccare è il lavoro di Conditional Access. Solo in combinazione il blocco ha effetto.

6. Inventariare le GPO attuali — Ordinare con Group Policy Analytics

Il primo lavoro reale di un piano di migrazione è inventariare le GPO attuali. Intune ha una funzionalità dedicata, Group Policy analytics, che può classificare, per impostazione, «MDM può sostituire questo» senza che dobbiate leggere le GPO a mano.⁶

I passi sono i seguenti.⁶

1. Aprite Group Policy Management Console (GPMC.msc) su un domain controller o simile, tasto destro sulla GPO obiettivo → Save Report ed esportatela come file XML (4 MB o meno per file)
2. Nel centro di amministrazione Intune, andate su Devices → Group Policy analytics e importate l’XML (è consentita la selezione multipla)
3. Dopo l’analisi automatica, ogni GPO mostra una percentuale di supporto MDM (la quota di impostazioni che hanno un equivalente in Intune)
4. Nel report Group policy migration readiness, confermate la classificazione per impostazione: Ready for migration / Not supported / Deprecated
5. Le impostazioni Ready for migration si possono convertire così come sono in una policy Settings catalog e distribuire

flowchart TB
    accTitle: Il flusso di inventario con Group Policy analytics
    accDescr: Esportate le GPO come XML da GPMC e importatele in Intune; vengono visualizzate la percentuale di supporto MDM e la prontezza di migrazione per impostazione, e le impostazioni Ready for migration si possono convertire in una policy Settings catalog
    export["Esportate le GPO come XML da GPMC"] --> import["Importate in Intune"]
    import --> rate["Viene visualizzata la percentuale di supporto MDM"]
    rate --> report["Report di prontezza di migrazione"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["Convertite in una policy Settings catalog"]

Figura 11: Dall’export XML attraverso l’import, la classificazione per impostazione e la conversione al Settings catalog — quello è il flusso di Group Policy analytics.

C’è un’avvertenza importante negli ambienti giapponesi. L’analisi delle impostazioni non-ADMX in Group Policy analytics è solo in inglese; importare una GPO che contiene impostazioni in una lingua diversa dall’inglese può rendere la percentuale di supporto MDM inaccurata.⁶ Trattate la percentuale di supporto come un valore di riferimento approssimativo, e fate il giudizio finale dall’elenco per impostazione.

flowchart TB
    accTitle: Un'avvertenza quando analizzate una GPO giapponese
    accDescr: L'analisi delle impostazioni non-ADMX in Group Policy analytics è solo in inglese, quindi una GPO che contiene impostazioni giapponesi può rendere la percentuale di supporto MDM inaccurata; trattate la percentuale come un riferimento approssimativo e fate il giudizio finale dall'elenco per impostazione
    jgpo["Una GPO che contiene impostazioni giapponesi"] --> limit["L'analisi non-ADMX è solo in inglese"]
    limit --> rate["La percentuale di supporto può essere inaccurata"]
    rate --> use1["Trattate la percentuale come un riferimento approssimativo"]
    rate --> use2["Fate il giudizio finale dall'elenco per impostazione"]

Figura 12: In una GPO giapponese la percentuale di supporto MDM può essere inaccurata, quindi fate il giudizio finale dall’elenco per impostazione.

In pratica, spezzate i risultati di classificazione in tre mucchi.

1. Impostazioni da scartare — impostazioni dell’era Internet Explorer, impostazioni per sistemi ritirati, impostazioni di cui nessuno sa spiegare il motivo. Il ritorno più grande dell’inventario è, di fatto, poter buttare via questo mucchio. Una GPO che gira da dieci anni ha una quantità considerevole di legacy accumulata.
2. Impostazioni da spostare a Intune — quelle tra Ready for migration di cui avrete ancora bisogno. Convertitele al Settings catalog e validate con un gruppo pilota.
3. Impostazioni per cui progettate un sostituto — quelle tra Not supported di cui avrete ancora bisogno. Esempi rappresentativi e direzioni di sostituzione sono i seguenti.

flowchart TB
    accTitle: I tre mucchi dei risultati di inventario
    accDescr: I risultati di inventario sono gestiti come tre mucchi: impostazioni da scartare, impostazioni da spostare a Intune e validare, e impostazioni che non hanno un corrispondente e per cui progettate un sostituto
    result["Risultati di classificazione"] --> discard["Impostazioni da scartare"]
    result --> more{"Spostare o sostituire?"}
    more --> move["Spostate a Intune"]
    more --> alt["Progettate un sostituto"]
    discard -.-> legacy["Smaltite il legacy"]
    move --> pilot["Settings catalog"]
    pilot -.-> pilotN["poi validate"]
    alt --> design["Script o fate un'app"]

Figura 13: Spezzate i risultati di inventario nei tre mucchi «scartare», «spostare a Intune» e «progettare un sostituto».

7. Uno scenario di migrazione a stadi — Cinque stadi e criteri di uscita

Spezzate il tutto in cinque stadi e mettete un criterio di uscita su ciascuno. Decidere in anticipo «quando possiamo dire che questo è fatto» è il trucco che tiene una migrazione IT da una persona sola dal bloccarsi.

flowchart TB
    accTitle: Uno scenario di migrazione in cinque stadi
    accDescr: Progredite a stadi dal pilota attraverso la policy di baseline, la distribuzione app, la sostituzione dei PC esistenti sul ciclo di rinnovo hardware e la riduzione del ruolo di AD, e alla fine portate a zero le impostazioni distribuite via GPO
    s1["（1） Pilota"] --> s2["（2） Policy di baseline"]
    s2 --> s3["（3） Distribuzione app"]
    s3 --> s4["（4） Sostituzione naturale dei PC esistenti"]
    s4 --> s5["（5） Ridurre il ruolo di AD"]
    s5 -.-> goal["Le impostazioni distribuite via GPO sono zero"]

Figura 14: Avanzate la migrazione in cinque stadi dal pilota attraverso la riduzione del ruolo di AD, e decidete in anticipo il criterio di uscita di ciascuno stadio.

I punti chiave di ciascuno stadio.

• (1) Pilota parte da un PC che stavate per comprare comunque — il prossimo PC di un assunto, una sostituzione break/fix, e simili. Partire da una macchina nuova ha il vantaggio che potete iniziare con investimento extra zero, e se fallisce potete fare wipe e ricominciare. Una volta che il conteggio cresce, considerate di usare Windows Autopilot per automatizzare da OOBE (setup iniziale) attraverso Entra join più iscrizione Intune.²
• In (2) Policy di baseline, non puntate a riprodurre ogni impostazione GPO. Prima restringete ai cinque di aggiornamento, crittografia, Defender, blocco schermo e LAPS, e visualizzate lo stato di conformità con una policy di conformità. Abilitare «solo dispositivi conformi» in Conditional Access viene dopo che avete confermato che non ci sono falsi positivi nel pilota.¹⁶
• (3) Distribuzione app è continuo con l’automazione del provisioning. Se avete già una procedura basata su winget in piedi («Automatizzare il provisioning PC con winget + PowerShell»), quell’asset si può riusare quasi così com’è come Store app (new) o un wrapper Win32-app.¹¹
• (4) PC esistenti, come ha detto il capitolo 3, non hanno un percorso di conversione a Entra join, quindi il principio è la sostituzione naturale. Le organizzazioni che hanno ancora un piano di sostituzione Windows 10 («Opzioni pratiche dopo la fine del supporto di Windows 10») possono evitare di fare il lavoro due volte avanzando quella sostituzione insieme a (4).
• In (5) Ridurre il ruolo di AD, svuotare GPO non significa necessariamente che AD è subito inutile. Se restano l’autenticazione del file server, le lookup LDAP da app legacy e simili, AD continua in forma ridotta come «server di autenticazione». Inventariare quelli e fissare scadenze è il lavoro di questo stadio.

flowchart TB
    accTitle: Cosa fare con AD dopo che GPO è vuota
    accDescr: Anche dopo che GPO è vuota, se restano l'autenticazione del file server o le lookup LDAP da app legacy, AD continua in forma ridotta come server di autenticazione, e inventariare i ruoli restanti e fissare scadenze è il lavoro dello stadio finale
    gpoempty["GPO è vuota"] --> remain{"Quali ruoli restanti ci sono?"}
    remain -->|Autenticazione del file server| keep["Continuare in forma ridotta come server di autenticazione"]
    remain -->|Lookup LDAP legacy| keep
    remain -->|Nessun ruolo restante| retire["Considerate di ritirare AD stesso"]
    keep --> task["Portate a termine inventario e fissazione delle scadenze"]

Figura 15: Anche dopo che GPO è vuota, se esistono ruoli restanti, AD continua in forma ridotta come server di autenticazione.

8. Le insidie

8.1. Doppia applicazione di GPO e MDM — Per default vince GPO

Durante il periodo di migrazione, sia GPO sia Intune distribuiranno impostazioni allo stesso PC (una macchina hybrid-joined). Qui, quando la stessa impostazione è in conflitto, Group Policy vince per default. Impostare MDMWinsOverGP di Policy CSP a 1 fa vincere l’impostazione lato MDM e blocca l’impostazione GPO corrispondente, ma quel meccanismo si applica solo alle impostazioni sotto Policy CSP e non si applica alle impostazioni definite in altri CSP come Defender CSP. Microsoft stessa afferma che se configurate un’impostazione che non è sotto MDMWinsOverGP sia da GPO sia da MDM, entrate in uno stato di conflitto e non c’è garanzia su quale vince.¹⁴

flowchart TB
    accTitle: Precedenza quando GPO e MDM sono in conflitto
    accDescr: Se distribuite la stessa impostazione sia da GPO sia da MDM, GPO vince per default; impostare MDMWinsOverGP a 1 fa vincere MDM solo per le impostazioni sotto Policy CSP, e per le impostazioni in altri CSP non c'è garanzia su quale vince
    both["Distribuite la stessa impostazione sia da GPO sia da MDM"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|No| gpowin["GPO vince （default）"]
    flag -->|Sì| csp{"Un'impostazione sotto Policy CSP?"}
    csp -->|Sì| mdmwin["MDM vince"]
    csp -->|No| unknown["Nessuna garanzia su quale vince"]
    both -.-> avoid["Il principio è non distribuire da entrambi"]

Figura 16: Per default vince GPO, e MDMWinsOverGP si applica solo sotto Policy CSP. Il principio è evitare la doppia distribuzione.

Il principio pratico è semplice. Non affidatevi al controllo di precedenza; non distribuite la stessa impostazione da entrambi. Per un’impostazione che avete spostato a Intune, rimettete la configurazione lato GPO corrispondente a «Not configured», o scollegate del tutto la GPO. L’elenco migrato del capitolo 6 è anche il registro per questo.

8.2. Dipendenza dagli asset on-premises — Unità di rete e stampanti

Molti dei posti in cui una migrazione si blocca non sono funzionalità Intune ma la connettività verso gli asset on-premises. L’accesso in sé da una macchina Entra-joined a un file server on-premises è possibile,² ma se le mappe unità e la distribuzione delle stampanti dipendevano da uno script di logon GPO, quel mezzo di distribuzione sparisce per primo. Decidete durante il pilota se piegare una migrazione di share a OneDrive/SharePoint o una sostituzione con Universal Print nello stadio (3), o fare da ponte per il momento con la distribuzione via script.¹²

flowchart TB
    accTitle: Sostituire le distribuzioni che dipendono dagli asset on-premises
    accDescr: Se le mappe unità e la distribuzione delle stampanti dipendono da uno script di logon GPO, quel mezzo di distribuzione sparisce per primo nella migrazione, quindi decidete durante il pilota se rispondere con una migrazione di share a OneDrive o SharePoint, una sostituzione con Universal Print, o la distribuzione via script per il momento
    dep["Dipendenza da uno script di logon"] --> lost["Il mezzo di distribuzione sparisce nella migrazione"]
    lost --> share["Migrate a OneDrive/SharePoint"]
    lost --> print["Sostituite con Universal Print o simile"]
    lost --> script["Fate da ponte con la distribuzione via script"]
    share --> decide["Decidete l'approccio durante il pilota"]
    print --> decide
    script --> decide

Figura 17: Le distribuzioni che dipendono da uno script di logon perdono il loro mezzo per prime nella migrazione, quindi decidete la sostituzione durante il pilota.

8.3. Riprogettare il provisioning — Autopilot non è «richiesto»

A volte vi verrà consigliato di introdurre Windows Autopilot come un set con una migrazione Intune, ma a una scala di approvvigionamento di poche o una dozzina di macchine all’anno, accedere con un account di lavoro a OOBE e fare Entra-join a mano non fa un vero danno. Autopilot inizia a ripagarsi quando il conteggio di approvvigionamento cresce e il setup non presidiato dallo scatolato ha valore, o quando potete usare la registrazione dispositivi lato rivenditore. Aggiungerlo dopo che (2) e (3) sono in piedi va bene; non è un prerequisito della migrazione.

flowchart TB
    accTitle: La decisione di introduzione di Autopilot
    accDescr: A una scala di approvvigionamento di poche o una dozzina di macchine all'anno, fare Entra-join a mano a OOBE non fa un vero danno; aggiungete Autopilot dopo, quando il conteggio di approvvigionamento è cresciuto e il setup non presidiato ha valore
    scale{"Qual è la scala di approvvigionamento annuale?"} -->|Poche o una dozzina| manual["Entra join a mano a OOBE"]
    scale -->|Una volta che il conteggio cresce| ap["Non presidiato con Autopilot"]
    ap -.-> later["Aggiungetelo dopo che （2） e （3） sono in piedi"]

Figura 18: Finché la scala di approvvigionamento è piccola, Entra join a mano basta; Autopilot si può aggiungere dopo.

8.4. Il malinteso che «non va bene se non è tutto in Intune»

L’ultimo non è un problema tecnico ma un problema di assunzione. La coesistenza di macchine Entra-joined e macchine domain-joined è una configurazione formalmente supportata,² e «AD è ancora lì = la migrazione è fallita» non è vero. Le aziende che girano per anni con alcune impostazioni ancora lasciate in GPO non sono rare, e anche allora c’è grande valore nello stato «ogni PC nuovo è gestito nel cloud, e il controllo funziona anche fuori sede». Preferite avanzamenti piccoli e reversibili alla bellezza di una migrazione completa.

flowchart TB
    accTitle: Il valore di girare in parallelo senza insistere su una migrazione completa
    accDescr: Che AD resti non è una migrazione fallita; anche se girate in parallelo per anni con impostazioni ancora in GPO, c'è grande valore nello stato in cui ogni PC nuovo è gestito nel cloud e il controllo funziona fuori sede
    miscon["AD che resta significa che la migrazione è fallita?"] -->|No| run["Girare in parallelo per anni con GPO ancora lì"]
    run --> value["I PC nuovi sono sotto controllo anche fuori sede"]
    value -.-> forward["Preferite avanzamenti piccoli"]

Figura 19: Anche girando in parallelo con AD ancora lì, lo stato in cui ogni PC nuovo è gestito nel cloud ha grande valore.

9. Una risposta realistica per l’IT da una persona sola

Infine, un riepilogo del progetto operativo in un’azienda in cui la persona responsabile è una (o ha il ruolo come lavoro collaterale).

• Restringete gli elementi di gestione fin dall’inizio. Se provate a portare dentro ogni impostazione dell’era GPO, vi esaurirete sul solo inventario. Partite dai cinque del capitolo 7 (2) (aggiornamento, crittografia, Defender, blocco schermo, LAPS) e fatene un «progetto per sottrazione» che aggiunge un’impostazione solo quando nasce il bisogno. Il Settings catalog offre migliaia di impostazioni,⁷ ma non avete alcun obbligo di usarle.
• Decidete su un’immagine PC standard. Mantenete solo uno standard: «un PC in questa azienda è questo set di policy e questo set di app». Le eccezioni di reparto si possono esprimere con gruppi e filtri, ma più le eccezioni crescono, meno una persona sola riesce a stare dietro.
• Chiedete a un partner esterno il progetto e il fare i template; tenete le operazioni quotidiane in-house. L’outsourcing di migrazione Intune che fallisce facilmente è il caso in cui buttate la build oltre il muro e finite in uno stato in cui «nessuno capisce cosa significano le schermate di amministrazione». Chiedete all’esterno il progetto iniziale, il templating delle policy e una cassa di risonanza per le decisioni di migrazione, e fate dell’obiettivo uno stato in cui potete aggiungere un PC e ritoccare una policy da soli giorno per giorno. Detto all’inverso, dovreste scegliere un partner che consegnerà fino a lì.
• Cambiate una cosa alla volta. Fate i cambi di policy uno alla volta, e andate avanti solo dopo aver confermato il risultato nei report Intune (stato di applicazione della policy e fallimenti di assegnazione). La sincronizzazione MDM è su un ciclo di circa 8 ore,³ e la maggior parte di «non si è applicata» è una questione di tempo, non un guasto.

flowchart TB
    accTitle: Il ciclo operativo di un cambio di policy
    accDescr: Fate i cambi di policy uno alla volta, e passate al cambio successivo solo dopo aver confermato lo stato di applicazione nei report Intune. La maggior parte dei casi di non applicazione si risolve aspettando il ciclo di sincronizzazione di circa 8 ore
    change["Fate solo un cambio di policy"] --> report["Confermate lo stato di applicazione nei report"]
    report --> next["Se non c'è problema, al cambio successivo"]
    next --> change
    report -.-> wait["La maggior parte della non applicazione è aspettare la sincronizzazione"]

Figura 20: Fate i cambi di policy uno alla volta, e andate avanti solo dopo aver confermato il risultato nei report.

10. Riepilogo

• GPO è un meccanismo che assume la raggiungibilità di un domain controller, e strutturalmente non raggiunge i PC fuori sede. Intune (MDM) sincronizza su internet, quindi risolve questo problema alla radice.
• La migrazione non è tutto o niente. Le macchine Entra-joined e le macchine domain-joined possono coesistere, e una migrazione a stadi che passa i PC nuovi a Entra join più Intune è la risposta realistica per le piccole e medie imprese. Non c’è un percorso di conversione per le macchine esistenti, quindi la sostituzione sul ciclo di rinnovo hardware è il pattern consolidato.
• Per le piccole e medie imprese, iniziare Intune con Microsoft 365 Business Premium (Intune Plan 1 più Entra ID P1) è realistico. La composizione dei piani continua a cambiare, però, e alcune funzionalità come Remediations richiedono una licenza più alta, quindi non prendete questo articolo di agosto 2026 come vangelo; confermate le fonti primarie.
• L’inventario delle GPO attuali si può automatizzare con Group Policy analytics. Convertite le impostazioni Ready for migration al Settings catalog, e sostituite gli script di logon e la distribuzione delle stampanti che non hanno un corrispondente con la distribuzione via script, trasformando il lavoro in un’app, o fermando la pratica. Notate che in una GPO giapponese la percentuale di supporto può essere inaccurata.
• Avanzate la migrazione nei cinque stadi «pilota → policy di baseline → distribuzione app → sostituzione naturale dei PC esistenti → ridurre il ruolo di AD», e decidete prima il criterio di uscita di ciascuno stadio.
• Un conflitto di doppia applicazione lo vince GPO per default. MDMWinsOverGP è un meccanismo solo Policy CSP, quindi il principio è «non distribuire la stessa impostazione da entrambi».
• Quando arriva un preventivo di sostituzione del server è il momento migliore per considerare questa migrazione. Prima di «un altro ciclo di AD», pensate a dove verranno usati i PC dei prossimi cinque anni.

Articoli correlati

• Una guida pratica a Group Policy (GPO) — Come funziona, confermare l’applicazione e scegliere tra GPO e Intune
• Gestione di Windows Update dopo la deprecazione di WSUS — Come scegliere tra WUfB, Autopatch e Intune
• Opzioni pratiche dopo la fine del supporto di Windows 10 — Una tabella decisionale per ESU, LTSC e sostituzione
• Automatizzare il provisioning PC con winget + PowerShell — Rendere eseguibile il runbook
• Guida pratica a BitLocker — Crittografia unità a partire dalla gestione delle chiavi di recupero
• Una guida pratica a Windows LAPS — Ritirare la password di amministratore locale condivisa su tutti i PC

Aree di consulenza correlate

KomuraSoft LLC si occupa del progetto di una migrazione a stadi da un ambiente AD+GPO a Entra ID+Intune (inventariare le GPO attuali, una policy per riprodurre le impostazioni, un piano pilota), della revisione comparativa di sostituzione del server rispetto a un passaggio al cloud, e di consulenze che riusano app line-of-business esistenti e asset di provisioning. Partire dal considerare insieme «dovremmo comprare un altro server AD» va bene.

• Consulenza tecnica e revisione della progettazione
• Riutilizzo di asset esistenti e supporto alla migrazione
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Se migriamo da GPO a Intune, possiamo riprodurre ogni impostazione Group Policy che usiamo oggi?

Non potete riprodurle tutte. Il Settings catalog di Intune ha migliaia di impostazioni Windows, incluse quelle che vengono da ADMX, e la maggior parte delle impostazioni di sicurezza e delle restrizioni si può spostare, ma alcune cose — mappe unità via script di logon, distribuzione di massa delle stampanti — non hanno un'impostazione MDM corrispondente. Se importate un export XML delle vostre GPO attuali in Group Policy analytics di Intune, ogni impostazione viene classificata come Ready for migration, Not supported o Deprecated. Per le impostazioni che non hanno un corrispondente, le coprite distribuendo uno script PowerShell, trasformando il lavoro in un'app, o semplicemente fermando quella impostazione.

Quale licenza ci serve per usare Intune?

La base è Microsoft Intune Plan 1. Potete sottoscriverla da sola, ma nelle piccole e medie imprese è comune usarla come parte di Microsoft 365 Business Premium (fino a 300 utenti). Business Premium include anche Entra ID P1, quindi potete arrivare a combinare policy di conformità con Conditional Access. Alcune funzionalità, come Remediations, richiedono a parte una licenza di classe Windows Enterprise E3/E5. La composizione dei piani cambia spesso, quindi confermate i dettagli più recenti sulle pagine ufficiali di licensing Microsoft prima di firmare (questo articolo è ad agosto 2026).

Dobbiamo ritirare subito il server AD?

No. I PC gestiti con Entra join più Intune e i PC gestiti con domain join AD più GPO possono coesistere sulla stessa rete aziendale. Una migrazione a stadi — lasciare AD per l'autenticazione del file server e i sistemi line-of-business esistenti, e fare Entra-join solo dei PC nuovi — è realistica. Viceversa, non c'è un modo supportato per «convertire» un PC già domain-joined in Entra join; è richiesto un wipe (reset), quindi il pattern consolidato è sostituire le macchine esistenti sul ciclo di rinnovo hardware. Basta considerare il ritiro di AD dopo che le GPO sono vuote e avete inventariato i ruoli restanti.

Perché Group Policy non si applica ai PC usati per il lavoro da remoto?

Perché GPO viene recuperata e applicata quando il PC può raggiungere un domain controller. Un PC fuori dall'ufficio può ricevere la policy più recente solo quando può raggiungere un domain controller su una VPN o simile, e un PC di casa che non usa VPN essenzialmente non la riceve mai. Intune (MDM) sincronizza la policy su internet, quindi potete gestire un PC ovunque sia; il problema di gestire i PC fuori sede è risolto dalla struttura di MDM. Oltre a una sincronizzazione periodica di circa ogni 8 ore, gira anche una sincronizzazione guidata da notifica quando la policy cambia.

Se distribuiamo la stessa impostazione sia da GPO sia da Intune, quale vince?

Per default, un'impostazione in conflitto la vince Group Policy. Impostare la policy MDMWinsOverGP a 1 fa vincere il lato MDM (Intune), ma quel meccanismo si applica solo alle impostazioni sotto Policy CSP; non si applica alle impostazioni definite in altri CSP come Defender CSP. Affidarsi al controllo di precedenza rende il comportamento difficile da prevedere, quindi in pratica il principio è «non distribuire la stessa impostazione da entrambi i canali», e una volta che un'impostazione è passata a Intune la cancellate dalla GPO originale per evitare la doppia gestione.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.