Group Policy Wordt Niet Toegepast op Windows 11 (2026): Complete Troubleshooting Gids

Bijgewerkt: 9 juli 2026

Als Group Policy niet wordt toegepast op een Windows 11-client, ligt de oorzaak in negen van de tien gevallen bij één van vier dingen: een verkeerd OU-scope, Security Filtering waarbij Authenticated Users is verwijderd, een WMI-filter dat de nieuwe build niet meer herkent, of een tijdsverschil van meer dan vijf minuten met de domain controller. Ik loop als service desk lead in deze gids systematisch door gpupdate, gpresult, Event Viewer en het Group Policy Operational log zodat je GPO-problemen binnen tien minuten oplost. Inclusief de nieuwe Event ID 4117 die Microsoft in de januari 2026 cumulatieve update introduceerde en die het jarenlange gepuzzel met Event ID 4098 vervangt.

• Voer altijd eerst gpupdate /force uit en genereer daarna een HTML-rapport met gpresult /h C:\Temp\GPReport.html /f. Dat rapport toont exact welke GPO's geweigerd zijn en waarom.
• De meest voorkomende oorzaak is Security Filtering. Als je Authenticated Users hebt vervangen door een beveiligingsgroep zonder de computer-accounts Read-rechten te geven, faalt zelfs een user-GPO stil.
• WMI-filters die op Version LIKE "10.0.19%" filteren, sluiten Windows 11-builds (10.0.22xxx, 10.0.26xxx) automatisch uit. Een klassieke migratie-valkuil.
• Sinds de januari 2026 cumulatieve update logt Windows 11 leesbare diagnostiek via Event ID 4117 in plaats van de cryptische Event ID 4098 uit het Group Policy Preferences-tijdperk.
• Voor kiosk-, RDS- of shared-workstation-scenario's is loopback processing onmisbaar. Anders wordt de user-configuratie nooit toegepast, hoeveel je ook rebooten.
• Een Kerberos-tijdsverschil van meer dan vijf minuten breekt authenticatie stil af. NTP-configuratie is altijd de eerste sanity-check, ook bij virtuele machines na een snapshot-revert.

Snelle diagnose in drie commando's

Voordat je dieper gaat graven: negen van de tien GPO-problemen worden zichtbaar met drie commando's, uitgevoerd in een elevated command prompt op de betrokken machine. Dit is de eerste tier-1 checklist die ik iedere nieuwe medewerker leer. Sla deze stap niet over. Ik zie te vaak dat een collega direct met Event Viewer begint, terwijl gpresult het antwoord in dertig seconden geeft.

Draai in volgorde:

# 1. Forceer een verse Group Policy refresh (computer + user).
#    /force overschrijft de agressieve throttling die Windows 11
#    hanteert voor foreground processing.
gpupdate /force

# 2. Toon in tekstvorm welke GPO's zijn toegepast en welke
#    zijn gefilterd, plus de reden per gefilterde GPO.
gpresult /r

# 3. Genereer een uitgebreid HTML-rapport met Component Status,
#    WMI-filter uitkomsten en per-instelling winnaar bij conflicten.
#    /f overschrijft een bestaand rapport zonder te vragen.
gpresult /h C:\Temp\GPReport.html /f
start C:\Temp\GPReport.html

Open het HTML-rapport en klap de secties Applied GPOs en Denied GPOs open. Naast elke geweigerde GPO staat een reden: Denied (Security), Denied (WMI Filter), Not Applied (Empty) of Disabled (GPO). Die reden vertelt je in welke sectie van deze gids je verder moet lezen. De Component Status-tabel onderaan toont per Client-Side Extension de verwerkingstijd. Een CSE met "Failed" en een GUID is direct verdachte nummer één.

Waarom wordt mijn Group Policy niet toegepast?

Zodra je het HTML-rapport hebt, moet je de reden matchen tegen de daadwerkelijke oorzaak. Eerlijk, in mijn zeventien jaar aan de service desk komen deze root causes in deze volgorde langs. Ik heb ze geordend op frequentie, niet op complexiteit:

