Group Policy nu se aplică în Windows 11: ghid complet de depanare pentru helpdesk (2026)

Actualizat: 8 iulie 2026

Când Group Policy nu se aplică în Windows 11, cauza este aproape întotdeauna una dintre trei: stația nu vede controlerul de domeniu la refresh, GPO-ul este blocat de un filtru (Security Filtering, WMI, sau permisiuni Authenticated Users lipsă după KB5008295), sau SYSVOL-ul returnează erori 1058/1030. Acest ghid rezolvă fiecare scenariu cu comenzi PowerShell și gpresult concrete, ordonate de la verificarea de 30 de secunde până la loguri gpsvc.log verbose. Este scris pentru tier-1 helpdesk, dar merge la fel de bine pentru admini seniori care caută un checklist rapid.

• Rulează gpresult /h C:\Temp\rsop.html înainte de orice altceva. Raportul HTML îți spune imediat care GPO a fost negat și motivul (Security Filtering, WMI Filter, Link Disabled).
• Windows 11 folosește build 10.0.22000+ sau 10.0.26100+; filtrele WMI vechi cu Version LIKE "10.0.19%" exclud silențios toate stațiile Windows 11.
• După patch-ul KB5008295, GPO-urile care au eliminat Authenticated Users din Delegation nu se mai aplică computerelor. Adaugă înapoi Authenticated Users cu drept de Read.
• Erorile Event ID 1058 și 1030 indică o problemă SYSVOL: fișier gpt.ini lipsă, replicare DFSR blocată, sau clock skew Kerberos peste 5 minute.
• gpupdate /force nu repară cauza refuzului. Doar reaplică GPO-urile care sunt deja în scope. Diagnostichează întâi cu gpresult.
• Pentru cazuri obscure, activează GPSvcDebugLevel=0x30002 în registry și citește %windir%\debug\usermode\gpsvc.log.

De ce nu se aplică Group Policy pe Windows 11

Am văzut aceeași scenă de zeci de ori: un utilizator zice că mapping-ul de imprimantă a dispărut sau că fundalul corporate nu mai apare. Primul reflex greșit e "hai să rulăm gpupdate /force și vedem". Nu. Mai întâi trebuie să înțelegi de ce nu se aplică, pentru că gpupdate reaplică politicile în scope, nu le adaugă în scope. Dacă un GPO este negat de un filtru, un al doilea refresh dă exact același rezultat.

Din experiența mea pe stații Windows 11 22H2/23H2/24H2, cauzele apar în această ordine de frecvență: (1) computerul nu este în OU-ul unde este linkat GPO-ul, (2) Authenticated Users a fost șters din Delegation și, după KB5008295, Windows refuză să mai citească GPO-ul cu contul de computer, (3) un filtru WMI cu versiune OS învechită, (4) linkul GPO este dezactivat sau are ordinea de precedență greșită cu Block Inheritance, (5) probleme SYSVOL (gpt.ini nu poate fi citit sau DFSR-ul nu a replicat modificarea între controlere), (6) stația nu are conectivitate LDAP către un DC (Event ID 1129), și doar în ultimă instanță o coruptie locală de cache în %windir%\System32\GroupPolicy. Restul articolului urmează exact această ordine.

Dacă lucrezi cu un mediu mai complex care include politici de blocare a conturilor, merită să citești și ghidul de depanare a conturilor blocate în Active Directory. Multe erori 1058 vin la pachet cu Kerberos supărat pe clock skew.

Cum forțez actualizarea Group Policy corect

Prima comandă pe care o rulezi pe stația afectată. Regula simplă: deschide PowerShell ca administrator, nu ca utilizator standard. Un gpupdate lansat fără elevare aplică doar politicile de user (User Configuration), pierzând complet Computer Configuration, și tocmai acolo sunt de obicei mapping-urile de imprimantă, restricțiile de firewall și setările Windows Update.

# Refresh complet (Computer + User) fara asteptare, cea mai comuna varianta
gpupdate /force

# Doar Computer Configuration (util cand ai schimbat setari de deployment de software sau firewall)
gpupdate /target:computer /force

# Doar User Configuration (folder redirection, drive mappings, browser homepage)
gpupdate /target:user /force

# Refresh + logoff automat (pentru politici care necesita re-logon, ex. loopback processing)
gpupdate /force /logoff

