KomuraSoft LLC
Contatti
Menu

Una guida pratica a Group Policy (GPO) — Come funziona, confermare l'applicazione e scegliere tra GPO e Intune

· · Windows, Group Policy, Active Directory, Intune, Gestione PC, PowerShell, Sistemi informativi

«Questa impostazione è distribuita via GPO», «i PC del cliente sono bloccati da Group Policy» — chi lavora con i sistemi aziendali Windows sente la parola «GPO» in continuazione. Eppure, quando si tratta di rilevare i compiti di amministrazione AD, o di installare un’app su un PC nel dominio presso un cliente, sono sorprendentemente pochi quelli che sanno spiegare con precisione quando, da dove e in quale ordine di priorità si applica Group Policy.

«Ho cambiato l’impostazione, ma non ha effetto», «mi hanno detto di eseguire gpupdate ma non so cosa stia facendo davvero», «l’app gira sulla macchina di sviluppo ma non dal cliente, e alla fine era una GPO» — questo articolo è rivolto agli sviluppatori di app aziendali che si imbattono in queste situazioni, e al personale IT delle piccole e medie imprese che ha ereditato l’amministrazione AD. Organizza come funziona Group Policy (l’ordine di applicazione LSDOU), quando ha effetto, come diagnosticarla con gpresult e il registro eventi, ADMX e l’archivio centrale, e come scegliere tra GPO e Intune (MDM), sulla base di fonti primarie ad agosto 2026.

1. Prima di tutto, la conclusione

  • Group Policy è «vince l’ultima elaborata». Si elabora nell’ordine locale → sito → dominio → OU (LSDOU), e in un conflitto ha priorità la GPO elaborata per ultima. La GPO locale (gpedit.msc) è lo strato più debole.1
  • Il momento di applicazione è «primo piano più background». La Configurazione computer si applica sempre all’avvio e la Configurazione utente sempre all’accesso; in più, per default c’è un aggiornamento in background circa ogni 90 minuti più un offset casuale di 0-30 minuti (5 minuti sui domain controller).2
  • gpupdate /force «riapplica ogni impostazione» — non è una cura universale. Alcune impostazioni, come l’installazione software e il reindirizzamento delle cartelle, si elaborano solo all’accesso o al riavvio (ed è esattamente per questo che esistono le opzioni /logoff e /boot).3
  • Il punto di partenza della diagnosi è il report RSoP di gpresult /h. Mostra sia le GPO applicate sia le GPO rifiutate, con i motivi. Per scavare più a fondo si usa il log operativo GroupPolicy (Microsoft-Windows-GroupPolicy/Operational).45
  • Di regola, le policy dei modelli amministrativi si scrivono nelle chiavi di policy dedicate del Registro (Software\Policies e simili). Il valore di policy ha priorità sull’impostazione propria dell’app, e «Non configurato» non scrive nulla. Detto questo, alcune policy scrivono fuori dalle chiavi dedicate (sezione 5).6
  • L’archivio centrale ADMX è la cartella PolicyDefinitions in SYSVOL. Una volta creata, GPMC inizia a consultare da lì le definizioni di modello comuni al dominio.7
  • La scelta tra GPO e Intune si decide sulla base di identità del dispositivo. Configurare la stessa impostazione in entrambi non dà un esito garantito. Group Policy analytics può aiutare quando considerate la migrazione.89
  • Per gli sviluppatori, la GPO è una causa classica di un’app che «fallisce solo dal cliente». Impostazioni che cambiano le premesse dell’app — la policy di esecuzione, l’unione delle regole locali del firewall disabilitata, la configurazione di proxy e unità, e altro — vengono distribuite dalla gestione centralizzata.1011

2. Che cos’è Group Policy — GPO locali e GPO di dominio

Group Policy è un meccanismo con cui un amministratore definisce in modo centralizzato le impostazioni di Windows e le impone sui computer e sugli utenti di destinazione. Un insieme di impostazioni si chiama GPO (Group Policy Object). Una GPO può vivere in uno di due posti.

  GPO locale GPO di dominio
Strumento di modifica gpedit.msc (Editor Criteri di gruppo locali) GPMC (Console Gestione Criteri di gruppo) + Editor Gestione Criteri di gruppo
Posizione di archiviazione Il PC stesso. Ce n’è una sola per il computer, ma per gli utenti si possono anche creare più GPO locali (MLGPO) suddivise per «amministratori / non amministratori / utenti specifici»12 Active Directory (si distribuisce collegandola a siti, domini e OU)
Ambito Solo quel PC Ogni computer/utente sotto il target del collegamento
Priorità La più debole (sovrascritta dalle GPO di dominio)1 Più forte della locale. Tra GPO di dominio, la priorità la decidono il target del collegamento e l’ordine di collegamento
Uso tipico Impostazioni autonome su PC in gruppo di lavoro e macchine di test Distribuire e imporre le impostazioni standard dell’organizzazione

Un PC in gruppo di lavoro (non nel dominio) elabora solo la GPO locale.1 Quindi in pratica, quando si dice che una macchina è «gestita da GPO», si intende quasi sempre una GPO di dominio.

GPO elaborate da un PC in gruppo di lavoro e da un PC nel dominioUn PC in gruppo di lavoro elabora solo la GPO locale, mentre un PC nel dominio elabora anche la GPO di dominio distribuita da Active DirectoryGruppo di lavoroNel dominioQual è la forma di appartenenza del PC?Elabora solo la GPO localeGPO locale + GPO di dominioIn pratica le GPO sono quasi sempre di dominio

Figura 1: Un PC in gruppo di lavoro elabora solo la GPO locale, mentre un PC nel dominio elabora anche la GPO di dominio.

Qualunque sia la GPO, il contenuto cade grosso modo in due categorie.

  • Configurazione computer: impostazioni che valgono per chiunque acceda a quel PC. Si applicano all’avvio.
  • Configurazione utente: impostazioni che valgono per quell’utente su qualsiasi PC in cui acceda. Si applicano all’accesso.

Questo asse — «l’impostazione è legata al PC o alla persona» — torna in modo coerente sia nell’ordine di applicazione sia nel modo in cui confermate che ha avuto effetto, più avanti in questo articolo. Alcune voci esistono in entrambe le configurazioni, quindi abituatevi a controllare sempre entrambi i rami quando cercate un’impostazione.

Le due linee di contenuto di una GPOOgni GPO ha due linee, Configurazione computer e Configurazione utente; la Configurazione computer si applica all'avvio e vale per chiunque acceda a quel PC, la Configurazione utente si applica all'accesso e vale su qualsiasi PC in cui quell'utente accedaContenuto della GPOConfigurazione computerConfigurazione utenteSi applica all'avvioSi applica all'accessoVale per chiunque accedaVale su qualsiasi PC

Figura 2: Una GPO ha due linee: la Configurazione computer legata al PC e la Configurazione utente legata alla persona.

3. Come funziona l’applicazione — il «vince l’ultima» di LSDOU e il controllo dell’ereditarietà

