Group Policy anvendes ikke på Windows 11: helpdesk-guide til fejlfinding 2026

Opdateret: 14. september 2026

Når Group Policy ikke anvendes på Windows 11, skyldes det næsten altid én af tre ting: SYSVOL replikerer ikke korrekt, filtreringen (sikkerhed eller WMI) er forkert, eller klienten når aldrig frem til en domænecontroller på det tidspunkt, hvor baggrundsopdateringen kører. Så lad os gå direkte til de kommandoer, jeg selv kører hver dag på servicedesken: gpupdate, gpresult, PowerShell og Event Viewer. Med den rækkefølge finder du årsagen på under ti minutter i stedet for at gætte dig frem.

• Kør altid gpupdate /force /wait:0 efterfulgt af gpresult /h C:\Temp\rsop.html, før du eskalerer en sag. Det giver svaret i 80 % af tilfældene.
• Sikkerhedsfiltrering kræver både Read og Apply Group Policy på GPO'en. Mangler den ene, gælder politikken ikke, uden nogen fejl i loggen.
• Windows 11 24H2 og 25H2 kræver opdaterede ADMX-skabeloner i central store. Gamle skabeloner får indstillinger til at forsvinde stille fra GPMC.
• Slow-link registrering aktiveres over VPN og deaktiverer som standard flere klient-side extensions som scripts og softwareinstallation.
• SYSVOL-replikeringsproblemer via DFSR er den mest oversete årsag på site-to-site domæner. Tjek altid Event ID 4012 og 5014 på hver DC.
• Loopback-behandling i tilstandene Merge og Replace giver vidt forskellige resultater. Brug altid gpresult til at bekræfte, at brugerdelen faktisk løses fra maskinens OU.

Hvorfor anvendes Group Policy ikke på mine Windows 11-klienter?

Group Policy anvendes ikke, når klienten enten (a) ikke kan lokalisere en domænecontroller på det tidspunkt, opdateringen kører, (b) mangler læserettigheder på GPO'en, (c) filtreres fra via WMI eller Item-Level Targeting, eller (d) rammes af replikeringsfejl i SYSVOL. Med Windows 11 24H2 er der desuden kommet et nyt lag: Group Policy Service starter nu forsinket på pc'er, som er tilmeldt Microsoft Entra ID og Intune samtidig med lokalt AD. De første to reboots efter en hybrid-tilmelding kan derfor resultere i, at brugerdelen af GPO'en ikke evalueres, fordi Kerberos-billetten endnu ikke er tilgængelig.

Min faste regel på servicedesken: begynd aldrig med at åbne GPMC på domænecontrolleren. Start altid på selve klienten. Det, brugeren oplever, er sandheden; det, GPMC viser, er blot administratorens hensigt. Kør gpresult /r som brugeren, sammenlign OU-placering med linkning i GPMC, og du har typisk pillet halvdelen af mysteriet fra allerede.

Sådan tvinger du en Group Policy-opdatering med gpupdate

Windows kører som standard baggrundsopdatering af Group Policy hver 90 minutter plus et tilfældigt offset på 0–30 minutter. Det er sjældent hurtigt nok, når man fejlfinder. Åbn en elevated PowerShell-session (Run as Administrator) og kør følgende. Kommandoerne er kommenteret, så tier-1 kan bruge dem uden risiko:

# Tving både computer- og brugerpolitikker til at re-evalueres nu.
# /force = re-appliker alle indstillinger, ikke kun ændringer.
# /wait:0 = giv kontrollen tilbage med det samme (ellers hænger konsollen op til 600 sekunder).
gpupdate /force /wait:0

# Nogle klient-side extensions (fx scripts og softwareinstallation)
# kræver logout/reboot for at træde i kraft. Tving en genstart, hvis politikken kræver det:
gpupdate /force /target:computer /boot
gpupdate /force /target:user /logoff

Hvis gpupdate returnerer "The processing of Group Policy failed", skal du straks slå fejlkoden op i Event Viewer under Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Event ID 1058 og 1030 peger på SYSVOL-tilgang; 7017 og 7016 peger på klient-side extensions; 4098 peger på Group Policy Preferences (typisk drev-mapninger). Alle koder er dokumenteret i Microsofts officielle Group Policy event reference, som jeg holder åbnet i en fane hele arbejdsdagen.

Analyser resultatet med gpresult og RSoP

