Csoportházirend nem alkalmazódik Windows 11-en: gpresult és gpupdate hibaelhárítás 2026

Frissítve: 2026. július 2.

Ha a csoportházirend nem alkalmazódik Windows 11-es kliensen, a leggyakoribb ok, hogy a gép egy szűrt vagy hatáskörön kívüli OU-ban van, illetve hogy a biztonsági szűrés (Security Filtering) vagy egy WMI-szűrő kizárja a gépet. A gyors ellenőrzés három paranccsal indul: gpupdate /force, gpresult /h report.html, és a Csoportházirend-eredmények (RSoP) elemzése. Ebben az útmutatóban végigmegyünk a teljes helpdesk-diagnosztikán (az LSDOU sorrendtől a lassú bejelentkezésig), konkrét PowerShell-kódokkal, amiket a tier‑1 kollégák is használhatnak.

• A csoportházirend feldolgozási sorrendje: Local → Site → Domain → OU (LSDOU); az utolsó felülírja a korábbit, kivéve ha „Enforced” beállítás van.
• A gpupdate /force újra alkalmazza az összes GPO-t, de nem javít elgépelt WMI-szűrőt vagy hiányzó Read jogot.
• A gpresult /h C:\Temp\rsop.html /f a legjobb egyetlen parancs, amit tier‑1 kollégának meg lehet mutatni. HTML-jelentést ad, amiben látszanak a szűrt GPO-k.
• 2026-ban a leggyakoribb hiba: az „Authenticated Users” Read jogát eltávolították egy GPO-ról, ezért a gépek csendben átugorják.
• Lassú bejelentkezés (>30s) esetén az Event Viewer GroupPolicy/Operational naplójában az Event ID 5308–5320 tranzakciós ideje mutatja a szűk keresztmetszetet.
• Távoli RSoP-hoz használd az Invoke-GPUpdate és Get-GPResultantSetOfPolicy parancsokat, ne a régi rsop.msc MMC-t.

Hogyan alkalmazódik a csoportházirend Windows 11-en?

A csoportházirend alkalmazási sorrendje az LSDOU: Local, Site, Domain, Organizational Unit. A gép induláskor és a felhasználó bejelentkezéskor 90–120 perces (véletlenszerűen offsetelt) intervallumban is frissíti, plusz háttérben minden 90 percben, tartományvezérlőkön 5 percben. Az utolsó feldolgozott házirend nyer, kivéve ha a magasabb szinten „Enforced” (kikényszerített) jelölés van, mert az lefölözi a lentebbieket.

Fontos megérteni, hogy a Local Group Policy (helyi házirend) a gépen tárolódik a %windir%\System32\GroupPolicy mappában, míg a tartományi GPO-k a SYSVOL osztott mappán keresztül replikálódnak (\\domain.local\SYSVOL\domain.local\Policies\{GUID}). Ha a SYSVOL DFSR-replikációja megáll (2026-ban ez FRS-ről migrált környezetekben még mindig előfordul), a gép egyszerűen a saját, elavult másolatát fogja használni. Ilyenkor a dfsrdiag replicationstate parancs a DC-n mutatja a torlódást.

A számítógépes rész (Computer Configuration) mindig a gép Active Directory-fiókjának helyétől függ, nem attól, hol van a bejelentkezett felhasználó. Ezt gyakran keverik össze junior kollégák. Őszintén, láttam már órákat elveszíteni azzal, hogy egy felhasználói OU-ba tett GPO-t vártak számítógépes viselkedésre.

Hogyan kényszeríthető a csoportházirend frissítése?

A klasszikus parancs a gpupdate /force, de érdemes tudni, mi a különbség a sima gpupdate és a /force között. A sima gpupdate csak a megváltozott GPO-kat alkalmazza (verziószám alapján a gpt.ini-ből), míg a /force minden házirendet újra letölt és alkalmaz, akkor is, ha nem változott. Utóbbi lassabb, de a helpdesk 90%-ában ezt kell futtatni, mert így derül ki, hogy egy szűrő vagy jog blokkolja a gépet.

# Csak a megvaltozott hazirendek frissitese - gyorsabb
gpupdate

# Osszes hazirend ujraalkalmazasa - ez a debug-hoz kell
gpupdate /force

# Ha felhasznaloi resz is kell, kijelentkezes utan
gpupdate /force /logoff

# Ujraindulast igenylo hazirendekhez (pl. mappa-atiranyitas)
gpupdate /force /boot

# Csak a szamitogepes vagy csak a felhasznaloi resz
gpupdate /target:computer /force
gpupdate /target:user /force