3.1. LSDOU: locale → sito → dominio → OU

Su un PC nel dominio, le GPO si elaborano nel seguente ordine.1

  1. GPO locale
  2. GPO collegate al sito
  3. GPO collegate al dominio
  4. GPO collegate a un’OU (unità organizzativa) — si elaborano dall’OU di livello più alto in giù, con la GPO sull’OU a cui il computer/utente di destinazione appartiene direttamente elaborata per ultima

Prendendo le lettere iniziali si ottiene l’ordine LSDOU. Il punto chiave è che questo non è «prima la priorità più alta» ma l’ordine in cui le GPO vengono elaborate. Quando più GPO configurano la stessa impostazione, vince quella elaborata per ultima (le impostazioni che non vanno in conflitto si sommano semplicemente).1 In altre parole, la GPO sull’OU più vicina all’oggetto è la più forte, e la GPO locale è la più debole. «L’ho sistemata in gpedit.msc e è tornata indietro» non è un malfunzionamento — è questa specifica che lavora esattamente come progettata.

Ordine di elaborazione LSDOU e vittoria dell'ultimaLe GPO si elaborano in ordine locale, sito, dominio, OU, e in caso di conflitto vince la GPO elaborata per ultima, quindi la GPO dell'OU più vicina all'oggetto è la più forte e la GPO locale è la più debole1. GPO locale2. Sito3. Dominio4. OU (dall'alto in giù)In conflitto vince l'ultimaLa GPO dell'OU più vicina è la più forteLa GPO locale è la più debole

Figura 3: LSDOU è l’ordine di elaborazione, e quando la stessa impostazione va in conflitto vince la GPO elaborata per ultima.

Quando più GPO sono collegate allo stesso sito, dominio o OU, la priorità tra di loro la decide l’ordine di collegamento nella scheda «Oggetti Criteri di gruppo collegati» di GPMC. La GPO con il numero di ordine di collegamento più basso viene elaborata per ultima e ha la priorità più alta.1

Ordine di collegamento quando ci sono più GPO nello stesso puntoSe più GPO sono collegate allo stesso sito, dominio o OU, l'ordine di elaborazione lo decide l'ordine di collegamento di GPMC, e la GPO con il numero più basso viene elaborata per ultima e ha la priorità più altaPiù GPO nello stesso puntoLo decide l'ordine di collegamento di GPMCLa GPO con numero minimo si elabora per ultimaVince per ultima e ha la priorità massima

Figura 4: Nello stesso target di collegamento, la GPO con il numero di ordine più basso viene elaborata per ultima e vince.

3.2. Blocco di ereditarietà e Enforced

Potete creare eccezioni all’ordine predefinito.1

  • Blocco di ereditarietà (Block Inheritance): impostato su un dominio o un’OU, ferma l’ereditarietà delle GPO dal livello superiore. È lo strumento per «questa OU non deve ricevere lo standard aziendale».
  • Enforced (un tempo chiamato No Override): impostato sul collegamento di una GPO, fa sì che quella GPO si applichi comunque, anche se un livello inferiore ha il blocco di ereditarietà, e non possa più essere sovrascritta da una GPO inferiore. Quando blocco di ereditarietà e Enforced vanno in conflitto, vince Enforced.1
Relazione tra blocco di ereditarietà e EnforcedIl blocco di ereditarietà ferma l'ereditarietà delle GPO dal livello superiore, ma una GPO con Enforced si applica comunque anche se a valle c'è un blocco, e non viene sovrascritta da una GPO inferioreNoSìNoSìGPO dal livello superioreBlocco di ereditarietà a valle?Si eredita così com'èLa GPO ha Enforced?L'ereditarietà si fermaSi applica comunqueNon viene sovrascritta da una GPO inferiore

Figura 5: Il blocco di ereditarietà ferma l’ereditarietà dal livello superiore, ma una GPO con Enforced attraversa il blocco e si applica comunque.

Enforced è un meccanismo che rompe il principio «vince l’ultima elaborata», quindi abusarne fa sì che sempre più risultati nella lettura dell’RSoP risultino controintuitivi. La prassi consolidata è riservarlo alle impostazioni di sicurezza che tutta l’azienda deve rispettare.

3.3. Filtro di sicurezza

Oltre al punto di collegamento, potete anche restringere a chi una GPO si applica, per GPO. Perché una GPO venga applicata, l’utente o il computer di destinazione deve avere sia il permesso «Lettura» sia il permesso «Applica Criteri di gruppo» su quella GPO. Per default entrambi sono concessi a Authenticated Users (che include utenti e computer), quindi la GPO si applica a tutti sotto il target del collegamento. Il filtro di sicurezza è il modo per restringere questo a gruppi di sicurezza specifici. Il filtro agisce sulla GPO nel suo insieme; non potete variarlo per impostazione all’interno della GPO.13

C’è un avvertimento importante. Quando restringete l’ambito, non togliete anche «Lettura» dal default Authenticated Users. Dal security update MS16-072 (2016), la policy utente viene recuperata nel contesto di sicurezza del computer, quindi se l’account computer non può leggere la GPO, la GPO per utente non si applicherà anche se l’utente di destinazione ha entrambi i permessi.14 Il modo corretto di restringere è concedere «Lettura + Applica Criteri di gruppo» al gruppo di destinazione, lasciando solo «Lettura» su Authenticated Users (o Domain Computers).14

Valutazione di applicazione del filtro di sicurezzaPerché una GPO si applichi, l'utente o il computer di destinazione deve avere sia Lettura sia Applica Criteri di gruppo, e per una GPO utente serve anche che l'account computer possa leggerlaNoSìNoSìSìNoOggetto sotto il collegamento della GPOLettura e applicazione entrambi?Rifiutata dal filtroGPO per utente?Si applicaIl computer può leggere?Non si applica (MS16-072)

Figura 6: Per l’applicazione servono sia «Lettura» sia «Applica Criteri di gruppo», e per una GPO utente serve anche la lettura dell’account computer.

In pratica, i due inciampi classici sono «l’ho aggiunto al gruppo ma non si applica (è un’impostazione per computer, ma ho aggiunto solo l’utente al gruppo)» e «l’ho tolto dal gruppo ma continua ad applicarsi». Il secondo non si risolve nemmeno aspettando un aggiornamento in background. L’appartenenza ai gruppi si valuta dal token di sicurezza creato all’accesso, quindi la modifica di gruppo di un utente arriva al filtro solo dopo un ciclo disconnessione/accesso, e la modifica di gruppo di un computer solo dopo un riavvio — una volta emesso un token nuovo.

Finché una modifica di gruppo non arriva al filtroL'appartenenza ai gruppi si valuta con il token di sicurezza creato all'accesso, quindi una modifica utente si riflette solo dopo un nuovo accesso e una modifica computer solo dopo un riavvio, quando esiste un token nuovoModifica dei membri del gruppoCon il token vecchio non si rifletteL'utente deve accedere di nuovoIl computer va riavviatoValutazione con il token nuovoSi riflette nel filtroL'aggiornamento in background non basta

