Group Policy Non Si Applica su Windows 11: Guida Helpdesk al Troubleshooting con gpresult 2026

Aggiornato: 31 Agosto 2026

Se una Group Policy non si applica su Windows 11, nel 90% dei casi la causa è una delle cinque seguenti: filtro di sicurezza mancante, WMI filter che non corrisponde alla build di Windows 11 (24H2 o 25H2), Registry.pol corrotto nella cartella C:\Windows\System32\GroupPolicy\Machine, evento 1058 su SYSVOL, oppure Kerberos out-of-sync per un orologio sfasato. Il flusso corretto è sempre lo stesso: partire da gpresult /r /scope computer, isolare la riga Denied e agire di conseguenza. Nessuna reinstallazione, nessuna magia.

• La prima diagnosi è sempre gpresult /r /scope computer e /scope user, mai gpupdate /force alla cieca.
• Su Windows 11 24H2/25H2 i WMI filter scritti per Version LIKE "10.0.19%" falliscono perche' la build e' 10.0.26100 o superiore.
• Gli event ID 1058 e 1030 nel log System indicano problemi di accesso a SYSVOL: firewall, DFS client disabilitato o permessi NTFS su gpt.ini.
• Se il Registry.pol in C:\Windows\System32\GroupPolicy\Machine e' corrotto, rinominarlo (non eliminarlo) e riavviare risolve la maggior parte dei blocchi locali.
• Il servizio Group Policy Client (gpsvc) deve essere Automatico: non e' arrestabile a mano, va rimesso in piedi dai registry key.
• L'intervallo di refresh e' 90 minuti + offset random 0-30 minuti; per test in laboratorio impostarlo a 5 minuti via GPO, mai in produzione.

Diagnosi con gpresult: il punto di partenza

Prima cosa che dico ai tier-1: non toccate gpupdate /force finche' non avete letto un gpresult. Rifare girare un update senza sapere cosa e' fallito e' come premere F5 sperando che passi da solo. Il tool gpresult di Microsoft restituisce il Resultant Set of Policy: quali GPO sono state applicate, quali sono state filtrate e - fondamentale - perche' sono state filtrate.

Il comando piu' utile e' questo, da un prompt elevato sulla macchina interessata:

# Report leggibile a schermo, solo lato computer
gpresult /r /scope computer

# Report leggibile a schermo, solo lato user (deve essere l'utente loggato)
gpresult /r /scope user

# Report HTML completo (il piu' completo, apritelo nel browser)
gpresult /h C:\Temp\rsop.html /f

# Da remoto su una macchina del dominio
gpresult /s PC01 /u DOMINIO\admin /p * /h \\fileserver\logs\PC01-rsop.html

Nel report HTML cercate la sezione "Applied GPOs" e, subito sotto, "Denied GPOs". Ogni riga negata riporta un Reason che vi dice esattamente dove guardare: Denied (Security) significa permessi ACL sulla GPO, Denied (WMI Filter) significa che la WQL non ha matchato, Not Applied (Empty) significa che la GPO e' vuota, Disabled (GPO) significa che il ramo Computer o User e' disabilitato in GPMC. Non c'e' altra strada: leggere il motivo, agire sul motivo. Salto questo passo e sto perdendo mezz'ora buona a caso.

Per gli helpdesk lead che gestiscono AD hybrid, ricordate che l'account di computer deve trovarsi nella OU giusta prima che qualsiasi GPO computer-side venga anche solo valutata; se stiamo debuggando problemi correlati, la nostra guida al troubleshooting degli account bloccati in Active Directory copre gli errori piu' comuni di posizionamento nelle OU e replicazione tra DC.

Perche' la Group Policy non viene applicata: le 5 cause reali

Dopo anni di ticket ripetitivi, le cause si contano sulla mano. Le metto in ordine di frequenza reale su parco Windows 11 aziendale nel 2026:

1. Security filtering rotto: qualcuno ha rimosso Authenticated Users dalla scheda Delegation della GPO senza aggiungere il gruppo target con Read + Apply Group Policy. Sintomo classico: Denied (Security) in gpresult.
2. WMI filter scritto per Windows 10: la query controlla Version LIKE "10.0.19%" e Windows 11 24H2 riporta 10.0.26100. La GPO non viene mai applicata sui client nuovi.
3. Block Inheritance sulla OU combinata con una GPO higher-priority che non ha Enforced: la policy corretta viene sovrascritta da una policy padre con settings che entrano in conflitto.
4. SYSVOL non raggiungibile: event 1058/1030 nel log System. Firewall aziendale che blocca SMB, DFS client disabilitato, o un DC in replica sfasata.
5. Registry.pol corrotto localmente: shutdown improvvisi, aggiornamenti falliti (KB5083769 e KB5074109 sono stati particolarmente rumorosi) o antivirus che ha messo in quarantena il file.