1. Security Filtering-permissies verkeerd. Authenticated Users verwijderd, computerobjecten missen Read-rechten.
2. OU-scope klopt niet. Het target-account zit in de verkeerde OU of de GPO is niet aan die OU gelinkt.
3. WMI-filter matcht Windows 11 niet. Vaak nog een oude Windows 10-versie-check uit 2020.
4. Block Inheritance actief op de OU. Meestal door een collega neergezet en vergeten.
5. Kerberos time skew > 5 minuten. Vooral bij VM's na snapshot-restore of pas-uitgerolde thin clients.
6. Loopback processing niet ingesteld. User-instellingen op RDS-hosts of kiosken worden genegeerd.
7. Instelling vereist logoff of reboot. Folder Redirection, Software Installation en Drive Maps worden nooit tijdens een foreground refresh geactiveerd.
8. Registry.pol beschadigd. Corruptie in het lokale policy-cachebestand, sinds februari 2026 direct zichtbaar in het system log.
9. DC-replicatie loopt achter. De GPO is aangemaakt op DC01 maar nog niet gerepliceerd naar DC02.
10. Netwerk of DNS haalt de DC niet. Event ID 1129 in het System log is dan het rooksignaal.

Als de gpresult-output je GPO helemaal niet noemt (niet in Applied en niet in Denied), dan zit het probleem in oorzaak 2 of 4: het object is niet in scope, of alle GPO's boven de OU zijn geblokkeerd. Komt de GPO wel voor met een reden? Spring dan direct naar de bijbehorende sectie hieronder.

OU-scope en GPO-links controleren

Een GPO die niet in de gpresult-lijst voorkomt heeft simpelweg geen bereik over dit object. Open Group Policy Management Console (gpmc.msc) en selecteer je GPO. Op het tabblad Scope zie je drie kritieke velden: Links, Security Filtering en WMI Filtering. De Links-lijst toont elke site, domain of OU waaraan de GPO is gekoppeld. Staat de OU van je computer- of user-object niet in die lijst? Dan wordt de GPO nooit geëvalueerd, zelfs niet met gpupdate /force.

Onthoud daarbij drie fundamenten die in de praktijk vaak worden vergeten:

• De Computer Configuration-tak wordt geëvalueerd tegen de OU van het computer-object, niet van de user. Als je een computer-instelling in een user-OU linkt, gebeurt er niets.
• Andersom geldt hetzelfde. User Configuration volgt de OU van het user-object. Verplaats je een gebruiker naar een andere OU, dan bevriest zijn RSoP pas na een logoff/logon-cyclus.
• Domain-links worden geërfd door elke onderliggende OU, tenzij een OU expliciet Block Inheritance heeft.

Verifieer de effectieve OU van een user of computer met PowerShell:

# Vraag de canonicale naam op van een AD-object. Dit toont
# in welke OU het object daadwerkelijk staat, inclusief nested paden.
Get-ADUser -Identity jandevries -Properties CanonicalName |
    Select-Object Name, CanonicalName

Get-ADComputer -Identity WKS-FIN-042 -Properties CanonicalName |
    Select-Object Name, CanonicalName

Als de CanonicalName een OU-pad toont dat je niet verwacht, is de rest van je troubleshooting zinloos totdat je het object verplaatst of de GPO opnieuw linkt. Voor complexe OU-structuren met veel geneste containers is dit veruit de meest onderschatte foutbron. Vergelijk het met hoe je bij een vergrendeld account eerst de bron zoekt: zie onze gids voor het vinden van een vergrendeld AD-account met PowerShell voor eenzelfde diagnostische aanpak.

Security Filtering en Authenticated Users

Sinds Microsoft de MS16-072-patch in 2016 uitrolde, is Security Filtering de meest voorkomende oorzaak van "mijn GPO past zich niet toe". De patch veranderde de manier waarop user-GPO's worden opgehaald: de client haalt ze nu op als het computer-account, niet meer als de user zelf. Elke GPO die je aan een specifieke security group toewijst moet daarom ook Read-rechten geven aan Authenticated Users of het target computer-account. Anders slaat het ophalen stil af en zie je Denied (Security) in gpresult. Ik heb dit precies zo zien misgaan bij een klant in de zorg, waar één "opgeruimde" GPO een compleet dashboard offline haalde.