Egy dolog, amit a Microsoft dokumentáció nem hangsúlyoz: a gpupdate aszinkron. Ha script-ből futtatod és utána azonnal ellenőrzöd az eredményt, előfordulhat, hogy a kliens még nem végzett. Adj neki 30–60 másodpercet, vagy figyeld az Event Viewer Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational naplóban az Event ID 8001-et, ami a feldolgozás befejezését jelzi.

Ha távolról szeretnéd frissíteni több gépen egyszerre (például egy új tartománycsatlakoztatott laptop-kötegen), használd a PowerShell Invoke-GPUpdate cmdletet, amely 2016 óta része a GroupPolicy modulnak, vagy a Csoportházirend-kezelő konzol (GPMC) OU-ján a jobb kattintás → „Group Policy Update” opciót. Utóbbi WMI-n és RPC-n keresztül kényszerít, ezért a Windows Firewall szabályokban engedélyezni kell a „Remote Scheduled Tasks Management” profilt.

gpresult HTML-jelentés olvasása lépésről lépésre

A gpresult az eszközöm, ha ki kell deríteni, miért nem alkalmazódik egy házirend. Három formátuma van, de a HTML-jelentés az egyetlen, amit tier‑1 kollégának meg lehet mutatni anélkül, hogy le kelljen ülni mellé.

# HTML jelentes az aktualis felhasznalorol es gepezrol
gpresult /h C:\Temp\rsop.html /f

# Csak a szamitogepes resz - felhasznaloi jogok nelkul is fut
gpresult /h C:\Temp\rsop.html /scope:computer /f

# Tavoli gepen (a fiokod local admin kell legyen a celen)
gpresult /s CLIENT01 /h \\fileserver\logs\CLIENT01-rsop.html /f

# Reszletes szoveges kimenet - script feldolgozashoz
gpresult /v > C:\Temp\rsop.txt

A HTML-jelentésben a legfontosabb szekció a „Denied GPOs”. Itt látszanak azok a házirendek, amelyeket a rendszer szándékosan kihagyott, és ok is szerepel mellette: „Access Denied (Security Filtering)”, „Denied (WMI Filter)”, vagy „Empty” (üres, tehát mind a Computer, mind a User rész üres). Ha itt szerepel a keresett GPO, tudod, hogy nem replikációs probléma van, hanem szűrés.

Az „Applied GPOs” alatt látszik a precedencia is (Winning GPO). Ha két GPO ugyanazt a beállítást állítja be, csak az utoljára feldolgozott érvényesül, kivéve, ha valamelyiken „Enforced” van. A precedenciaszámok kisebb értéke jelenti a magasabb prioritást (1 = legmagasabb). Ez rengeteg junior kollégát összezavar.

Miért nem alkalmazódik a csoportházirendem?

A 2026-os helpdesk-tapasztalatom szerint hét dolog a hibaesetek 95%-át adja. Sorrendben, gyakoriság szerint:

1. Elrontott Security Filtering. Valaki eltávolította az „Authenticated Users” csoportot a Delegation fülről, hogy csak egy adott biztonsági csoportra korlátozza a GPO-t. A gépeknek is Read jog kell. Ha csak felhasználói csoport marad, a gép nem tudja olvasni a GPO-t, és csendben átugorja. Javítás: add hozzá az „Authenticated Users”-t vagy a „Domain Computers”-t Read joggal (ne Apply-jal).
2. Rossz OU. A gép nem abban az OU-ban van, ahova a GPO linkelve van. Ellenőrzés: dsquery computer -name CLIENT01 vagy (Get-ADComputer CLIENT01).DistinguishedName.
3. WMI Filter hiba. A szűrő WQL-je hibás vagy nem illeszkedik. Ellenőrzés: futtasd a szűrő WQL-jét a kliensen a Get-WmiObject -Query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.0.26100%'" paranccsal (Windows 11 24H2).
4. Block Inheritance. Az OU-n van egy „Block Inheritance” jelölés, ami elvágja a felette lévő GPO-k öröklését. A GPMC-ben ilyenkor kék felkiáltójel látszik.
5. Loopback processing rosszul beállítva. A User Group Policy Loopback Processing „Replace” módban felülírja a felhasználói házirendeket, ez terminal server / RDS-es környezetben szokott meglepetést okozni.
6. SYSVOL replikációs hiba. A GPO GPT (fájl) része nem replikálódott a legközelebbi DC-re. Verziószám-eltérés a GPMC-ben az AD Attributes és SYSVOL Attributes oszlopok között.
7. DNS és Kerberos hiba. Ha a kliens nem éri el a DC-t a helyes _ldap._tcp SRV rekordon keresztül, egyáltalán nem tud GPO-t kérni. Ellenőrzés: nltest /dsgetdc:domain.local.