Il resto - Kerberos time skew, GPO disabled ramo Computer, loopback mal configurato, gpsvc service fermo - copre il restante 10%. Se avete escluso queste cinque cause con metodo, siete gia' oltre il 90% della popolazione dei ticket.

Come vedere quale GPO ha vinto sul client

Il modo pulito e' aprire il report HTML di gpresult /h e cercare le tabelle "Winning GPO" sotto ogni policy setting: la colonna dice quale GPO ha impostato il valore finale. In alternativa, per una singola area (es. Firewall), gpresult /r /v mostra il verbose con la lista ordinata. Preferisco l'HTML: piu' rapido da girare a un collega e ha gli errori evidenziati in rosso.

WMI filter e Windows 11 24H2/25H2: il problema della build

Questa cade in trappola qualsiasi team che non ha aggiornato i propri filtri WMI dai tempi di Windows 10. Windows 11 24H2 (rilasciato ottobre 2024) e 25H2 (release attesa ottobre 2025 e ormai standard nel 2026) riportano una Version WMI nella classe Win32_OperatingSystem che comincia con 10.0.26100 per 24H2 e 10.0.26200 per 25H2. Qualunque WMI filter scritto ai tempi di Windows 10 con LIKE "10.0.19%" escludera' silenziosamente tutte le macchine 24H2/25H2. Il target GPO viene visto come "Denied (WMI Filter)" in gpresult e nessuno sa perche'.

Il modo corretto di filtrare "solo Windows 11" in una WQL query nel 2026 e':

-- Solo Windows 11 (build 22000 o superiore, esclude Server e Windows 10)
SELECT * FROM Win32_OperatingSystem
WHERE ProductType = 1
  AND BuildNumber >= 22000

-- Solo Windows 11 24H2 o superiore (comodo per policy nuove)
SELECT * FROM Win32_OperatingSystem
WHERE ProductType = 1
  AND BuildNumber >= 26100

-- Solo Windows 11 workstation escludendo VDI/multi-user
SELECT * FROM Win32_OperatingSystem
WHERE ProductType = 1
  AND BuildNumber >= 22000
  AND (OperatingSystemSKU = 48 OR OperatingSystemSKU = 49)

ProductType = 1 significa Workstation (2 e' DC, 3 e' Server). Usare BuildNumber invece di Version LIKE e' piu' robusto perche' non si spezza con ogni nuova release. Per testare velocemente la vostra query WMI da PowerShell su un client:

# Verifica sul client se la query WMI restituisce risultati
# Se restituisce l'oggetto, il filtro applichera'; se e' vuoto, no.
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE ProductType = 1 AND BuildNumber >= 22000"

Event ID 1058 e 1030: SYSVOL, DFS e permessi NTFS

Se in Event Viewer sotto Windows Logs > System filtrate per source GroupPolicy e vedete Event ID 1058 accoppiato a un 1030, il messaggio classico e': "Windows attempted to read the file \\dominio.local\SysVol\dominio.local\Policies\{GUID}\gpt.ini from a domain controller and was not successful". La descrizione dice tutto: il client non riesce a leggere gpt.ini. Le cause possibili, in ordine di probabilita':

1. Firewall blocca SMB verso il DC: firewall di terze parti aggiornato di recente, o policy di segmentazione che non prevede la porta 445 dal client verso il DC.
2. DFS client disabilitato: qualcuno ha impostato HKLM\SYSTEM\CurrentControlSet\Services\Mup\DisableDfs = 1. SYSVOL e' esposto via DFS namespace, quindi senza DFS client la share non e' raggiungibile.
3. Permessi NTFS su gpt.ini rotti: Authenticated Users deve avere Read + Execute su \\dominio.local\SysVol\dominio.local\Policies\{GUID}\. Se qualcuno ha ristretto le ACL, boom.
4. DFS-R con backlog: la GPO e' stata creata su un DC ma non ha replicato sugli altri. Il client fa autenticazione contro un DC che non ha ancora il GPT.
5. Antivirus che scansiona SYSVOL sul DC: file lock temporaneo che rende gpt.ini irraggiungibile per pochi secondi durante la scansione.