De standaardsituatie: elke nieuwe GPO heeft Authenticated Users in Security Filtering met zowel Read als Apply Group Policy. Zodra een admin deze groep verwijdert om te vervangen door een custom group, verlies je automatisch de Read-permissie voor de computer-accounts. Er zijn twee fixes:

1. Voorkeur: laat Authenticated Users staan met alléén Read, en gebruik je custom group voor Apply Group Policy. Dit voldoet aan MS16-072 en beperkt tegelijk het bereik.
2. Alternatief: voeg Domain Computers expliciet toe met Read-permissie (niet Apply). Nu kan elke domain-joined machine de GPO ophalen zonder deze toe te passen.

Verifieer dit vanuit PowerShell voordat je gaat klikken in GPMC:

# Toon alle permissies op een GPO in leesbare vorm.
# Handig als je niet zeker weet welke groepen Read en Apply hebben.
Import-Module GroupPolicy

$gpoNaam = "Finance-Workstation-Baseline"
Get-GPPermission -Name $gpoNaam -All |
    Select-Object @{n='Trustee';e={$_.Trustee.Name}},
                  Permission, Inherited |
    Format-Table -AutoSize

Zie je alleen jouw custom group en géén Authenticated Users? Voeg ze terug met Read-rechten en draai gpupdate /force op een testmachine. In negen van de tien gevallen is de GPO daarna direct actief. Een van de meest bevredigende quick fixes in ons vak. Microsoft documenteert dit gedrag uitgebreid in de officiële MS-Learn KB over ontbrekende computer Read-permissies.

WMI-filters die Windows 11 breken

WMI-filters voegen een voorwaardelijke evaluatie toe: voor het toepassen van een GPO draait de client een WQL-query op de lokale WMI-repository. Retourneert die query niets, dan wordt de GPO gewoon overgeslagen. Geheel stil, zonder foutmelding aan de eindgebruiker. Dat maakt WMI-filters ideaal voor targeting op OS-versie of hardware, maar ook berucht bij Windows 11-migraties.

De klassieker die ik in 2026 nog steeds meerdere keren per maand tegenkom:

-- Deze filter matcht Windows 10 (build 10.0.19xxx)
-- maar NIET Windows 11 (10.0.22000 t/m 10.0.26xxx).
SELECT * FROM Win32_OperatingSystem
WHERE Version LIKE "10.0.19%" AND ProductType = "1"

Zodra je een fleet upgradet naar Windows 11 24H2 of 25H2, verdwijnen al je op deze filter afhankelijke GPO's. De correcte filter voor "alle moderne Windows-clientversies" is bewust breed:

-- Match elke Windows 10 en Windows 11 client (ProductType 1 = workstation).
-- Windows Server heeft ProductType 2 (DC) of 3 (member server).
SELECT * FROM Win32_OperatingSystem
WHERE Version LIKE "10.%" AND ProductType = "1"

Test elke WMI-filter direct vanuit PowerShell voordat je hem in productie zet:

# Voer de WQL-query los uit met Get-CimInstance.
# Retourneert de query iets? Dan matcht de filter deze machine.
# Retourneert het niets, dan wordt de GPO stil overgeslagen.
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem
    WHERE Version LIKE '10.%' AND ProductType = '1'"

Een tweede veelvoorkomende fout is architectuur-detectie via %PROCESSOR_ARCHITECTURE%. Dat is een environment variable, geen WMI-property, dus de query faalt altijd. Gebruik in plaats daarvan Win32_Processor:

SELECT * FROM Win32_Processor WHERE AddressWidth = "64"

Merk je dat helemaal geen enkele GPO met een WMI-filter meer toegepast wordt op een specifieke machine? Dan is de kans groot dat de WMI-repository corrupt is. Herbouw hem als laatste redmiddel met winmgmt /verifyrepository, en als dat foutmeldingen geeft, met winmgmt /resetrepository in een offline sessie.