Når gpupdate er kørt, er næste skridt at bekræfte, hvad der faktisk blev anvendt. gpresult er dit primære værktøj, og det leverer betydeligt mere information i HTML-rapporten end i konsoludskriften. Kør begge:

# Kort konsol-oversigt: hvilke GPO'er blev anvendt, hvilke blev filtreret fra?
gpresult /r /scope:computer
gpresult /r /scope:user

# Fuld HTML-rapport (dette er den, jeg altid vedhæfter til tickets)
gpresult /h C:\Temp\rsop-%COMPUTERNAME%.html /f

# Ren XML-udgave, hvis du skal parse programatisk med PowerShell
gpresult /x C:\Temp\rsop.xml /f

Åbn HTML-rapporten og gå direkte til sektionen "Denied GPOs". Det er dér, du finder de politikker, der skulle have været anvendt, men blev filtreret fra. Årsagen står i kolonnen "Reason Denied": "Access Denied (Security Filtering)" betyder en manglende ACL på GPO'en, mens "Filtering: Not Applied (Empty)" ofte skyldes, at politikken kun har brugerindstillinger, men er linket til en computer-OU (eller omvendt). RSoP kan også køres remote fra en administratorstation med Invoke-Command, hvilket er guld værd, når du fejlfinder for en bruger på hjemmekontoret.

Har du et Active Directory-miljø med hyppige kontolåsninger på samme brugere, som også oplever GPO-problemer, så er der ofte en fælles årsag. Se min tidligere gennemgang af Active Directory-kontolåsninger og hvordan du finder kilden for de samme Kerberos- og replikeringstrin.

Sikkerhedsfiltrering og WMI-filtre: de klassiske faldgruber

Den mest almindelige årsag til at en GPO "forsvinder" fra en bestemt bruger eller maskine er sikkerhedsfiltrering. En GPO anvendes kun, hvis det sikkerhedsprincipal (bruger, gruppe eller computer), der evaluerer politikken, har både tilladelsen Read og Apply Group Policy. Fjerner du "Authenticated Users" fra ACL'en for at begrænse scope til en enkelt gruppe, glemmer folk ofte, at Windows 11-klienter nu evaluerer maskin-GPO'er som computerobjektet (ikke som brugeren), og hvis computerobjektet ikke er medlem af den nye gruppe, gælder politikken ikke.

Ærligt talt er det her et af de scenarier, jeg selv har brændt mig på: en kollega fjernede "Authenticated Users" fra en enkelt drev-mapning-GPO, og pludselig manglede halvdelen af salgsafdelingen deres hjemmedrev om mandagen. Efter MS16-072 (KB3163622) kræver alle GPO'er desuden mindst "Authenticated Users: Read" for at kunne læses fra klienten. Fjerner du den, får du en tavs failure. Politikken forsvinder bare uden fejl. Løsningen er at tilføje "Domain Computers: Read" eller genindsætte "Authenticated Users: Read" (uden Apply). WMI-filtre er den anden klassiker. Et filter som SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.22%" ekskluderer al Windows 11, fordi build-numrene starter med 22000+, men OS-versionen blev flyttet til 10.0.26100 med 24H2. Test altid WMI-filtre lokalt med Get-CimInstance -Query, før du deployer.

Slow-link registrering og VPN-problemer

Windows 11 anvender Network Location Awareness til at måle bandwidth mellem klienten og domænecontrolleren. Falder båndbredden under 500 kbps eller stiger latency over 1500 ms (hvilket sker konstant på Always On VPN-forbindelser med split-tunnel og mobile brugere), markeres forbindelsen som "slow link". Standardadfærden er, at følgende klient-side extensions ikke kører over slow link: Software Installation, Scripts (login/startup), Folder Redirection, Disk Quota og Internet Explorer Maintenance. Registry Policy og Security Policy kører fortsat.

Det er den enkeltstående mest almindelige årsag til, at brugere hjemmefra klager over, at mappede drev "nogle gange" ikke er der. Hvis du kører moderne VPN som Always On, kan du enten (a) forhøje slow-link tærsklen via Computer Configuration → Administrative Templates → System → Group Policy → Configure Group Policy slow link detection, (b) tvinge synkron behandling ved logon via Always wait for the network at computer startup and logon, eller (c) genoverveje, om drev-mapninger overhovedet skal ligge i GPO'er i 2026. Group Policy Preferences med Item-Level Targeting og "Apply once and do not reapply" er langt mere pålidelig. Du kan finde alle detaljerne omkring VPN-lag i min guide til VPN-fejlfinding i Windows 11 for helpdesk.