Il test rapido da eseguire sul client per confermare la (1) e la (2):

# 1. Verifica che la share SYSVOL sia raggiungibile
Test-NetConnection -ComputerName dc01.dominio.local -Port 445

# 2. Prova a leggere gpt.ini direttamente (sostituire GUID con quello del report gpresult)
Get-Content "\\dominio.local\SysVol\dominio.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini"

# 3. Verifica che il DFS client sia abilitato (deve essere 0 o assente)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Mup" -Name "DisableDfs" -ErrorAction SilentlyContinue

Sui DC ricordate di escludere C:\Windows\SYSVOL dallo scan real-time dell'antivirus: e' una best practice Microsoft, ma metta la mano sul fuoco chi lo ha ancora attivo. Per la Microsoft Q&A ufficiale sul tema fate riferimento alla documentazione Microsoft Learn sull'evento 1058.

Registry.pol corrotto: come rigenerare la cache locale

Quando la comunicazione con AD e' pulita ma le policy locali continuano a non applicarsi, il sospetto numero uno e' il Registry.pol corrotto. Windows tiene la cache delle policy locali in due file:

• C:\Windows\System32\GroupPolicy\Machine\Registry.pol per le policy Computer
• C:\Windows\System32\GroupPolicy\User\Registry.pol per le policy User

Uno shutdown durante l'applicazione policy, un aggiornamento cumulativo fallito (KB5074109 e' stato particolarmente sciagurato su questo) o un antivirus troppo zelante possono lasciare il file inconsistente. Il fix e' rinominare (non eliminare, mai) e riavviare - Windows rigenera i file vuoti al boot successivo e ripopola con le GPO domain-linked:

# Eseguire da PowerShell elevato sul client
# Backup difensivo: rinominiamo, non cancelliamo
$timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
Rename-Item "C:\Windows\System32\GroupPolicy\Machine\Registry.pol" "Registry.pol.$timestamp.bak"
Rename-Item "C:\Windows\System32\GroupPolicy\User\Registry.pol" "Registry.pol.$timestamp.bak" -ErrorAction SilentlyContinue

# Forza refresh dopo il rename
gpupdate /force

# Riavvio (le policy computer-side richiedono un boot per rileggere)
Restart-Computer -Force

Servizio Group Policy Client (gpsvc) non parte

Il servizio Group Policy Client (gpsvc) e' quello che processa fisicamente le GPO all'avvio e ai refresh. Su Windows 11 e' impostato come Automatic (Trigger Start) e - punto importante per i tier-1 - non si puo' arrestare o riavviare dalla console services.msc: i pulsanti sono grigi per policy. Se il servizio non parte, il fix e' via registry:

# Verifica lo stato del servizio
Get-Service -Name gpsvc

# Se il servizio e' Stopped e i pulsanti sono grigi, controllare questi due registry key
# 1. Chiave del servizio - deve esistere
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\gpsvc"

# 2. Chiave del gruppo di hosting - deve esistere e contenere GPSvcGroup
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost" -Name "GPSvcGroup" -ErrorAction SilentlyContinue

# Se manca la GPSvcGroup, ricreare la struttura corretta
$svcHostPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost"
New-ItemProperty -Path $svcHostPath -Name "GPSvcGroup" -PropertyType MultiString -Value "GPSvc" -Force

# Ricreare la chiave dei parametri per gpsvc
$gpsvcParams = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost\GPSvcGroup"
New-Item -Path $gpsvcParams -Force
New-ItemProperty -Path $gpsvcParams -Name "AuthenticationCapabilities" -PropertyType DWord -Value 0x3020
New-ItemProperty -Path $gpsvcParams -Name "CoInitializeSecurityParam" -PropertyType DWord -Value 1

# Riavvio obbligatorio dopo modifica registry
Restart-Computer -Force

Nel 99% dei casi che ho visto in helpdesk, la corruzione della GPSvcGroup e' dovuta a un tool di "system cleaner" installato dall'utente. Bandire quel tipo di software con AppLocker o Windows Defender Application Control (WDAC) e' la cura definitiva.

Abilitare gpsvc.log per il debug avanzato

Quando Event Viewer non basta e i log GroupPolicy sono generici, si abilita il debug logging del servizio Group Policy. Questo produce un gpsvc.log in C:\Windows\Debug\UserMode\gpsvc.log con la traccia completa di ogni operazione GP - CSE eseguite, tempi, errori dettagliati.