Figura 7: Una modifica di gruppo si riflette nel filtro solo quando un nuovo token viene creato con una disconnessione o un riavvio.

C’è anche una modalità speciale chiamata elaborazione loopback, per situazioni come PC condivisi o server Remote Desktop, in cui volete che chiunque acceda a quel PC riceva una Configurazione utente sostituita (un meccanismo che applica le impostazioni utente in base alla posizione del computer, con le modalità Sostituzione e Unione).15 È una funzione avanzata usata su chioschi e PC di aula, quindi questo articolo si limita a notare che esiste.

Idea dell'elaborazione loopbackL'elaborazione loopback è una modalità speciale che applica la Configurazione utente in base alla posizione del computer, con due modalità Sostituzione e Unione, usata su PC condivisi e chioschi dove si vuole la stessa impostazione utente per chiunque accedaPC condivisi, chioschi e similiElaborazione loopbackSi decide dalla posizione del computerModalità SostituzioneModalità UnioneVale per chiunque abbia effettuato l'accesso

Figura 8: L’elaborazione loopback è una modalità speciale che applica la Configurazione utente in base alla posizione del computer, con due modalità Sostituzione e Unione.

4. Quando le impostazioni hanno effetto — elaborazione in primo piano e aggiornamento in background

Metà dei casi di «l’ho configurata ma non ha effetto» è semplicemente che il momento di applicazione non è ancora arrivato. Ci sono due tipi di applicazione.2

Tipo Momento Ambito
Elaborazione in primo piano (foreground) Configurazione computer: all’avvio / Configurazione utente: all’accesso Ogni impostazione
Aggiornamento in background Per default, circa ogni 90 minuti più un offset casuale di 0-30 minuti (sfasato perché non tutti i dispositivi scarichino insieme) Solo le impostazioni che supportano l’elaborazione in background
Aggiornamento in background (domain controller) Per default, ogni 5 minuti Come sopra

In altre parole, per un dispositivo in funzione che può raggiungere un domain controller, le impostazioni che supportano l’aggiornamento in background si diffondono in circa due ore dopo che avete cambiato la GPO, senza altre azioni. I dispositivi offline, o i portatili portati fuori sede senza una connessione VPN, non la ricevono finché non raggiungono di nuovo un DC. Le impostazioni che si applicano solo tramite elaborazione in primo piano dovranno inoltre aspettare un avvio o un accesso. Se urge, eseguite gpupdate sul PC di destinazione. Per default si applicano solo le impostazioni che sono cambiate; aggiungendo /force si riapplicano tutte le impostazioni, indipendentemente dal fatto che siano cambiate.3

rem Aggiornare solo le impostazioni cambiate (di solito basta)
gpupdate

rem Riapplicare ogni impostazione (quando si sospetta uno stato in cache)
gpupdate /force
Raggiungibilità del DC e come arriva l'applicazioneSu un dispositivo in funzione che raggiunge un domain controller, le impostazioni che supportano l'aggiornamento in background si diffondono in circa due ore, ma un PC offline o in uscita senza VPN non le riceve finché non si collega al DCSìNoIl DC è raggiungibile?Si diffonde in circa due oreNon arriva finché non si collegaPC offline o in uscita senza VPN

Figura 9: Su un dispositivo in funzione che raggiunge un DC le impostazioni si diffondono in circa due ore, ma un dispositivo offline non le riceve finché non si collega di nuovo al DC.

La cosa da tenere d’occhio è che alcune impostazioni semplicemente non hanno effetto tramite gpupdate. L’installazione software per utente e il reindirizzamento delle cartelle si elaborano solo all’accesso, e l’installazione software per computer solo all’avvio. gpupdate mette a disposizione proprio per questo le opzioni /logoff (disconnettersi dopo l’aggiornamento) e /boot (riavviare dopo l’aggiornamento).3 Prima di lamentarvi che «ho eseguito gpupdate /force e ancora non ha effetto», verificate se l’impostazione è di un tipo che richiede un riavvio o un accesso.

Percorsi con cui un'impostazione si applicaUna modifica GPO, se l'impostazione supporta l'aggiornamento in background, arriva in circa 90 minuti più un offset di 0-30 minuti; le impostazioni che si applicano solo in primo piano aspettano avvio o accesso, e anche gpupdate per urgenza richiede /logoff o /boot per quelle in primo pianoSìNoSi modifica la GPOSupporta l'aggiornamento in background?Aggiornamento in circa 90 min + 0-30 minSi applica all'avvio o all'accessoApplicataSe urgeEseguire gpupdate/force per riapplicare tuttoIn primo piano servono /logoff o /boot

Figura 10: L’aggiornamento in background consegna solo le impostazioni che lo supportano; quelle che si applicano solo in primo piano, anche dopo gpupdate, richiedono ancora disconnessione o riavvio.

5. Diagnosticare un’impostazione che non si applica — gpresult, il registro eventi e il Registro

5.1. Controllare l’RSoP con gpresult /h

gpresult è lo strumento standard per controllare l’esito finale (RSoP: Resultant Set of Policy) una volta che più GPO si sono sovrapposte. Produrre un report HTML da un prompt dei comandi con privilegi elevati è l’approccio più leggibile.45

rem Produrre un report HTML RSoP sia utente sia computer
gpresult /h C:\temp\gp-report.html /f

rem Per controllare solo un riepilogo nella console
gpresult /r
gpresult /scope computer /r

Le prime tre cose da controllare nel report sono:

  1. L’elenco delle GPO applicate — la GPO che cercate c’è?
  2. L’elenco delle GPO rifiutate, con i motivi — motivi di non applicazione, come il filtro di sicurezza, un filtro WMI, o una GPO vuota, sono mostrati qui5
  3. La «GPO vincente» per ciascuna impostazione — il valore di quale GPO ha deciso l’impostazione che cercate. Se sta vincendo un’altra GPO, tornate indietro e rivedete le regole di priorità della sezione 3
I tre punti da guardare per primi nel report RSoPNel report di gpresult si guarda prima se la GPO desiderata è nell'elenco delle GPO applicate, poi l'elenco delle GPO rifiutate con i motivi, e infine quale GPO ha vinto per ciascuna impostazioneAprire il report RSoP1. Elenco delle GPO applicate2. GPO rifiutate e motivi3. GPO vincente per ciascuna impostazioneSe vince un'altra GPO, rivedere

Figura 11: Il report RSoP si legge nell’ordine GPO applicate, GPO rifiutate con i motivi, e GPO vincente per ciascuna impostazione.

5.2. Il log operativo GroupPolicy