# Refresh + restart automat (pentru software installation via GPP)
gpupdate /force /boot

# Asteapta maxim 120 secunde ca refresh-ul sa termine inainte sa dea prompt-ul inapoi
gpupdate /wait:120 /force

Dacă vezi mesajul "Updating policy... Computer Policy update has completed successfully. User Policy update has completed successfully.", asta nu înseamnă că politicile au fost aplicate. Înseamnă doar că motorul GP a rulat fără erori. Un GPO refuzat de un filtru WMI raportează exact același succes. Confirmarea reală vine din gpresult, care e pasul următor.

Cum verific ce GPO-uri sunt aplicate cu gpresult

gpresult este singura comandă care îți răspunde la întrebarea "de ce nu se aplică". Raportează exact ce GPO-uri au fost procesate ultima dată de motorul Group Policy, care au fost negate, și motivul negării: Security Filtering, WMI Filter, Empty, Disabled Link, Inaccessible sau Access Denied.

# Sumar rapid in consola, bun pentru un check de 10 secunde
gpresult /r

# Raport HTML complet (recomandat), arata filtrele si extensiile per GPO
gpresult /h C:\Temp\rsop.html /f

# Raport pentru un utilizator specific (ruleaza ca admin)
gpresult /user CORP\ionpopescu /h C:\Temp\rsop-user.html /f

# Raport pentru un computer remote (necesita RSAT + firewall permisiv pentru RPC)
gpresult /s WKS-1234.corp.local /h C:\Temp\rsop-remote.html /f

# Doar Computer Configuration (fara User), util cand nu esti logat cu userul afectat
gpresult /scope computer /h C:\Temp\rsop-computer.html /f

Deschide raportul HTML în Edge sau Chrome. În secțiunea Computer Details → Applied GPOs vezi ce s-a aplicat cu succes. În Denied GPOs ai lista celor negate, cu coloana Reason Denied. Iată ce înseamnă fiecare mesaj în practică:

• Access Denied (Security Filtering): contul de computer/user nu are permisiunea Apply Group Policy. Verifică tabul Delegation al GPO-ului. Vezi și secțiunea despre KB5008295 mai jos.
• Denied (WMI Filter): interogarea WQL a returnat zero rezultate pe stație. Rulează manual Get-CimInstance -Query "<query>" ca să verifici ce lipsește.
• Empty: GPO-ul nu conține setări în partea de configurare care ar trebui să se aplice (Computer sau User). Deschide GPMC, mergi pe tabul Settings, verifică că nu e "Not configured" peste tot.
• Disabled Link: linkul spre OU a fost dezactivat. Right-click pe link în GPMC → Link Enabled.
• Inaccessible: stația nu poate contacta un DC. Verifică rezolvarea DNS pentru _ldap._tcp.corp.local și conectivitatea pe portul 389.

Pentru PowerShell native (mai curat pentru scripting și rapoartele periodice pe fleet), folosește modulul GroupPolicy livrat cu RSAT:

# Raport RSoP echivalent cu gpresult, dar in XML structurat
Get-GPResultantSetOfPolicy -ReportType Xml -Path C:\Temp\rsop.xml

# Sumar per GPO existent in domeniu (nu doar cele aplicate)
Get-GPO -All | Select-Object DisplayName, GpoStatus, ModificationTime

# Extrage intreaga configuratie a unui GPO in XML, util pentru diff intre modificari
Get-GPOReport -Name "Corp - Mapping Imprimante" -ReportType Xml -Path C:\Temp\gpo-print.xml

Depanare erori Event ID 1058 și 1030 (SYSVOL)

Când vezi în Event Viewer (Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational) evenimentele 1058 ("Processing of Group Policy failed. Windows attempted to read the file \\domain\SysVol\domain\Policies\{GUID}\gpt.ini") și 1030 ("The processing of Group Policy failed"), problema este aproape întotdeauna la nivelul SYSVOL, nu la stație. Fixează 1058 și 1030 dispare de la sine.

Verificarea de bază: deschide pe stația afectată calea completă din eveniment în Explorer.

# Copiaza GUID-ul din eventul 1058 si substituie-l aici
$guid = "31B2F340-016D-11D2-945F-00C04FB984F9"   # exemplu: Default Domain Policy
$domain = "corp.local"