Block Inheritance en Enforced verklaard

Een OU met Block Inheritance aan (herkenbaar aan het blauwe uitroepteken in GPMC) negeert álle GPO's die op hogere niveaus zijn gelinkt, behalve GPO's die expliciet als Enforced zijn gemarkeerd. Dit is doorgaans een bewuste keuze voor bijvoorbeeld een test-OU of een DMZ, maar ik zie het minstens één keer per maand terugkomen als iemand het "even" heeft aangezet om een specifiek probleem te troubleshooten, en het daarna vergeten uit te zetten.

De vuistregels:

• Block Inheritance op een OU stopt overerving vanuit domain en parent-OU's.
• Een GPO die op domain-niveau of parent-OU als Enforced (voorheen "No Override") is gemarkeerd, wint altijd. Ook bij Block Inheritance.
• Enforced GPO's krijgen ook voorrang op conflicterende instellingen in child-OU's, waardoor ze vaak worden gebruikt voor niet-onderhandelbare security baselines zoals BitLocker-vereisten.

Als je een security-baseline uitrolt (bijvoorbeeld voor BitLocker-encryptie en herstelsleutels op Windows 11), overweeg dan altijd Enforced te gebruiken. Zo voorkom je dat een lokale admin met Block Inheritance een kritieke policy sloopt. Documenteer beide vlaggen in je change management. Een niet-gedocumenteerde Enforced-GPO is een tijdbom bij delegatie van OU-beheer aan een businessunit.

Kerberos-tijdsverschil en NTP

Windows vereist dat de client authenticeert vóórdat Group Policy überhaupt wordt opgehaald. Die authenticatie loopt via Kerberos, en Kerberos accepteert maximaal vijf minuten tijdsverschil tussen client en domain controller. Wijkt het meer af, dan krijg je in Event Viewer een fout KRB_AP_ERR_SKEW en faalt Group Policy zonder duidelijke oorzaak. De user ziet alleen "kan geen verbinding maken met een domain controller". Ik liep hier zelf tegenaan bij een provider die 's nachts VM-snapshots terugrolde: elke ochtend zaten twee servers een uur in het verleden.

Ik zie deze fout vooral op drie plekken:

1. Virtuele machines na een snapshot-revert. De VM springt terug in de tijd en tikt verder vanaf toen, soms uren of dagen achter. Windows Time-service haalt dit niet altijd automatisch in, zeker niet als de host-integratie uit staat.
2. Vers-uitgerolde thin clients en IoT-devices. De CMOS-batterij is leeg of niet aanwezig; de clock start op fabrieksdefault en heeft een NTP-sync nodig vóór join.
3. Machines in een andere tijdzone met een misconfigured BIOS clock. Windows verwacht UTC in de RTC; sommige systemen (dual-boot met Linux) schrijven lokale tijd, met een drift van meerdere uren als resultaat.

Verifieer en repareer met w32tm in een elevated prompt:

# Toon de huidige NTP-bron en offset ten opzichte van de peer.
w32tm /query /status
w32tm /query /source

# Forceer een resync met een externe of interne NTP-server.
# Op domain-joined machines is de PDC Emulator de juiste bron.
w32tm /resync /force

# Op de PDC Emulator zelf: peer aan een externe NTP-pool.
w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time

Draai daarna gpupdate /force opnieuw. Als de client meteen weer aan Group Policy trekt en de RSoP zich vult, was tijd inderdaad de dader. Voor achtergrond over hoe Kerberos-tijd werkt, is de Windows Time-service documentatie op MS-Learn het startpunt.

Loopback processing voor user-config

Loopback processing is de instelling die veel service desk-medewerkers verwart: het staat onder Computer Configuration maar bepaalt hoe User Configuration wordt toegepast. Als je in een RDS-omgeving, kioskopstelling of gedeelde-workstation-scenario user-instellingen wilt afdwingen op basis van waar de machine staat (en niet waar de user staat), heb je loopback nodig. Zonder loopback wint de user-OU altijd, wat je ook op de computer-OU configureert.