Quando gpresult non basta — per esempio l’elaborazione sta fallendo del tutto, o ci mette troppo — guardate il log operativo GroupPolicy in Visualizzatore eventi. Si trova in «Registri di applicazioni e servizi > Microsoft > Windows > GroupPolicy > Operational» (nome del log Microsoft-Windows-GroupPolicy/Operational). Registra l’intero arco dell’elaborazione delle policy, dall’inizio alla fine, insieme all’elenco delle GPO applicate e all’elenco delle GPO rifiutate (con i motivi). A ogni ciclo di elaborazione delle policy è assegnato un ActivityID univoco, quindi la procedura raccomandata da Microsoft è recuperare l’ActivityID da un evento di avviso o errore nel log di sistema, e poi usare una vista personalizzata per restringere solo a quella istanza.5

Procedura per restringere il log operativo GroupPolicyNel log operativo GroupPolicy a ogni ciclo di elaborazione delle policy è assegnato un ActivityID univoco, quindi si recupera l'ActivityID da un avviso o errore del log di sistema e si restringe con una vista personalizzata ai soli eventi di quel cicloAvvisi ed errori del log di sistemaRecuperare l'ActivityIDRestringere con una vista personalizzataLeggere gli eventi di un solo cicloElenchi di GPO applicate e rifiutate con motivo

Figura 12: Il log operativo si legge recuperando l’ActivityID dal log di sistema e restringendo con una vista personalizzata a un solo ciclo di elaborazione delle policy.

5.3. La relazione con la chiave Policies del Registro

Le policy dei modelli amministrativi (capitolo successivo) alla fine vengono scritte come valori di Registro. Di regola, si scrivono nelle seguenti chiavi di policy dedicate.6

  • HKEY_LOCAL_MACHINE\Software\Policies (Configurazione computer; la posizione raccomandata)
  • HKEY_CURRENT_USER\Software\Policies (Configurazione utente; la posizione raccomandata)
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

C’è un principio di progetto importante. Un’app che riconosce le policy si comporta leggendo prima la chiave Policies; se un valore è presente lì, ha priorità; se no, l’app torna alla propria impostazione (preference) o al default. Una policy «Non configurato» non scrive nulla nel Registro.6 In altre parole, le policy dei modelli amministrativi non riscrivono l’impostazione propria dell’app lasciando un «tatuaggio» (tattooing) — invece, un valore imposto tenuto in un punto separato viene consultato con priorità. Smettete di configurare la policy, e l’app torna a obbedire al proprio valore di impostazione.

Relazione di priorità tra valore di policy e impostazione dell'appUn'app che riconosce le policy legge prima la chiave Policies e se c'è un valore lo antepone, altrimenti usa la propria impostazione o il valore predefinito, e una policy Non configurato non scrive nulla nel RegistroSìNoL'app legge l'impostazioneC'è un valore nella chiave Policies?Priorità al valore di policyUsa la propria impostazione o il defaultPolicy Non configuratoNon scrive nulla nel Registro

Figura 13: La policy non riscrive l’impostazione propria dell’app: un valore imposto tenuto in un altro punto viene consultato con priorità.

Detto questo, non ogni policy scrive in una chiave dedicata. Alcune impostazioni incorporate del sistema operativo (per esempio, «Enable Win32 long paths» scrive su LongPathsEnabled sotto HKLM\SYSTEM\CurrentControlSet\Control\FileSystem), insieme a template di generazione precedente o di terze parti, scrivono su percorsi arbitrari fuori dalle chiavi dedicate. Per impostazioni come queste, il valore resta anche dopo che smettete di configurare la policy. Controllate la definizione ADMX, il testo di descrizione dell’impostazione, o il report gpresult per vedere su quale chiave una data impostazione scrive davvero.

Detto in un altro modo, il disegno ben educato descritto sopra vale solo dentro il perimetro dei modelli amministrativi (le chiavi di policy dedicate). I valori che script o Group Policy Preferences scrivono fuori dalla chiave Policies si comportano come valori di Registro ordinari, e questo quadro non offre un meccanismo per ripristinarli automaticamente una volta che smettete di distribuirli. In pratica, quando diagnosticate un problema, l’approccio più rapido e affidabile è guardare direttamente se l’impostazione che cercate è scritta sotto la chiave Policies.

# Esempio di controllo diretto di un valore distribuito da criterio (la maggior parte dei criteri è scritta sotto Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue
Procedura di diagnosi quando l'impostazione non si applicaPrima si conferma con il report RSoP di gpresult le GPO applicate e rifiutate, se non basta si restringe il log operativo GroupPolicy per ActivityID, e il valore reale distribuito si verifica direttamente nella chiave Policies del RegistroSìNoL'impostazione non si applicaConfermare l'RSoP con gpresult /hSi capiscono i motivi di applicazione e rifiuto?Rivedere priorità o filtriGuardare il log operativo GroupPolicyRestringere a un ciclo con l'ActivityIDVerificare il valore reale della chiave Policies

Figura 14: La diagnosi parte da gpresult /h; se non basta si passa al log operativo GroupPolicy, e il valore reale si verifica direttamente nella chiave Policies.

6. Modelli amministrativi (ADMX) e archivio centrale

Le definizioni dietro le impostazioni elencate sotto «Modelli amministrativi» di GPMC sono scritte come file ADMX (il corpo della definizione) più file ADML (le stringhe di visualizzazione per ciascuna lingua). Ogni PC ha le definizioni fornite dal sistema operativo sotto C:\Windows\PolicyDefinitions, e gli strumenti di amministrazione le caricano per costruire la schermata delle impostazioni.7

Se operate dentro un dominio, la mossa di base è creare un archivio centrale (central store). Create una cartella PolicyDefinitions sotto il SYSVOL di un domain controller (per esempio, \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), e il suo contenuto viene replicato su ogni domain controller del dominio; gli strumenti di Group Policy consultano l’archivio centrale per default.7 Questo elimina il problema in cui «la versione del template differisce da una postazione di amministrazione all’altra, e le impostazioni visibili non coincidono». I file ADML vanno in sottocartelle specifiche per lingua (it-IT per l’italiano).7

Funzionamento dell'archivio centraleCreando la cartella PolicyDefinitions sotto SYSVOL di un domain controller il contenuto si replica su tutti i domain controller e gli strumenti di Group Policy la consultano per default, così spariscono le discrepanze di definizione tra postazioni di amministrazioneCreazione sotto SYSVOLPolicyDefinitionsSi replica su tutti i DCGli strumenti GP la consultano per defaultSpariscono le discrepanze tra postazioniGli ADML vanno in cartelle per lingua

Figura 15: PolicyDefinitions in SYSVOL si replica su tutti i domain controller, e gli strumenti di Group Policy la consultano per default.