# Verifica daca gpt.ini este accesibil
Test-Path "\\$domain\SysVol\$domain\Policies\{$guid}\gpt.ini"

# Daca returneaza False, testeaza share-ul de baza
Test-Path "\\$domain\SysVol\$domain\Policies"
Test-Path "\\$domain\NETLOGON"

Dacă share-ul SYSVOL este vizibil dar gpt.ini lipsește sau este 0 bytes pe un anumit DC, ai o problemă de replicare DFSR. Rulează pe fiecare DC:

# Starea replicarii DFSR pentru SYSVOL
Get-DfsrState -ComputerName DC01

# Backlog intre DC-uri (0 inseamna sincronizat)
Get-DfsrBacklog -GroupName "Domain System Volume" -FolderName SYSVOL_SHARE `
  -SourceComputerName DC01 -DestinationComputerName DC02

# Ultimul eveniment de replicare, cauta Event ID 4602 (initial sync complete)
Get-WinEvent -LogName "DFS Replication" -MaxEvents 20 | Format-Table TimeCreated, Id, Message -AutoSize

Alte cauze frecvente pe care le-am întâlnit la ticket-uri de rutină:

• Antivirus care scanează SYSVOL: adaugă exclusion pentru %SystemRoot%\SYSVOL pe toate DC-urile.
• Permisiuni NTFS stricate pe folderul GPO: Authenticated Users trebuie să aibă Read + Execute pe {GUID} și pe fișierele din interior.
• SMB signing forțat prin GPO care se aplică chiar înainte ca stația să se autentifice, un catch-22 clasic pe stații nou-adăugate în domeniu.
• Serviciul DFS Client dezactivat: verifică Get-Service DfsC, trebuie să fie Running și cu StartType Automatic.

WMI Filters: capcana silențioasă pe Windows 11

Filtrele WMI sunt cea mai frecventă cauză de "nu se aplică" care nu apare în nicio eroare vizibilă. Stația raportează succes, dar GPO-ul este negat cu Reason: Denied (WMI Filter) în gpresult. Problema apare masiv pe fleet-uri care au migrat de la Windows 10 la Windows 11 fără să audite filtrele existente.

Cazul clasic: un filtru "Doar Windows 10" scris ca SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.19%" exclude silențios toate stațiile Windows 11, care raportează Version 10.0.22000 (21H2), 10.0.22621 (22H2), 10.0.22631 (23H2) sau 10.0.26100 (24H2). Testează filtrul manual pe o stație Windows 11:

# Vezi ce versiune raporteaza statia (Win11 24H2 = 10.0.26100)
Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber

# Testeaza exact interogarea din filtrul WMI
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE ""10.0.22%"""
# Daca returneaza un obiect -> filtrul se aplica. Daca returneaza null -> GPO-ul este negat.

# Interogare corecta pentru "toate versiunile Windows 11" (build 22000+)
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE Version >= '10.0.22000'"

# Alternativa mai robusta: filtreaza dupa ProductType (1=workstation, 2=DC, 3=member server)
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE ProductType = 1 AND Version >= '10.0.22000'"

Un al doilea gotcha pe care l-am prins recent la un client: filtrele care folosesc Win32_ComputerSystem.Model pentru targeting hardware nu mai returnează string-ul așteptat pe stațiile ARM64 (Snapdragon X, Copilot+ PCs). Dacă rulezi un fleet mixt, adaugă un filtru secundar pe Win32_Processor.Architecture (9 = x64, 12 = ARM64) sau renunță complet la filtrele WMI și folosește Item-Level Targeting din Group Policy Preferences, care este evaluat de client-side extension și e semnificativ mai rapid.

Security Filtering după KB5008295

În noiembrie 2021 Microsoft a lansat KB5008295, care a schimbat modul în care GPO-urile citesc datele din SYSVOL. Înainte, un GPO putea funcționa chiar și fără Authenticated Users în Delegation, atâta timp cât Security Filtering permitea aplicarea către un grup de securitate specific. După KB5008295, contul de computer trebuie să aibă cel puțin permisiunea Read pentru a putea prelua GPO-ul de pe SYSVOL. Dacă Authenticated Users lipsește complet, computerul nu mai poate citi politica, iar aplicarea eșuează silențios.

Simptomul clasic: politica funcționa perfect luni de zile, apoi după un patch tuesday "au dispărut" restricțiile pentru un grup de utilizatori. Verifică prin PowerShell:

# Vezi toate permisiunile pentru un GPO
Get-GPPermission -Name "Corp - Restrictii USB" -All

# Daca Authenticated Users nu apare in lista, adauga-l cu Read (NU cu Apply Group Policy)
Set-GPPermission -Name "Corp - Restrictii USB" `
  -TargetName "Authenticated Users" `
  -TargetType Group `
  -PermissionLevel GpoRead