# Abilitare il debug logging di gpsvc (richiede riavvio)
$diagPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics"
if (-not (Test-Path $diagPath)) { New-Item -Path $diagPath -Force }
New-ItemProperty -Path $diagPath -Name "GPSvcDebugLevel" -PropertyType DWord -Value 0x30002 -Force

# Assicurarsi che la cartella di destinazione esista
New-Item -ItemType Directory -Path "C:\Windows\Debug\UserMode" -Force -ErrorAction SilentlyContinue

# Riavviare per iniziare la registrazione
Restart-Computer -Force

# Dopo aver riprodotto il problema, disabilitare il logging
Remove-ItemProperty -Path $diagPath -Name "GPSvcDebugLevel"

Loopback processing e ordine di applicazione

Il loopback processing e' la feature piu' male-utilizzata di Group Policy - detto senza mezzi termini. Serve a un caso specifico: applicare policy User a un utente basandosi sul computer a cui e' loggato (tipico scenario: kiosk, sala riunioni, VDI). Fuori da questi casi, e' un colpo di piede.

Due modalita':

• Replace: le policy User dell'utente vengono sostituite da quelle linkate al computer. Nessuna policy user standard viene applicata.
• Merge: le policy User dell'utente vengono combinate con quelle del computer, con precedenza a quelle del computer in caso di conflitto.

Configurazione: Computer Configuration > Administrative Templates > System > Group Policy > Configure user Group Policy loopback processing mode. Se una policy user non si applica sui client di una sala riunioni e vedete che gpresult mostra la GPO come "Applied" ma i valori non ci sono, controllate se loopback e' in Replace: le policy user standard sono state saltate di proposito.

Ordine di applicazione (LSDOU)

Windows applica le GPO in ordine LSDOU: Local, Site, Domain, Organizational Unit (dalla piu' esterna alla piu' interna). L'ultima applicata vince, a meno che una GPO padre abbia Enforced o una OU figlia abbia Block Inheritance. Enforced batte Block Inheritance sempre.

gpupdate /force non funziona: cosa controllare

Se gpupdate /force restituisce "Computer policy could not be updated successfully", la lista di controllo e' breve. Come suggerisce la guida Windows OS Hub sul troubleshooting delle GPO, i colpevoli piu' comuni sono:

1. Prompt non elevato: gpupdate gira anche senza admin ma per aggiornare il ramo Computer richiede privilegi elevati. Sempre Run as administrator.
2. Client non e' sulla rete aziendale: senza raggiungibilita' del DC (via LAN o VPN) le policy domain non arrivano. Verificare con nltest /dsgetdc:dominio.local.
3. Kerberos time skew: se l'orologio del client differisce dal DC di piu' di 5 minuti, l'autenticazione Kerberos fallisce e la sessione autenticata verso SYSVOL non viene stabilita.
4. Machine account password fuori sincro: se la macchina e' stata offline per settimane, il segreto della trust puo' essere disallineato. Da PowerShell elevato: Test-ComputerSecureChannel -Repair -Credential (Get-Credential).
5. Servizio gpsvc fermo o corrotto: cfr. sezione dedicata piu' sopra.

Se la VPN e' coinvolta - scenario comune sul lavoro remoto - controllate anche il timing: molte VPN si connettono dopo il logon, quindi il client cerca di applicare policy Computer prima che il tunnel sia su. La nostra guida al troubleshooting delle VPN aziendali su Windows 11 copre i profili "Always On" e le impostazioni di logon script che risolvono esattamente questo problema di ordine di applicazione.

Playbook helpdesk: script di triage in 60 secondi

Questo e' lo script che faccio girare ai tier-1 su ogni ticket "GPO non applicata". Genera un dossier completo che, se non risolve, permette al tier-2 di lavorare in 5 minuti invece di 30:

# PSGpoTriage.ps1
# Uso: eseguire da PowerShell elevato sulla macchina interessata
# Output: C:\Temp\GPO-Triage--\ con tutto il necessario

# Crea cartella di output
$hostname = $env:COMPUTERNAME
$timestamp = Get-Date -Format "yyyyMMdd-HHmm"
$outDir = "C:\Temp\GPO-Triage-$hostname-$timestamp"
New-Item -ItemType Directory -Path $outDir -Force | Out-Null

Write-Host "Raccolta dati per $hostname ..." -ForegroundColor Cyan