Het pad in GPMC: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user group policy loopback processing mode. Je hebt twee modi:

• Merge: user-GPO's uit de user-OU worden eerst toegepast, daarna wint de computer-OU's user-configuratie bij conflicten. Gebruik dit voor gedeelde laptops waar je bepaalde restricties per locatie wilt opleggen zonder de reguliere user-profielen te vernietigen.
• Replace: user-GPO's uit de user-OU worden volledig genegeerd; alleen de computer-OU's user-configuratie telt. Dit is de juiste keuze voor kiosk- en single-purpose-machines.

Test loopback voorzichtig. Op een normale kantoormachine kan Replace-mode je Outlook-signature, Office-taal en OneDrive-configuratie in één klap wegvagen. Ik rol loopback altijd eerst uit naar een testcomputer met een testgebruiker, log twee keer in en uit, en vergelijk gpresult /r-output vóór en na. Als loopback actief is, zie je "The following GPOs were applied to the user" gevuld met GPO's uit de computer-OU. Dat is het bewijs dat de mode werkt.

Event Viewer, Event ID 4117 en gpsvc.log

Als gpresult geen duidelijke oorzaak aanwijst, is Event Viewer je volgende halte. Twee logs zijn relevant: Windows Logs → System voor GPO-processing errors, en Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational voor gedetailleerde per-GPO tracing. Elke gpupdate /force-run krijgt een unieke ActivityID. Filter het log op die ID om de stappen van precies die run te isoleren.

De belangrijkste Event ID's die je moet kennen:

• 1129: Group Policy kan geen domain controller bereiken. Netwerk of DNS. Vaak LDAP-poort 389 geblokkeerd door een firewall of VPN split-tunnel.
• 1058 / 1030: de GPT-bestanden in SYSVOL kunnen niet worden gelezen. Vaak permissies op de SYSVOL-share of DFS-replicatiefouten.
• 4098: legacy Group Policy Preferences fout. Kan van alles betekenen. Dit is de fout waarom we jarenlang gpsvc-debug logging moesten aanzetten.
• 4117: nieuw sinds januari 2026. Vervangt 4098 met concrete details: welk bestandspad faalde, welke UNC niet resolveerde, welke remediatiestap wordt aanbevolen. Als je Windows 11 nog niet naar de januari-cumulative hebt gepatcht, is dit alleen al reden om dat vandaag te doen.
• 7016 / 5719: Netlogon-fouten die duiden op een gebroken vertrouwensrelatie. Dat is een separaat probleem, maar sluit vaak group policy failure in.

Voor de hardnekkige gevallen zet je debug logging aan op de Group Policy Service zelf. Sinds de februari 2026 patch tuesday hoef je géén ADMX-bestanden meer handmatig te kopiëren; het is nu een preview-toggle direct in gpedit.msc. Voor oudere builds gebruik je nog steeds de registry-methode:

# Zet gpsvc verbose debug logging aan (max 10MB rolling log).
# Vergeet niet dit weer uit te zetten na de troubleshoot, want het log wordt groot.
$path = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics"
New-Item -Path $path -Force | Out-Null
Set-ItemProperty -Path $path -Name "GPSvcDebugLevel" -Value 0x30002 -Type DWord

# Maak de logmap aan; zonder deze map wordt gpsvc.log niet geschreven.
New-Item -Path "C:\Windows\debug\usermode" -ItemType Directory -Force | Out-Null

# Draai gpupdate en lees het log met een specifieke ActivityID filter.
gpupdate /force
Get-Content C:\Windows\debug\usermode\gpsvc.log -Tail 200

Voor de volledige lijst met Event ID's en hun oorzaken, raadpleeg de officiële Microsoft-Learn troubleshooting guide voor Applying Group Policy.

PowerShell voor bulk-diagnose over een fleet

Een enkele client troubleshooten is één ding. Een systemisch probleem over honderd workstations opsporen is iets heel anders. Sinds Windows 10 hebben we Invoke-Command en de GroupPolicy-module, en die combinatie laat je vanaf één beheerwerkstation RSoP-data over een hele OU verzamelen. Dit is mijn go-to script wanneer een specifieke GPO "op sommige machines" niet werkt.