SYSVOL, DFSR og manglende ADMX-skabeloner

GPO-indstillinger opbevares to steder: Group Policy Container (GPC) i Active Directory og Group Policy Template (GPT) i mappen \\domain\SYSVOL\domain\Policies\{GUID}. GPC replikeres via AD-replikering, mens GPT replikeres via DFSR. Kommer de to ud af sync, ser du typisk symptomet: en indstilling er sat i GPMC, men gælder aldrig for klienter. Kør denne PowerShell på hver DC for at diagnostisere:

# Tjek DFSR-backlog for SYSVOL-replication group.
# En sund backlog er 0 filer på tværs af alle par.
$dfsr = Get-DfsrBacklog -GroupName "Domain System Volume" `
    -FolderName "SYSVOL Share" `
    -SourceComputerName DC01 `
    -DestinationComputerName DC02 -Verbose

# Tjek Event Log for DFSR errors (Event ID 4012 = journal wrap, 5014 = folder unavailable)
Get-WinEvent -LogName "DFS Replication" -MaxEvents 50 |
    Where-Object { $_.LevelDisplayName -in "Error","Warning" } |
    Select-Object TimeCreated, Id, Message | Format-List

Den anden SYSVOL-relaterede årsag er manglende eller forældede ADMX-skabeloner. Windows 11 24H2 introducerede ~60 nye policy-indstillinger og fjernede legacy Internet Explorer-templates. Kører du fortsat 22H2-templates i din Central Store (\\domain\SYSVOL\domain\Policies\PolicyDefinitions), ser du enten tomme indstillinger i GPMC, eller endnu værre: indstillinger, du kan konfigurere, men som klienten ikke forstår. Download den nyeste bundle fra Microsoft, kopier *.admx til PolicyDefinitions og *.adml til den relevante sprog-undermappe (fx da-DK).

Loopback-behandling for brugerpolitikker

Loopback-behandling er den funktion, folk enten elsker eller hader. Den bruges typisk til at anvende brugerindstillinger baseret på hvilken maskine brugeren logger på. Perfekt til kioskcomputere, mødelokale-pc'er eller shared workstations i Windows 11. Du finder indstillingen under Computer Configuration → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode.

Fælden ligger i valget mellem Merge og Replace. I Replace ignoreres brugerens egne OU-baserede GPO'er totalt; kun brugerindstillingerne fra computerens OU anvendes. I Merge anvendes brugerens egne først, derefter computerens (som vinder ved konflikt). Debug er ubarmhjertigt, hvis du ikke ved, hvilken du har valgt, så jeg bruger denne standard-diagnostik:

# Kør som den ramte bruger; kig efter "Loopback processing" i output.
gpresult /scope:user /v | Select-String -Pattern "loopback","GPO"

# På maskinen: bekræft hvilke user-side GPO'er der er registreret via loopback
Get-GPResultantSetOfPolicy -ReportType Xml -Path C:\Temp\rsop.xml
[xml]$rsop = Get-Content C:\Temp\rsop.xml
$rsop.Rsop.UserResults.Gpo | Select-Object Name, Enabled, AccessDenied

Bemærk desuden, at hvis loopback står i Merge, men det bagvedliggende computer-OU ikke har nogen linkede bruger-GPO'er, bliver nettoeffekten stille og roligt lig med "brugerens egne GPO'er", hvilket er præcis modsat, hvad de fleste forventer. Design altid en dedikeret OU til loopback-maskiner, og læg brugerindstillingerne der.

PowerShell-værktøjskasse til systematisk fejlfinding

Her er det diagnostik-script, jeg lader tier-1 køre, når en bruger melder, at "Group Policy virker ikke". Det samler alt relevant på ét sted, så tier-2 kan overtage uden yderligere spørgsmål:

# Save som Invoke-GPDiag.ps1 og kør fra en elevated PowerShell prompt på klienten
# Output: en ZIP-fil på C:\Temp klar til vedhæftning i ticket-systemet.

$out = "C:\Temp\GPDiag-$env:COMPUTERNAME-$(Get-Date -f 'yyyyMMdd-HHmm')"
New-Item -Path $out -ItemType Directory -Force | Out-Null

# 1. Hvilken DC er klienten koblet til?
nltest /dsgetdc:$env:USERDNSDOMAIN > "$out\dc.txt"

# 2. RSoP: både konsol og HTML
gpresult /r > "$out\gpresult-r.txt"
gpresult /h "$out\rsop.html" /f

# 3. Event log for Group Policy (sidste 24 timer)
$since = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-GroupPolicy/Operational'; StartTime=$since
} | Export-Csv "$out\gp-events.csv" -NoTypeInformation

# 4. Kerberos-billetter (relevant ved MS16-072 issues)
klist > "$out\klist.txt"

# 5. Netværkslag: kan vi nå DC'en over de rette porte?
$ports = 88,135,389,445,464,636
$dc = (Get-ADDomainController -Discover).HostName[0]
$ports | ForEach-Object {
    $ok = Test-NetConnection -ComputerName $dc -Port $_ -InformationLevel Quiet
    "$dc`:$_ = $ok"
} | Set-Content "$out\ports.txt"