# 1. Report gpresult HTML completo (computer + user)
gpresult /h "$outDir\rsop.html" /f 2>&1 | Out-Null

# 2. Report gpresult text verbose
gpresult /r /v > "$outDir\gpresult-verbose.txt" 2>&1

# 3. Event log GroupPolicy (ultime 24h)
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-GroupPolicy'
    StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Export-Csv "$outDir\gpo-events-24h.csv" -NoTypeInformation

# 4. Stato servizio gpsvc
Get-Service -Name gpsvc | Format-List * > "$outDir\gpsvc-status.txt"

# 5. Test connettivita' verso il DC autenticante
$dcInfo = nltest /dsgetdc:$env:USERDNSDOMAIN 2>&1
$dcInfo | Out-File "$outDir\dc-info.txt"
$dcName = ($dcInfo | Select-String "DC: \\\\").ToString().Split('\\')[-1].Trim()
if ($dcName) {
    Test-NetConnection -ComputerName $dcName -Port 445 |
        Format-List | Out-File "$outDir\smb-test.txt"
}

# 6. Test secure channel
Test-ComputerSecureChannel -Verbose *>&1 |
    Out-File "$outDir\secure-channel.txt"

# 7. Verifica orologio (Kerberos richiede skew < 5 minuti)
w32tm /query /status > "$outDir\time-status.txt" 2>&1

# 8. Snapshot Registry.pol size (0 byte = corrotto)
Get-ChildItem "C:\Windows\System32\GroupPolicy" -Recurse -File |
    Select-Object FullName, Length, LastWriteTime |
    Format-Table -AutoSize | Out-File "$outDir\registry-pol-status.txt"

Write-Host "Fatto. Dossier salvato in: $outDir" -ForegroundColor Green
Write-Host "Aprire prima rsop.html, poi gpo-events-24h.csv" -ForegroundColor Yellow

Impacchettatelo come action nel vostro RMM (Intune, NinjaOne, N-able, whatever) e il tempo medio di risoluzione dei ticket GPO scende del 40-50% rispetto al triage manuale. Sono numeri veri dal mio team, non marketing.

Domande frequenti

Perche' la Group Policy non viene applicata anche dopo gpupdate /force?

Perche' gpupdate non risolve i problemi a monte: se una GPO e' filtrata per security o WMI, o se il client non riesce a leggere SYSVOL, l'update fallira' esattamente come prima. Partire sempre da gpresult /h rsop.html /f per capire quale GPO e' Denied e con quale motivo, poi agire sul motivo.

Cosa significa Denied (WMI Filter) in gpresult?

Significa che la GPO ha un filtro WMI associato e la query WQL non ha restituito risultati sulla macchina target. Su Windows 11 24H2/25H2 e' quasi sempre dovuto a filtri scritti per Windows 10 con Version LIKE "10.0.19%": aggiornarli a BuildNumber >= 22000 risolve.

Quanto tempo impiega Windows ad applicare una nuova GPO?

Per default 90 minuti + offset random 0-30 minuti (quindi tra 90 e 120 minuti). Le policy che richiedono foreground processing (software install, folder redirection, drive mapping) si applicano solo a boot o logon. In laboratorio potete forzare con gpupdate /force /boot /logoff, in produzione mai perche' logga fuori l'utente.

Come posso vedere quale GPO ha impostato un determinato valore?

Nel report HTML di gpresult /h, sotto ogni policy setting la colonna "Winning GPO" mostra il nome della GPO che ha impostato il valore finale. In alternativa, per un singolo setting registry, potete usare Group Policy Management Console > Group Policy Modeling per simulare l'applicazione senza toccare il client.

Perche' vedo Event ID 1058 nel log System del client?

Perche' il client non e' riuscito a leggere gpt.ini da SYSVOL. Le cause piu' comuni sono: SMB (porta 445) bloccato da firewall verso il DC, DFS client disabilitato sul client (DisableDfs = 1 nel registry), permessi NTFS ristretti su gpt.ini, o antivirus che scansiona SYSVOL sul DC bloccando i file. Il messaggio dell'evento indica il DC coinvolto e il GUID della GPO problematica.

Devo riavviare dopo aver rinominato Registry.pol?

Si, per le policy Computer. Rinominare il file e' un'operazione a caldo, ma Windows rilegge Machine\Registry.pol solo al boot successivo per le policy computer-side. Per le policy User basta un logoff/logon. Ricordate di rinominare (non cancellare) per poter fare rollback in caso di regressione inaspettata.