# Verifica permisiunile pe TOATE GPO-urile din domeniu, util dupa audit-uri
Get-GPO -All | ForEach-Object {
    $perms = Get-GPPermission -Guid $_.Id -All -ErrorAction SilentlyContinue
    $hasAuth = $perms | Where-Object { $_.Trustee.Name -eq "Authenticated Users" }
    [PSCustomObject]@{
        Name = $_.DisplayName
        HasAuthenticatedUsers = [bool]$hasAuth
        Permission = $hasAuth.Permission
    }
} | Where-Object { -not $_.HasAuthenticatedUsers } | Format-Table -AutoSize

Distincția importantă: pentru Security Filtering targetat, adaugă Authenticated Users cu GpoRead, nu cu GpoApply. Read îi dă doar dreptul să citească fișierele din SYSVOL, în timp ce Apply e ce controlează cine primește politica. Un GPO cu Authenticated Users-Read plus Marketing Group-Apply se aplică doar Marketing Group, dar toată lumea poate citi. Este exact ce vrei.

Loguri gpsvc.log verbose pentru cazuri grele

Când gpresult, Event Viewer și interogările WMI toate zic "totul e OK" dar politica tot nu se aplică, ultima resursă este Group Policy Service Debug Log. Este un log verbose de tot ce face motorul GP la fiecare refresh: rezolvare DNS, contactare DC, download SYSVOL, evaluare filtre, invocare de client-side extensions. Îl activezi cu o cheie de registry.

# Activeaza gpsvc.log, necesita restart al serviciului sau reboot
$path = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics"
if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }

# Nivel 0x30002 = verbose complet, cu detalii per extensie
Set-ItemProperty -Path $path -Name "GPSvcDebugLevel" -Value 0x30002 -Type DWord

# Restart serviciul Group Policy Client (poate cere reboot pe Win11 24H2)
Restart-Service gpsvc -Force

# Forteaza refresh si asteapta
gpupdate /force

# Deschide logul (fisierul poate depasi 100 MB, foloseste un editor rapid, nu Notepad)
notepad "$env:windir\debug\usermode\gpsvc.log"

# CRITIC: dezactiveaza logul cand termini, altfel umple discul in 24-48h
Remove-ItemProperty -Path $path -Name "GPSvcDebugLevel" -ErrorAction SilentlyContinue
Restart-Service gpsvc -Force

Ce cauți în log: linia ProcessGPOList îți arată ordinea de procesare, ReadGPExtensions îți spune care Client-Side Extension (CSE) a rulat, iar liniile ProcessRegistryPolicy, ProcessSoftwareInstallation, ProcessFolderRedirection îți indică fiecare pas per GPO. Erorile apar ca hr = 0x80070005 (Access Denied) sau hr = 0x8007054b (domain not found). Documentația oficială pentru codurile hr este pe Microsoft Learn: Applying Group Policy troubleshooting guidance.

Pentru probleme reproductibile pe mai multe stații, colectează gpsvc.log în paralel pe 3–5 device-uri, apoi rulează un diff. De multe ori vezi imediat că un pas care e prezent pe stațiile funcționale lipsește pe cele defecte. La un client am prins astfel o problemă de firewall pe o subrețea de laptopuri: blocarea portului 445 pe hostul de VDI împiedica download-ul GPT.INI, dar în Event Viewer nu apărea nimic vizibil.

Checklist rapid tier-1 helpdesk

Ordinea asta a rezolvat probabil 90% din ticketele GPO pe care le-am primit anul trecut. Rulează în ordine, nu sări peste pași, chiar dacă pare evident că problema e alta.