Ci sono due cautele operative. Prima, Microsoft distribuisce nuovi file ADMX per ciascuna nuova versione di Windows, e quando aggiornate sostituite il lato archivio centrale. Sostituire C:\Windows\PolicyDefinitions su ciascun PC individuale con la versione scaricata non è supportato.7 Seconda, quando aggiornate un archivio centrale esistente, la guida è di non sovrascrivere direttamente il PolicyDefinitions di produzione. Invece, allestite il set completo di ADMX — sia per il sistema operativo sia per app come Office ed Edge — in una cartella di lavoro con nome di versione come PolicyDefinitions-24H2, rinominate la cartella attuale da parte in qualcosa come PolicyDefinitions-23H2, e poi rinominate la cartella di lavoro in PolicyDefinitions per promuoverla in produzione.7 Gli strumenti di Group Policy consultano solo la cartella letteralmente chiamata PolicyDefinitions, quindi mettere i file in una cartella con nome di versione non ha effetto. Il vantaggio di questo approccio è che se sorge un problema, potete tornare alla cartella che avete messo da parte.7

Procedura di aggiornamento dell'archivio centralePer aggiornare si allestisce il set completo di ADMX OS e applicazioni in una cartella di lavoro con nome di versione, si rinomina la cartella attuale per metterla da parte, poi si rinomina la cartella di lavoro nel nome di produzione PolicyDefinitions, e se c'è un problema si torna alla cartella precedenteCartella di lavoro con nome di versioneAllestire OS e applicazioniRinominare l'attuale e metterla da parteRinominare la cartella di lavoro nel nome di produzioneViene consultata come produzioneSe c'è un problema, tornare alla cartella precedente

Figura 16: L’aggiornamento allestisce il set in una cartella di lavoro, mette da parte quella attuale e promuove con un rinomina.

7. GPO vs Intune (MDM/CSP) vs distribuzione manuale/script — una tabella di decisione

GPO non è più l’unica opzione per gestire la configurazione dei dispositivi Windows. MDM, di cui Intune è l’esempio più noto, configura le impostazioni del sistema operativo tramite un meccanismo chiamato CSP (Configuration Service Provider). Ecco una tabella di decisione su quale costruire l’approccio.

Aspetto GPO di dominio Intune (MDM/CSP) Distribuzione manuale/script
Prerequisiti Domain-joined AD + connettività a un domain controller Licenza Intune + dispositivo iscritto a Intune (Entra-joined/hybrid-joined, più dispositivi Entra-registered come BYOD a seconda del metodo di iscrizione) Nessuno (ed è esattamente per questo che non c’è nemmeno governance)
Raggiungibilità dei dispositivi fuori sede / da casa Non si aggiorna se non può raggiungere un DC via VPN o simile Arriva su internet Dipende dallo sforzo manuale
Granularità/copertura delle impostazioni La più ampia (modelli amministrativi + impostazioni di sicurezza + script, e così via) In espansione, ma non ancora equivalente all’insieme completo delle impostazioni GPO9 Solo quanto avete scritto
Imposizione Imposta come policy (la chiave Policies ha priorità)6 Imposta come policy (CSP) Non torna indietro una volta che un utente la cambia
Mezzi per confermare l’applicazione gpresult / log operativo GroupPolicy45 Report del centro di amministrazione Intune Costruire un meccanismo proprio
Adatta a Dispositivi centrati su AD on-prem che restano sulla LAN interna Dispositivi centrati sul cloud, fuori sede, siti distribuiti Una manciata di macchine, o come complemento ad altri metodi

L’asse di decisione è semplice: la base di identità del dispositivo (AD, o Microsoft Entra) e dove si trova il dispositivo. GPO è più affidabile per una flotta di PC da scrivania pienamente joined a un AD on-prem; GPO semplicemente non arriva affatto ai PC mobili Entra-joined.

Nella realtà, la maggior parte delle piccole e medie imprese sta in mezzo, in un setup ibrido (domain-joined più iscritto a Intune), e la cosa peggiore che potete fare qui è «configurare la stessa impostazione sia via GPO sia via MDM». Policy CSP ha una policy chiamata MDMWinsOverGP che fa vincere MDM quando GPO e MDM vanno in conflitto, ma il suo ambito è limitato alle policy corrispondenti dentro Policy CSP. Microsoft stessa è esplicita sul fatto che configurare un’impostazione fuori da quel controllo sia via GPO sia via MDM produce una race condition senza garanzia su quale vince, e che la doppia configurazione va evitata.8 Il primo principio dell’operazione ibrida è decidere, area di impostazione per area di impostazione, «questa è GPO, questa è Intune», e tenersi a una sola autorità di gestione.

Come scegliere tra GPO e IntuneSe la base di identità del dispositivo è AD on-prem e sta in sede, GPO è adatta; se è Entra join o fuori sede, Intune è adatta; in ibrido si evita la doppia configurazione della stessa impostazione e si sposta l'autorità di gestione su un solo lato per areaNel dominio AD e in sedeEntra join o fuori sedeIbridoQual è la base e la posizione del dispositivo?GPO è affidabile e più granulareCon Intune arriva anche fuori sedeSpostare su un solo lato per areaLa doppia configurazione non ha esito garantitoPer classificare: Group Policy analytics

Figura 17: La scelta si decide sulla base di identità e sulla posizione del dispositivo; in ibrido non configurate la stessa impostazione sia in GPO sia in MDM.

Quando siete allo stadio di considerare una migrazione da GPO a Intune, Group Policy analytics di Intune è il punto di ingresso. Importate GPO esportate da GPMC (XML), e analizzerà se ciascuna impostazione è supportata da MDM, oppure non supportata/deprecata; le impostazioni supportate si possono migrare in una policy Settings catalog di Intune.9 È più accurato pensarlo come uno strumento per «classificare cosa si può spostare, cosa no, e cosa scartare» che per «spostare tutto». L’autorità di gestione di Windows Update si sta riorganizzando lungo le stesse linee — si veda anche «Gestione di Windows Update dopo la deprecazione di WSUS».

Classificazione con Group Policy analyticsImportando in Group Policy analytics una GPO esportata da GPMC in XML si classifica per ciascuna impostazione se MDM la supporta, se è deprecata o non disponibile, e le impostazioni già supportate si possono migrare a una policy del catalogo impostazioniEsportare in XML da GPMCImportare in analyticsAnalizzare lo stato per ciascuna impostazioneGià supportata da MDMDeprecata o non disponibileMigrare a una policy Settings catalog

Figura 18: Group Policy analytics importa la GPO esportata e classifica le impostazioni che si possono spostare su MDM da quelle che non si possono.

8. Un punto cieco dello sviluppatore — come la GPO del cliente cambia il comportamento dell’app