# Verzamel de laatste GPO-toepassings-timestamp en gefilterde
# GPO's van elke computer in een specifieke OU. Draait parallel
# met -ThrottleLimit voor snelheid; pas aan naar je infra.
$computers = Get-ADComputer -SearchBase "OU=Workstations,DC=corp,DC=nl" `
    -Filter "Enabled -eq \$true" |
    Select-Object -ExpandProperty Name

$results = Invoke-Command -ComputerName $computers -ThrottleLimit 20 -ScriptBlock {
    # gpresult /r in scriptbare vorm; parse de tekstoutput voor
    # "Last time Group Policy was applied" en "Denied GPOs".
    $raw = gpresult /r /scope:computer 2>&1
    [PSCustomObject]@{
        Computer   = $env:COMPUTERNAME
        LastApply  = ($raw | Select-String "Last time Group Policy was applied").Line.Trim()
        DeniedGPOs = ($raw | Select-String "Denied|Filtered" | Measure-Object).Count
    }
} -ErrorAction SilentlyContinue

$results | Where-Object DeniedGPOs -gt 0 |
    Sort-Object DeniedGPOs -Descending |
    Format-Table -AutoSize

Draai dit periodiek in je monitoring-pipeline en je vangt afwijkingen (bijvoorbeeld één machine die plots dubbel zoveel Denied GPOs heeft) veel eerder dan wanneer een gebruiker een ticket opent. Combineer de output met je ticketing-tool en je hebt proactieve remediatie in plaats van reactieve firefighting. Voor een compacter alternatief kun je ook Get-GPResultantSetOfPolicy gebruiken, al is die trager omdat het XML-output genereert per host.

Veelgestelde vragen

Hoe forceer ik een Group Policy update op Windows 11?

Open een elevated command prompt en draai gpupdate /force. Dit vernieuwt zowel Computer als User Configuration onmiddellijk in plaats van te wachten op het standaard 90-minuten refresh-interval. Voor instellingen zoals Folder Redirection, Software Installation of Drive Maps is een logoff (user) of reboot (computer) daarna nog steeds nodig; die worden niet tijdens een foreground refresh geactiveerd.

Waarom toont gpresult /r "The user does not have RSOP data"?

Meestal draai je gpresult in een elevated context van een andere admin dan de ingelogde gebruiker. Voeg /user DOMEIN\gebruiker toe om expliciet de eindgebruiker op te vragen. Als het probleem blijft, is Group Policy nog niet succesvol verwerkt: controleer netwerkverbinding en draai eerst gpupdate /force.

Werkt gpedit.msc op Windows 11 Home?

Nee, de Local Group Policy Editor is standaard niet beschikbaar in Windows 11 Home. Voor echte GPO-functionaliteit moet je upgraden naar Pro (ongeveer USD 99 via de Microsoft Store) of een derde-partij tool zoals PolicyPlus gebruiken. Ongepatchte scripts die gpedit.msc-bestanden kopiëren zijn onveilig en breken bij elke feature-update.

Wat is het verschil tussen Enforced en Block Inheritance?

Block Inheritance is een instelling op een OU die alle overgeërfde GPO's van hogere niveaus negeert. Enforced is een instelling op een individuele GPO-link waardoor die GPO altijd wint, ook bij Block Inheritance en bij conflicterende instellingen in child-OU's. Gebruik Enforced voor niet-onderhandelbare security baselines zoals BitLocker-vereisten.

Wat betekent Event ID 4117 in het Group Policy log?

Event ID 4117 is de vervanger van het oude Event ID 4098 en werd geïntroduceerd in de januari 2026 cumulatieve update voor Windows 11. In plaats van een cryptische foutcode toont 4117 direct het gefaalde bestandspad, de betrokken UNC-locatie en een aanbevolen remediatiestap. Zie je nog Event ID 4098? Dan heb je de patch nog niet geïnstalleerd; patchen is de eerste actie.