Ha a probléma tartós autentikációs jellegű, akkor gyakran az AD-oldalon van a hiba oka. Hasonló tüneteket okozhat a rossz jelszó miatt zárolt AD-fiók is, mert a zárolt gépfiók sem tudja olvasni a GPO-kat.

Távoli RSoP futtatása PowerShell-lel

A régi rsop.msc MMC snap-in helyi géphez van kötve és Windows 11 24H2-ben már deprecated (elavult) státuszú a Microsoft Windows 11 deprecated features listája szerint. 2026-ban a hivatalos módszer a PowerShell GroupPolicy modulja.

# GroupPolicy modul betoltese - tartomanyvezerlon vagy RSAT-tal
Import-Module GroupPolicy

# Tavoli RSoP HTML formatumban egy adott felhasznalora es gepre
Get-GPResultantSetOfPolicy `
    -User "DOMAIN\jsmith" `
    -Computer "CLIENT01" `
    -ReportType Html `
    -Path "\\fileserver\logs\CLIENT01-jsmith.html"

# Csak a szamitogepes resz - hasznos ha a felhasznalo nincs bejelentkezve
Get-GPResultantSetOfPolicy `
    -Computer "CLIENT01" `
    -ReportType Xml `
    -Path "C:\Temp\CLIENT01.xml"

# Kotegelt frissites: OU osszes gepenek gpupdate /force parancsa
Get-ADComputer -Filter * -SearchBase "OU=Laptops,DC=domain,DC=local" |
    ForEach-Object {
        Invoke-GPUpdate -Computer $_.Name -Force -RandomDelayInMinutes 0
    }

Egy fontos figyelmeztetés: az Invoke-GPUpdate ütemezett feladatot hoz létre a célgépen (nem RPC-n futtatja), ezért ha a Task Scheduler szolgáltatás áll, vagy a Windows Firewall blokkolja a „Remote Scheduled Tasks Management” profilt, a parancs csendben elbukik. Erről a Microsoft Learn Invoke-GPUpdate dokumentációja részletesen ír.

Lassú bejelentkezés és GPO-diagnosztika az Event Log-ban

Ha felhasználó 30 másodpercnél tovább vár a Windows 11-es bejelentkezésre, a bűnös 80%-ban egy lassú GPO Client-Side Extension (CSE), jellemzően a Group Policy Preferences (Drive Maps), Folder Redirection, vagy Software Installation. Az azonosítás menete:

1. Nyisd meg az Event Vieweret → Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational.
2. Szűrj a bejelentkezés időpontjára, és keresd az Event ID 4001-t (feldolgozás indítása) és Event ID 8001-t (feldolgozás vége). A különbség adja a teljes GPO-időt.
3. A közbülső Event ID 5308–5320 események mindegyike egy CSE-hez tartozik, és mutatja annak külön futásidejét ezredmásodpercben. Így pontosan látszik, melyik CSE fogyaszt.
4. A Event ID 7017 és 1085 hibák hálózati vagy hitelesítési problémát jeleznek. DNS-t és Kerberost kell nézni.

Ha Drive Map preferencia a szűk keresztmetszet, gyakran egy nem elérhető fájlszerver okozza: a CSE 30 másodpercig várja az SMB-kapcsolatot, mielőtt lemondana. Vedd fel a Drive Map elemet Item-Level Targetinggel, hogy csak megfelelő géptípuson próbálkozzon (pl. „Client OS: Windows 11”). Egy másik tipikus lassítás a régi WMI-szűrők halmozódása; 2026-ban minden WMI-szűrős GPO extra 100–300 ms-t ad a bejelentkezéshez a szűrő kiértékelése miatt.

Windows 11-ben a bejelentkezési teljesítmény további romlását okozhatja a Windows 11-es frissítési hibáknál is tárgyalt Delivery Optimization P2P-forgalom, ha a User Configuration része a bejelentkezéskor CSE-n keresztül hálózatot használ.

Tömeges GPO-audit PowerShell-scripttel

Ha 50+ gépet kell auditálnod (pl. új GPO bevezetése után), a következő script minden gépen elindít egy távoli gpresult-ot, majd egy közös fájlszerverre menti a HTML-jelentéseket. Használd RSAT-tal ellátott admin-gépről.

# Bulk-gpresult.ps1 - kotegelt GPO audit egy OU-ra
# Futtatas: .\Bulk-gpresult.ps1 -SearchBase "OU=Laptops,DC=domain,DC=local"

param(
    [Parameter(Mandatory=$true)]
    [string]$SearchBase,

    [string]$ReportPath = "\\fileserver\gpo-audit"
)

# RSAT AD es GroupPolicy modulok kellenek
Import-Module ActiveDirectory
Import-Module GroupPolicy

# Kimeneti mappa letrehozasa datummal
$today = Get-Date -Format "yyyy-MM-dd"
$outDir = Join-Path $ReportPath $today
New-Item -ItemType Directory -Path $outDir -Force | Out-Null

# Osszes gep az OU-bol
$computers = Get-ADComputer -Filter * -SearchBase $SearchBase -Properties LastLogonDate

Write-Host "Auditalunk $($computers.Count) gepet..." -ForegroundColor Cyan

foreach ($c in $computers) {
    # 30 napnal regebben nem loginolt gepeket kihagyjuk - offline vagy nyugdijazott
    if ($c.LastLogonDate -lt (Get-Date).AddDays(-30)) {
        Write-Host "Kihagy: $($c.Name) (utolso login: $($c.LastLogonDate))" -ForegroundColor Yellow
        continue
    }

    # Ping test - halott gepeket ne probaljuk
    if (-not (Test-Connection -ComputerName $c.Name -Count 1 -Quiet)) {
        Write-Host "Nem elerheto: $($c.Name)" -ForegroundColor Red
        continue
    }

    $outFile = Join-Path $outDir "$($c.Name).html"
    try {
        Get-GPResultantSetOfPolicy `
            -Computer $c.Name `
            -ReportType Html `
            -Path $outFile `
            -ErrorAction Stop
        Write-Host "OK: $($c.Name)" -ForegroundColor Green
    }
    catch {
        Write-Warning "Hiba $($c.Name) - $($_.Exception.Message)"
    }
}

Write-Host "Kesz. Jelentesek: $outDir" -ForegroundColor Cyan

A scriptet érdemes ütemezett feladatban futtatni (Task Scheduler → futtatás SYSTEM-ként vagy egy dedikált „gpo-audit” szolgáltatásfiókkal, ami Enterprise Admin nem, de Domain User + a célgépeken helyi admin). A kimeneti HTML-ekből grep-pel gyorsan lehet keresni: Select-String -Path "\\fileserver\gpo-audit\2026-07-02\*.html" -Pattern "Access Denied", így egy pillanat alatt kiderül, hány gépen bukott el a Security Filtering. További Group Policy Analyzer eszközöket a Microsoft Policy Analyzer GitHub repóban találsz, amit GPO-baseline összehasonlításokra használunk.

Gyakran ismételt kérdések

Mi a különbség a gpupdate és a gpupdate /force között?

A gpupdate csak azokat a GPO-kat alkalmazza újra, amelyek verziószáma megváltozott a gpt.ini-ben; a gpupdate /force viszont minden GPO-t újra letölt és feldolgoz, akkor is, ha nem változott. Debug-hoz mindig a /force verziót használd.

Miért nem alkalmazódik a csoportházirendem egy adott gépre?

2026-ban a leggyakoribb ok, hogy a GPO Security Filtering fülről eltávolították az „Authenticated Users” Read jogát. Emiatt a gép nem tudja olvasni a GPO-t és csendben átugorja. Ellenőrizd a gpresult /h jelentés „Denied GPOs” szekcióját, ott „Access Denied (Security Filtering)” jelenik meg.

Hogyan futtatható RSoP távoli számítógépen?

PowerShell-lel a Get-GPResultantSetOfPolicy -Computer CLIENT01 -ReportType Html -Path C:\Temp\rsop.html parancs javasolt. A régi rsop.msc csak helyi gépen fut és Windows 11 24H2-től deprecated. Fontos, hogy a fiókod local admin legyen a célon, és a Windows Firewall engedje a WMI-t.

Milyen gyakran frissül automatikusan a csoportházirend?

Tagszervereken és klienseken alapértelmezetten 90 percenként, 0–30 perces véletlenszerű offsettel (tehát 90–120 perc között). Tartományvezérlőkön 5 percenként. Bejelentkezéskor és rendszerindításkor mindig lefut egy szinkron feldolgozás.

Miért lassú a bejelentkezés, ha sok GPO van?

A bejelentkezési idő döntően a szinkron CSE-ktől (Client-Side Extension) függ: Software Installation, Folder Redirection, Drive Maps preferenciák. Az Event Viewer GroupPolicy/Operational naplójában az Event ID 5308–5320 mutatja, melyik CSE mennyi ideig fut. Winget-configurationre vagy Intune Win32 app deploymentre való átállással a Software Installation-idő megszüntethető.

Hogyan ellenőrizhető, hogy egy GPO WMI-szűrője illeszkedik-e a gépre?

Nyisd meg a szűrő WQL kifejezését a GPMC-ben, majd futtasd a kliens gépen PowerShell-lel: Get-WmiObject -Query "<a szuro WQL-je>". Ha üres eredményt ad, a szűrő nem illeszkedik és a GPO kimarad. Windows 11 24H2 verzióstring: 10.0.26100.