Per finire, qualcosa che vale la pena sapere se fate sviluppo su commessa. La GPO del cliente riscrive in silenzio le premesse della vostra app. Accanto a firewall e antivirus, la GPO è un ospite fisso dietro «gira sulla macchina di sviluppo ma non dal cliente». Ecco alcuni esempi concreti.

  • Policy di esecuzione di PowerShell: la policy di esecuzione si può configurare in modo centralizzato via GPO, e gli ambiti MachinePolicy/UserPolicy derivanti da GPO hanno sempre priorità su un valore impostato in locale o sul processo.10 Se un installer o uno script operativo è costruito sull’assunto che «aggiungendo -ExecutionPolicy Bypass funzionerà», sotto gestione GPO non si avvia nemmeno. Si veda «Policy di esecuzione di PowerShell e firma degli script — Una guida pratica per uscire da “tappare con Bypass”» per i dettagli.
  • Unione delle regole locali del firewall disabilitata: in ambienti in cui il firewall è gestito in modo centralizzato via GPO/Intune, «unione delle regole locali» (AllowLocalPolicyMerge) può essere disabilitata per profilo. Dove è disabilitata, una regola in ingresso che un installer ha registrato in locale esiste ma non viene applicata.11 È un punto da confermare prima di installare un’app di tipo server; è trattato in dettaglio in «Il firewall di Windows e le applicazioni aziendali».
  • Configurazione dell’ambiente come mapping di unità e proxy: mapping di unità di rete, stampanti e simili si distribuiscono di solito tramite Group Policy Preferences.16 Assunti sull’ambiente — «l’unità Z dovrebbe esistere», «il proxy dovrebbe essere una connessione diretta» — possono cadere a seconda dell’utente che ha effettuato l’accesso o dell’appartenenza all’OU del PC. È anche facile dimenticare, per un’app residente, che le impostazioni distribuite tramite Configurazione utente naturalmente non si applicano all’account con cui gira un servizio o un’attività pianificata.
  • L’impostazione semplicemente «non si può riportare indietro»: le impostazioni che arrivano dai modelli amministrativi in genere l’utente non le può cambiare affatto dall’interfaccia (la voce è disattivata). Il fatto che «fate cambiare l’impostazione al cliente» non funzioni ha implicazioni reali su come progettate l’approccio di supporto.
Premesse dell'app che cambia la GPO del clienteLa GPO del cliente cambia le premesse dell'app imponendo la policy di esecuzione, disabilitando l'unione delle regole locali del firewall, distribuendo unità e proxy, e lasciando l'utente incapace di ripristinare l'impostazione, ed è una causa di un'app che funziona solo in sviluppoGPO del clienteImposizione della policy di esecuzioneUnione regole locali disabilitataDistribuzione di unità e proxyL'impostazione non si può ripristinareCausa di un fallimento solo dal cliente

Figura 19: La GPO del cliente riscrive in silenzio le premesse dell’app, come la policy di esecuzione, il firewall e la configurazione dell’ambiente.

Ci sono tre precauzioni realistiche sul lato sviluppo. Prima, documentare come requisito di installazione le premesse ambientali da cui dipende l’app — policy di esecuzione, porte in ascolto, dove scrive, percorso del proxy, e così via — e farle confermare dall’IT del cliente prima del deployment. Seconda, quando sorge un problema, controllare il report reale di gpresult /h e i valori reali sotto HKLM\Software\Policies, invece di indovinare (sezione 5). Terza, separare in fase di progettazione quali operazioni hanno bisogno di privilegi di amministratore e quali no (questa linea è tracciata in «Quando servono davvero i privilegi di amministratore su Windows? - UAC, aree protette e come distinguerlo in progettazione»). La GPO non è il nemico — è una specifica dell’ambiente. Trattatela come una specifica, e la diagnosi diventa meccanica.

Le tre precauzioni del lato sviluppoLe precauzioni del lato sviluppo sono documentare come requisito di installazione le premesse ambientali da cui dipende l'app e chiedere conferma all'IT del cliente prima dell'installazione, in caso di problema verificare il report gpresult e i valori reali della chiave Policies, e separare in progettazione i processi che richiedono privilegi di amministratorePrecauzioni del lato sviluppo1. Documentare le premesse ambientali2. Verificare con gpresult e i valori reali3. Separare in progettazione il bisogno di privilegiChiedere conferma all'IT del cliente prima dell'installazione

Figura 20: Le precauzioni del lato sviluppo sono tre: documentare le premesse ambientali, verificare con gpresult e i valori reali, e separare in progettazione il bisogno di privilegi di amministratore.

9. Riassunto

  • Group Policy è un meccanismo che elabora le impostazioni a livello di GPO nell’ordine locale → sito → dominio → OU (LSDOU), e i conflitti si risolvono con «vince l’ultima elaborata». La GPO sull’OU più vicina all’oggetto è lo strato più forte, e la GPO locale è il più debole.
  • Blocco di ereditarietà, Enforced e filtro di sicurezza vi permettono di controllare il flusso predefinito. Enforced batte anche il blocco di ereditarietà, quindi non va abusato.
  • L’applicazione avviene su due canali: elaborazione in primo piano all’avvio/accesso, e un aggiornamento in background circa ogni 90 minuti più un offset casuale per default. gpupdate /force riapplica ogni impostazione, ma non ha effetto sulle impostazioni che si elaborano solo all’accesso o al riavvio.
  • Quando un’impostazione non si applica, diagnosticate in modo meccanico nell’ordine gpresult /h → log operativo GroupPolicy → chiave Policies del Registro. Le GPO rifiutate sono mostrate con un motivo.
  • Le definizioni dei modelli amministrativi sono ADMX/ADML, e l’operazione di dominio dovrebbe consolidarle nell’archivio centrale SYSVOL. Quando aggiornate, sostituite il lato archivio centrale invece di rimpiazzare la cartella PolicyDefinitions locale.
  • Se usare GPO o Intune lo decide la base di identità e la posizione del dispositivo; in un setup ibrido, evitate di configurare due volte la stessa impostazione e tenete l’autorità di gestione da un solo lato. Group Policy analytics può aiutare a classificare una migrazione.
  • Per gli sviluppatori, la GPO di un cliente fa parte della specifica dell’ambiente. Documentate le premesse intorno a policy di esecuzione, firewall, mapping di unità e configurazione del proxy, e costruite l’abitudine di confermarle con gpresult — e la maggior parte dei casi di «fallisce solo dal cliente» smette di fare paura.

Articoli correlati

Aree di consulenza correlate

KomuraSoft LLC si occupa di indagare perché un’applicazione aziendale non funziona nell’ambiente del cliente sotto gestione GPO, di organizzare i requisiti di installazione (policy di esecuzione, firewall, premesse di rete) e di consulenza tecnica su inventario delle policy e piano di gestione combinata con Intune per il personale IT che ha ereditato un ambiente AD. Si può partire da uno stadio anche solo «leggere insieme un report gpresult».