# 6. Zip og drop i tickettray
Compress-Archive -Path $out -DestinationPath "$out.zip" -Force
Write-Host "Diagnostik gemt til $out.zip" -ForegroundColor Green

Scriptet er bevidst simpelt; det er tænkt til at blive læst, forstået og udvidet. På vores servicedesk supplerer vi det med en fast tjekliste i ticketen: hvilken DC blev ramt, hvilke GPO'er er 'Denied', hvornår kørte sidste succesfulde background refresh, og er brugeren via VPN?. Fire spørgsmål, halvdelen af de sager jeg tidligere brugte en time på lukkes nu på 15 minutter.

Læs Event Viewer korrekt til Group Policy-fejlfinding

Windows 11 skriver Group Policy-events til to logs: System (den gamle Userenv-arv) og Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Sidstnævnte er den, du skal have åben. Hver GPO-processing skriver et startvent (Event ID 4001, computer; 4002, bruger) og et slutvent (8001–8007 afhængigt af succes/fejl). Mellem disse to events finder du alle CSE'er (Registry Policy: 5017, Security: 5312, Group Policy Preferences: 4098). Kryds tidsstemplet på et 8007 (failure) med et 5017 lige før, og du har den præcise CSE, der brød sammen.

Vores tier-2 har en fast Custom View gemt med filteret *[System[Provider[@Name='Microsoft-Windows-GroupPolicy'] and (Level=1 or Level=2 or Level=3)]]. Det viser kun Critical, Error og Warning på tværs af alle GPO-events, og det er som regel nok til at pege på den skyldige CSE inden for 30 sekunder. Kombiner med den generelle Windows 11 fejlfinding-guide, hvis du har brug for at udelukke bredere OS-problemer først.

Ofte stillede spørgsmål

Hvorfor virker gpupdate /force ikke længere på Windows 11?

På Windows 11 24H2 og nyere starter Group Policy-tjenesten forsinket ved hybrid Entra-tilmelding. Bekræft med Get-Service gpsvc, at tjenesten kører, og tjek Event ID 7000 i System-loggen. Er tjenesten stoppet af en third-party endpoint protection, virker gpupdate ikke, uanset hvor mange gange du kører den.

Hvordan tjekker jeg, om en GPO faktisk er anvendt?

Kør gpresult /h C:\Temp\rsop.html som den ramte bruger og åbn rapporten. Sektionen "Applied GPOs" viser præcis, hvad der er anvendt, og "Denied GPOs" viser, hvad der blev filtreret fra, og hvorfor. Konsoludskriften fra gpresult /r giver kun overskrifter.

Hvad betyder "Access Denied (Security Filtering)" i gpresult?

Det betyder, at brugerens eller computerens sikkerhedstoken mangler tilladelsen Apply Group Policy på den pågældende GPO. Åbn GPO'en i GPMC, gå til fanen "Delegation" → "Advanced" og bekræft, at både Read og Apply Group Policy er sat til Allow for det korrekte principal.

Hvor lang tid tager Group Policy om at træde i kraft?

Windows 11 kører baggrundsopdatering hver 90 minutter plus et tilfældigt offset på 0–30 minutter, så op til 120 minutter i praksis. Software Installation, Scripts og Folder Redirection kræver dog logout/reboot for at træde i kraft, uanset baggrundsopdateringen.

Kan jeg køre Group Policy på Entra-only enheder uden lokalt AD?

Nej, ikke traditionel Group Policy. På Entra-only Windows 11-enheder anvender du Settings Catalog og Configuration Profiles i Microsoft Intune, som mapper mange (men ikke alle) klassiske GPO-indstillinger til CSP-ækvivalenter. Der findes en officiel Group Policy Analytics-rapport i Intune, som du kan bruge til at planlægge migrationen.