1. Rulează gpresult /h C:\Temp\rsop.html /f ca administrator, deschide raportul, verifică secțiunile Applied GPOs și Denied GPOs.
2. Confirmă că stația vede un DC: nltest /dsgetdc:corp.local. Dacă răspunde cu un timeout, e problemă de DNS/VPN, nu de GPO.
3. Sincronizează ceasul: w32tm /resync /rediscover. Verifică drift cu w32tm /query /status.
4. Verifică apartenența la OU: Get-ADComputer $env:COMPUTERNAME -Properties DistinguishedName. OU-ul returnat trebuie să fie sub un container linkat la GPO.
5. Verifică Authenticated Users pe GPO (vezi secțiunea despre KB5008295).
6. Testează manual filtrul WMI dacă GPO-ul are unul (vezi secțiunea WMI).
7. Verifică că SYSVOL este accesibil: Test-Path "\\corp.local\SysVol\corp.local\Policies".
8. Golește cache-ul GP local: rd /s /q %windir%\System32\GroupPolicy apoi gpupdate /force. Necesită reboot după.
9. Numai dacă niciunul dintre pași nu ajută: activează gpsvc.log verbose și escaladează la tier-2.

Pentru probleme legate specific de politici Windows Update sau BitLocker, verifică și ghidul de depanare a actualizărilor Windows 11, care acoperă interacțiunea dintre Windows Update for Business și GPO-urile de deployment. Pentru probleme M365 care par legate de GPO dar de fapt sunt Conditional Access, ghidul de depanare Microsoft 365 pentru administratori IT îți arată cum să separi cele două straturi.

Referință oficială suplimentară pentru administratori seniori: Microsoft Learn: Group Policy processing descrie ordinea LSDOU (Local → Site → Domain → OU), iar documentul complet de troubleshooting pe GitHub conține tabelul complet de coduri hr pe care le poți întâlni în gpsvc.log.

Întrebări frecvente

Ce înseamnă eroarea "Windows failed to apply the Group Policy Registry settings"?

Înseamnă că motorul Group Policy a citit GPO-ul din SYSVOL, dar Client-Side Extension pentru Registry a eșuat la scrierea valorilor în HKLM sau HKCU. De obicei este o problemă de permisiuni NTFS pe cheia țintă, un antivirus care blochează modificarea, sau conflict cu un alt GPO care încearcă să scrie aceeași cheie. Rulează gpresult /h și caută secțiunea Extension: Registry, care arată exact ce eroare a returnat CSE-ul.

Group Policy se aplică pe Windows 11 Home?

Nu în sensul enterprise. Windows 11 Home nu include Local Group Policy Editor (gpedit.msc) și nu poate fi domain-joined, deci nu primește GPO-uri de la un DC Active Directory. Poți folosi alternative ca PolicyPlus sau MDM prin Microsoft Intune (Entra ID join), dar pentru un helpdesk corporativ răspunsul practic este: fă upgrade la Windows 11 Pro (aprox 99 USD prin Microsoft Store) sau folosește Intune cu Configuration Profiles.

Cât timp durează până se aplică o politică nouă?

Refresh-ul automat rulează la 90 de minute plus un offset aleator de 0–30 minute pe stații, și la 5 minute pe controlere de domeniu. Deci fereastra maximă normală este de 120 de minute. Politicile de folder redirection, drive mappings sau software installation necesită logoff/reboot pentru a se aplica complet, chiar și după gpupdate /force.

De ce vede utilizatorul politica în gpresult dar setarea nu funcționează?

De obicei este un conflict cu o setare locală (Local Group Policy sau modificare manuală în registry) care are precedență, sau CSE-ul relevant nu a rulat. Alte cauze comune: politica este de tip "Preference" (nu "Policy") și utilizatorul a modificat manual valoarea după aplicare. Preferences nu sunt tatuate ca Policies, ci scrise o singură dată. Rulează gpupdate /force /wait:120 și verifică din nou.

Ce fac dacă Central Store pentru ADMX nu conține template-urile Windows 11 24H2?

Descarcă pachetul oficial Administrative Templates (.admx) for Windows 11 2024 Update (24H2) de pe Microsoft Download Center, extrage-l local, apoi copiază conținutul folderului PolicyDefinitions în \\corp.local\SYSVOL\corp.local\Policies\PolicyDefinitions pe DC. După replicare (verifică cu Get-DfsrBacklog), consolele GPMC de pe toate stațiile de administrare vor vedea automat template-urile noi, fără reinstall.