Riferimenti

  1. Microsoft Learn, Group Policy processing and precedence. Sul fatto che Group Policy si elabora nell’ordine GPO locale → sito → dominio → OU, con una GPO elaborata più tardi che in un conflitto sovrascrive una precedente (le impostazioni che non vanno in conflitto si aggregano); sul fatto che più GPO nello stesso contenitore si elaborano in ordine di collegamento, con la GPO dal numero di ordine più basso elaborata per ultima e con priorità massima; sulle eccezioni di Enforced, disabilitazione di un collegamento, disabilitazione della configurazione utente/computer, e blocco di ereditarietà; sul fatto che una GPO Enforced continua ad applicarsi anche dove un livello inferiore ha il blocco di ereditarietà; sul fatto che un computer in gruppo di lavoro elabora solo la GPO locale; e sul fatto che la policy computer si applica all’avvio e la policy utente all’accesso. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, ADMX_GroupPolicy Policy CSP. Sul fatto che Group Policy computer si applica sempre all’avvio del sistema e, per default, si aggiorna in background ogni 90 minuti più un offset casuale di 0-30 minuti; sul fatto che Group Policy utente si applica sempre all’accesso e si aggiorna sullo stesso default di 90 minuti più offset di 0-30 minuti; sul fatto che l’intervallo di aggiornamento predefinito sui domain controller è 5 minuti; e sul fatto che l’intervallo di aggiornamento è configurabile in un intervallo di 0-64.800 minuti. ↩ ↩2

  3. Microsoft Learn, gpupdate. Sul fatto che gpupdate per default applica solo le impostazioni di policy cambiate e riapplica ogni impostazione con /force; su /logoff, necessario per estensioni come l’installazione software per utente o il reindirizzamento delle cartelle che un aggiornamento in background non elabora ma solo all’accesso; su /boot, necessario per estensioni come l’installazione software per computer che si elaborano solo all’avvio; e sulle opzioni /target:{computer user} e /wait.

    ↩ ↩2 ↩3

  4. Microsoft Learn, gpresult. Sul fatto che gpresult è il comando che mostra il Resultant Set of Policy (RSoP); sul fatto che /h produce un report HTML e /x un report XML, con /f che consente la sovrascrittura; sul fatto che /r dà una visualizzazione di riepilogo e /v e /z visualizzazioni dettagliate; sul fatto che /scope {user computer} restringe il target; e sul fatto che il set risultante di policy sovrapposte viene generato in base all’appartenenza a sito, dominio e OU.

    ↩ ↩2 ↩3

  5. Microsoft Learn, Applying Group Policy troubleshooting guidance. Sulla procedura di eseguire gpresult /h da un prompt dei comandi con privilegi elevati per controllare perché una GPO non si applica, come punto di partenza della diagnosi di Group Policy; sul fatto che il log operativo GroupPolicy (Microsoft-Windows-GroupPolicy/Operational) registra l’elenco delle GPO applicate e l’elenco delle GPO rifiutate insieme ai motivi di rifiuto; sul fatto che a ogni istanza di elaborazione delle policy è assegnato un ActivityID univoco, e sulla procedura di usare una vista personalizzata per restringere agli eventi di quella sola istanza; e sull’abilitazione del log di debug di GPSvc. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, Implementing Registry-based Policy. Sul fatto che l’archiviazione della policy basata sul Registro è limitata a HKCU\Software\Policies e HKLM\Software\Policies (le posizioni raccomandate) più Software\Microsoft\Windows\CurrentVersion\Policies sotto HKCU/HKLM; sul fatto che uno stato «Non configurato» non scrive nulla nel Registro; sul fatto che le applicazioni devono leggere prima la chiave di policy e, se non esiste, tornare a un valore di preference, con la chiave di policy che ha sempre priorità sulla chiave di preference; sui tipi di dati che si possono archiviare, REG_DWORD, REG_SZ e REG_EXPAND_SZ; e sul fatto che le applicazioni devono ricontrollare la chiave di policy quando avviene un aggiornamento di policy. ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, How to create and manage the Central Store for Group Policy Administrative Templates in Windows. Sul fatto che i modelli amministrativi sono suddivisi nel corpo di definizione ADMX e nelle stringhe di visualizzazione ADML specifiche per lingua; sul creare l’archivio centrale come cartella PolicyDefinitions sotto il SYSVOL di un domain controller (per esempio, \contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions); sul fatto che il suo contenuto viene replicato su ogni domain controller del dominio e gli strumenti di Group Policy consultano l’archivio centrale per default; sul fatto che i file ADML si mettono in cartelle specifiche per lingua come en-US o it-IT; sul fatto che sostituire C:\Windows\PolicyDefinitions con un set ADMX scaricato non è supportato; sulla guida, quando si aggiorna un archivio centrale esistente, di allestire il set completo di file ADMX/ADML del sistema operativo e delle estensioni delle applicazioni in una nuova cartella con nome di versione come PolicyDefinitions-24H2, rinominare la cartella attuale da parte in qualcosa come PolicyDefinitions-23H2, e poi rinominare la nuova cartella nel nome di produzione PolicyDefinitions; e sul vantaggio di questo approccio, cioè poter tornare alla cartella messa da parte se sorge un problema grave. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. Microsoft Learn, ControlPolicyConflict Policy CSP. Sul fatto che impostare la policy MDMWinsOverGP (valore predefinito 0) a 1 fa sì che l’impostazione MDM abbia precedenza su Group Policy per le policy corrispondenti dentro Policy CSP; sul fatto che il suo ambito è limitato alle policy dentro Policy CSP e non si applica ad altri CSP come Defender CSP; e sul fatto che configurare un’impostazione fuori da questo controllo sia via GPO sia via MDM produce una race condition senza garanzia su quale vince, ed è per questo che la doppia configurazione va evitata. ↩ ↩2

  9. Microsoft Learn, Analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune. Sul fatto che Group Policy analytics importa e analizza GPO on-premises, mostrando quali impostazioni sono supportate dai provider MDM incluso Intune e quali sono deprecate o non disponibili; sull’importare GPO esportate da GPMC in formato XML; e sul fatto che le GPO importate sono migrabili a una policy Settings catalog per il deployment sui dispositivi. ↩ ↩2 ↩3

  10. Microsoft Learn, about_Execution_Policies. Sul fatto che gli ambiti della policy di esecuzione si valutano nell’ordine di priorità MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine; sul fatto che MachinePolicy e UserPolicy sono gli ambiti impostati da Group Policy, così che anche una policy più permissiva (o più stretta) impostata a un ambito inferiore è sovrascritta dalla policy di priorità più alta; e sul fatto che Get-ExecutionPolicy -List mostra l’impostazione di ogni ambito. ↩ ↩2

  11. Microsoft Learn, Windows Firewall rules. Sul fatto che gli ambienti che gestiscono il firewall in modo centralizzato via GPO o CSP possono disabilitare «unione delle regole locali» (AllowLocalPolicyMerge) per profilo; sul fatto che le regole create in locale non si applicano quando è disabilitata; e sul fatto che la distribuzione centralizzata diventa obbligatoria per le regole delle app che richiedono connessioni in ingresso. ↩ ↩2

  12. Microsoft Learn, Step-by-Step Guide to Managing Multiple Local Group Policy Objects. Sul fatto che la GPO locale, da Windows Vista in poi, ha più strati — «Criteri computer locale», «Amministratori/Non amministratori» e policy per utente — noti come MLGPO; sul fatto che questi si elaborano nell’ordine computer locale → amministratori/non amministratori → per utente, con lo strato per utente letto per ultimo e con priorità più alta; e sul fatto che è una funzione pensata per gestire PC non nel dominio. ↩

  13. Microsoft Learn, Security filtering using GPMC. Sul fatto che il filtro di sicurezza è il meccanismo che restringe quali utenti e computer ricevono le impostazioni di una GPO; sul fatto che una GPO si applica solo se l’utente o il computer di destinazione ha sia il permesso «Lettura» sia il permesso «Applica Criteri di gruppo»; sul fatto che entrambi i permessi sono concessi a Authenticated Users (che include utenti e computer) su ogni GPO per default; e sul fatto che il filtro opera sulla GPO nel suo insieme piuttosto che per impostazione. ↩

  14. Microsoft Learn, Deploying Group Policy Security Update MS16-072 (KB3163622). Sul cambio di progetto, dopo MS16-072, per cui Group Policy utente viene recuperata nel contesto di sicurezza del computer; sul requisito risultante che l’account computer abbia accesso in lettura alla GPO; e sul bisogno, quando il permesso di Authenticated Users è stato rimosso via filtro di sicurezza o simile, di aggiungere «Lettura» (non «Applica Criteri di gruppo») per Authenticated Users o Domain Computers. ↩ ↩2

  15. Microsoft Learn, Loopback processing of Group Policy. Sul fatto che l’elaborazione loopback è una funzione che applica un set di GPO di impostazioni utente in base alla posizione dell’oggetto computer; sul fatto che è pensata per computer a scopo speciale come quelli in aree pubbliche, laboratori o aule; e sul fatto che è supportata solo in un ambiente Active Directory, con le modalità Unione e Sostituzione. ↩

  16. Microsoft Learn, Group Policy Preferences Getting Started Guide. Sul fatto che Group Policy Preferences è la famiglia di estensioni GPMC che configura mapping di unità, stampanti, attività pianificate, servizi, opzioni delle cartelle e altro; sul fatto che il targeting a livello di elemento permette un’ulteriore restrizione; e sul fatto che Preferences distribuisce impostazioni senza restringere le modifiche dell’utente, con la scelta se imporre o no una data impostazione — un carattere distinto dalle Policy vere e proprie. ↩

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.

Ho eseguito gpupdate /force, ma l'impostazione non si applica. Perché?
Per prima cosa verificate se l'impostazione è di un tipo che un aggiornamento in background non applica mai. L'installazione software per utente e il reindirizzamento delle cartelle si elaborano solo all'accesso, e l'installazione software per computer solo all'avvio, quindi dopo gpupdate servono una disconnessione (/logoff) o un riavvio (/boot). Poi eseguite gpresult /h per produrre un report RSoP e controllate se quella GPO compare tra le «GPO applicate», oppure tra le «GPO rifiutate» con un motivo. Se è applicata ma il comportamento non è cambiato, sospettate che un'altra GPO con priorità più alta stia sovrascrivendo la stessa impostazione (vince l'ultima elaborata). Il report mostra la «GPO vincente» per ciascuna impostazione, quindi potete individuare esattamente quale GPO sta vincendo.
Cosa significa «Denied - Filtering» in un report gpresult?
Significa che la GPO è nel raggio d'azione per quanto riguarda il punto di collegamento, ma il filtro l'ha esclusa dall'applicazione reale. La causa più comune è il filtro di sicurezza: perché una GPO si applichi, l'utente o il computer deve avere sia il permesso «Lettura» sia il permesso «Applica Criteri di gruppo» su quella GPO. Per default entrambi sono concessi a Authenticated Users, ma se avete ristretto a gruppi specifici, un'appartenenza dimenticata — non aver aggiunto il gruppo, o non aver aggiunto l'account computer — provoca un rifiuto. Per le GPO per utente, concedere entrambi i permessi solo all'utente di destinazione non basta. Da MS16-072, la policy utente viene recuperata nel contesto di sicurezza del computer, quindi va lasciato «Lettura» (non «Applica») a Authenticated Users o Domain Computers. Altre cause sono un filtro WMI che non corrisponde, o la configurazione utente/computer disabilitata sulla GPO stessa. Il motivo del rifiuto è registrato sia nel report gpresult sia nel log operativo GroupPolicy.
Un dispositivo va gestito con GPO o con Intune?
La regola di base è allinearsi alla base di identità del dispositivo. Se i dispositivi sono soprattutto domain-joined a un AD on-premises e sempre connessi alla rete interna, GPO è l'opzione più affidabile e a grana più fine. Se avete più dispositivi Microsoft Entra-joined, o macchine da casa che non toccano mai un domain controller, Intune (MDM/CSP), che può consegnare la configurazione anche fuori sede, è più adatto. In un ambiente ibrido in cui coesistono entrambi, configurare la stessa impostazione sia via GPO sia via MDM produce un conflitto senza vincitore garantito, quindi il principio è decidere, area di impostazione per area di impostazione, quale dei due la gestisce, e tenersi a quello. Quando considerate la migrazione, importare le GPO esistenti in Group Policy analytics di Intune permette di classificare le impostazioni già supportate da MDM e quelle non supportate o deprecate.
Un'impostazione che ho configurato con l'editor Criteri di gruppo locali (gpedit.msc) continua a essere sovrascritta dall'impostazione di dominio. È previsto?
Sì, è il comportamento di progetto. Group Policy si elabora nell'ordine locale → sito → dominio → OU (LSDOU), e in un conflitto vince la GPO elaborata per ultima, il che rende la GPO locale lo strato più debole. Se una GPO di dominio configura la stessa impostazione, la modifica locale verrà sempre sovrascritta. Viceversa, se il lato dominio lascia quell'impostazione «Non configurato», il valore della GPO locale resta. Anche se per i test volete far prevalere l'impostazione locale, su un PC nel dominio non c'è modo di invertire quest'ordine di priorità, quindi gli approcci realistici sono creare un'OU di test e regolare la GPO di dominio, oppure usare una macchina di test non nel dominio.
L'app aziendale che abbiamo sviluppato proprio non gira nell'ambiente del cliente. C'è un modo per verificare se la causa è una GPO?
Il primo passo è chiedere all'amministratore del cliente di eseguire gpresult /h report.html da un prompt dei comandi con privilegi elevati sul PC interessato e di esaminare il report RSoP. Cercate impostazioni che cambierebbero il comportamento dell'app: script bloccati dalla policy di esecuzione, unione delle regole locali del firewall disabilitata, oppure proxy e mapping di unità configurati. Aiuta anche controllare se sotto HKLM\Software\Policies e HKCU\Software\Policies nel Registro sono stati scritti valori di policy per il prodotto in questione, il che permette di segnalare in modo meccanico le impostazioni imposte dai modelli amministrativi. Sul lato sviluppo, la preparazione pratica è documentare le premesse da cui dipende l'app — policy di esecuzione, porte in ascolto, cartella di scrittura, e così via — come requisito di installazione, e farle confermare dall'IT del cliente prima del deployment.

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.

Contattaci
Torna al blog