Group Policy tillämpas inte: komplett felsökningsguide för IT-helpdesk 2026

Uppdaterad: 17 juni 2026

Den vanligaste anledningen till att en Group Policy (GPO) inte tillämpas är att klienten aldrig faktiskt får in den. Antingen exkluderar säkerhetsfiltreringen användaren eller datorn, ett WMI-filter returnerar False, eller så har SYSVOL inte replikerat den senaste versionen. Den här guiden visar hur du på under tio minuter avgör var i kedjan det stannar, hur du läser gpresult /h som en proffsadmin, och hur du fixar problemet med PowerShell-kommandon som tier-1 kan kopiera rakt in i en terminal. Allt är verifierat mot Windows 11 24H2 och Windows Server 2025.

• Börja alltid med gpresult /h C:\Temp\gp.html. HTML-rapporten visar exakt vilka GPO:er som tillämpades, vilka som filtrerades bort och varför.
• De fyra vanligaste orsakerna till att en GPO inte slår igenom är: felaktig länkning, säkerhetsfiltrering som saknar Authenticated Users Read, ett WMI-filter som inte matchar, eller Block Inheritance på en OU.
• gpupdate /force applicerar alla policyer på nytt, men det kräver fortfarande att klienten kan nå en domänkontrollant och att SYSVOL-replikeringen är frisk.
• Loopback processing (Replace eller Merge) är rätt verktyg när användarinställningar ska tillämpas baserat på datorn, till exempel kioskburkar och RDS-värdar.
• Group Policy Operational-loggen i Event Viewer (Microsoft-Windows-GroupPolicy/Operational) ger event-ID:n som pekar direkt på rotorsaken. Events 5311, 6017 och 7017 är dina vänner.
• SYSVOL-replikering via DFSR är ofta den tysta boven. Kör dfsrdiag pollad och dfsrdiag backlog mot DC:erna när inget verkar uppdateras.

Snabb diagnos: är det GPO:n eller klienten?

Innan jag öppnar Group Policy Management Console (GPMC) gör jag alltid en trestegs-diagnos på klienten. Det sparar mig en halvtimme av onödigt klickande i konsolen, och det visar nästan alltid om problemet ligger på klientsidan (en otrevlig lokal policy, trasigt nätverk till DC:n, eller ett utgånget maskinpassword) eller på katalogsidan (felaktig länkning, fel filter, eller en GPO som aldrig replikerats färdigt).

Ärligt talat, det första jag gör är att verifiera att klienten kan nå en domänkontrollant och att den hämtar policy från en sajt som motsvarar dess IP. Kör nltest /dsgetdc:contoso.local och titta på vilken DC som returneras. Är det en DC i fel sajt så får klienten kanske policyer från en GPO som ligger efter i replikeringen. Sedan kör jag w32tm /query /status för att kontrollera klockskillnaden mot DC:n. Kerberos accepterar fem minuters skew som standard, och en klient med tidsdrift får felaktiga biljetter, vilket i sin tur stoppar grupprincip-bearbetningen helt.

Det andra steget är att kolla om Group Policy Client-tjänsten (gpsvc) ens kör. Den får man inte stoppa eller starta om manuellt. Microsoft har medvetet låst service-kontrollerna efter ett par incidenter där admins råkade döda den och fick svartskärm (jag har själv suttit med en sådan burk klockan tre på morgonen, det är inte kul). Verifiera istället med Get-Service gpsvc i en upphöjd PowerShell. Om den står som Stopped är det nästan alltid en korrupt användarprofil eller ett trasigt SID-cache som ligger bakom. Ominstallera profilen innan du går vidare.

Tredje steget: kontrollera om datorns maskinkonto fortfarande är friskt mot domänen med Test-ComputerSecureChannel -Verbose. Returnerar den False har du hittat problemet. Datorn har tappat sin förtroenderelation och måste återställas med Reset-ComputerMachinePassword eller en domän-omanslutning. Vår felsökningsguide för Active Directory går djupare in på just detta scenario.

Så använder du gpresult för att se vilka GPO:er som tillämpas

Så, gpresult är fortfarande det viktigaste verktyget för att svara på frågan "vilka GPO:er kör faktiskt på den här klienten just nu?". De flesta tier-1-tekniker jag möter använder bara gpresult /r, men det är som att felsöka ett nätverk med ping. Det fungerar i nödfall, men HTML-rapporten är mil bättre. Kör alltid:

# Generera en fullständig HTML-rapport för dator + inloggad användare
# Spara på en delad mapp så supporten kan öppna den utan att RDP:a in
gpresult /h C:\Temp\gp-$env:COMPUTERNAME.html /f

# Vill du köra mot en annan dator i fältet?
gpresult /s WS-DESKTOP-042 /h \\fileserver\support$\gp-WS-DESKTOP-042.html /f

# Mot en specifik användare på en specifik dator
gpresult /s WS-DESKTOP-042 /user CONTOSO\anna.svensson /h ... /f

HTML-rapporten har tre sektioner du faktiskt bryr dig om. Längst upp ser du Applied GPOs, alltså listan över policyer som verkligen tillämpades. Längre ner ser du Denied GPOs tillsammans med en kolumn Reason Denied: "Empty", "Disabled Link", "Access Denied (Security Filtering)" eller "Not Applied (WMI Filter)". 90 procent av alla "GPO tillämpas inte"-ärenden löses i den här tabellen. Bläddra inte förbi den.

Behöver du en programmatisk variant (till exempel för en automatisk diagnostikkörning över tusen klienter), använd RSoP-WMI-providern via PowerShell:

# Lista alla GPO:er som tillämpas på den lokala datorn, sorterat efter ordning
Get-CimInstance -Namespace root\rsop\computer -ClassName RSOP_GPO |
    Sort-Object -Property name |
    Select-Object name, version, filterAllowed, accessDenied

# Hitta alla policyer som avvisades på grund av säkerhetsfiltrering
Get-CimInstance -Namespace root\rsop\computer -ClassName RSOP_GPO |
    Where-Object { $_.accessDenied -eq $true } |
    Format-Table name, accessDenied -AutoSize

Den här syntaxen är dokumenterad i Microsofts WMI-policy-referens och fungerar identiskt på Windows 10, 11 och Server 2019/2022/2025. Spara skriptet som ett verktyg i ert ticketing-system, så slipper tier-1 lära sig kommandona utantill.

Varför tillämpas inte min GPO? De vanligaste orsakerna

Efter femton år av Group Policy-incidenter har jag landat på samma fem rotorsaker, om och om igen. Här är listan i ungefär den ordning du bör kontrollera dem.

1. GPO:n är länkad fel, eller inte alls

Användare och datorobjekt måste ligga i en OU (eller en överordnad OU utan Block Inheritance) som GPO:n är länkad till. En GPO som ligger i Group Policy Objects-noden men inte är länkad gör ingenting. Lika illa: en GPO länkad till en OU där datorobjekten faktiskt inte ligger. Kör Get-ADComputer WS-DESKTOP-042 -Properties DistinguishedName och jämför mot GPO:ns länk-scope i GPMC.

2. Säkerhetsfiltrering saknar Authenticated Users eller Domain Computers

Efter MS16-072 (säkerhetsuppdateringen från 2016 som många glömmer) krävs att datorobjektet har Read-rättigheter på GPO:n, även för användarinställningar. Tar du bort Authenticated Users från Security Filtering måste du lägga tillbaka Domain Computers med Read-rättigheter under Delegation-fliken, annars läser klienten aldrig in policyn.

3. WMI-filter matchar inte

Ett WMI-filter som SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.22%" exkluderar tyst alla Windows 11 24H2-klienter (de rapporterar 10.0.26100). Testa filtret manuellt på en klient innan du publicerar det:

Get-CimInstance -Query 'SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.22%"'

Returnerar kommandot ingenting matchar inte filtret, och GPO:n hoppas över.

4. Block Inheritance eller Enforced är inkonsekvent

Block Inheritance på en barn-OU stoppar alla GPO:er från överordnade OU:er, så länge de inte är markerade som Enforced. Att slänga in Block Inheritance "för säkerhets skull" är ärligt talat något av det värsta jag ser i fält. Du gör domänen oförutsägbar för alla som kommer efter dig.

5. Klienten har inte fått policyn än

Bakgrundsuppdatering sker var 90:e minut plus ett slumpmässigt offset på 0 till 30 minuter. Ny dator i en ny OU? Den får inte policyn förrän vid nästa uppdatering, eller tills du tvingar fram den. Vilket vi gör i nästa avsnitt.

Hur tvingar jag uppdatering av grupprincip?

Det klassiska kommandot är gpupdate /force, men det finns några variationer som tier-1 sällan känner till och som sparar tid när du felsöker en hel byggnad samtidigt.

# Tvinga om-applicering av alla policyer (dator + användare). /force = ignorera versionscache.
gpupdate /force

# Vill du logga ut användaren automatiskt om en användar-CSE kräver det? Annars frågar Windows.
gpupdate /force /logoff

# Boot-time policyer som mappade enheter eller startup-script? Då behövs reboot.
gpupdate /force /boot

# Bara datorinställningar (snabbare, ingen användarpolling)
gpupdate /target:computer /force

För fjärrutförande från en admin-burk finns Invoke-GPUpdate i GroupPolicy-modulen. Den schemalägger en uppdatering på den angivna datorn via Task Scheduler och fungerar mot vilken domänansluten Windows-klient som helst, så länge du har RPC öppet i brandväggen.

# Tvinga uppdatering på en remote-klient
Invoke-GPUpdate -Computer "WS-DESKTOP-042" -Force

# Hela en OU i batch — perfekt efter en helgsändning av en stor policyändring
Get-ADComputer -SearchBase "OU=Klienter,DC=contoso,DC=local" -Filter * |
    ForEach-Object { Invoke-GPUpdate -Computer $_.Name -RandomDelayInMinutes 0 -Force }

Om gpupdate kastar fel "The processing of Group Policy failed" är det sällan policyn själv. Det är nästan alltid att klienten inte hittar en DC, att SYSVOL-sökvägen (\\contoso.local\SYSVOL) inte är nåbar, eller att en CSE (Client-Side Extension) har kraschat. Kontrollera Event Viewer-loggen jag pratar om längre ner.

WMI-filter, säkerhetsfiltrering och Item-Level Targeting

Tre filtreringsmekanismer påverkar om en policy körs eller inte, och de utvärderas i olika ordning. Många blandar ihop dem och felsöker fel sak.

Mekanism	Var den utvärderas	Användbar för	Felsöks med
Security Filtering	GPO-objektets ACL	Tillämpa policy bara på en viss säkerhetsgrupp	gpresult /h, fliken Delegation
WMI Filter	Klientens WMI vid policy-pull	OS-version, modellnummer, RAM-mängd	Get-CimInstance med filterets query
Item-Level Targeting (ILT)	Group Policy Preferences vid apply	Per-objekt-villkor i en GPP (mappad enhet, registernyckel)	gpresult /h sektionen Preferences
Block Inheritance / Enforced	OU-hierarkin	Stoppa policyer från överordnade OU:er	GPMC, kolumnen Enforced/Blocked

Säkerhetsfiltrering är där flest fel uppstår eftersom det är två rättigheter som måste stämma: Read och Apply Group Policy. Tar du bort Authenticated Users helt försvinner båda. Och eftersom Apply Group Policy implicit kräver Read missar du ofta att lägga tillbaka Read för Domain Computers. Resultat: GPO:n läses aldrig in och visas som "Inaccessible, Empty, or Disabled" i rapporten.

WMI-filter är notoriskt långsamma. Varje filter kostar 100 till 500 ms vid policy-bearbetning, och de utvärderas vid varje uppdatering, även bakgrundscykler. Har du fem WMI-filter på en användares policy-set ligger du på 2 till 3 sekunders extra inloggningstid. Använd hellre Item-Level Targeting i Group Policy Preferences när det går; ILT cacheas och är billigare. Microsoft beskriver detta tradeoff väl i deras Group Policy-processing-dokumentation.

För att felsöka ett misstänkt WMI-filter, kör filterets WQL-fråga direkt på klienten via PowerShell och se vad den returnerar:

# Filtrets WQL: SELECT * FROM Win32_ComputerSystem WHERE Manufacturer = "LENOVO"
Get-CimInstance -Query 'SELECT * FROM Win32_ComputerSystem WHERE Manufacturer = "LENOVO"'

# Returnerar inget? Då matchar filtret inte. Kontrollera den faktiska tillverkar-strängen:
(Get-CimInstance Win32_ComputerSystem).Manufacturer
# "LENOVO " med ett efterföljande mellanslag är ett klassiskt skäl till missmatch

Loopback processing och Block Inheritance

Loopback processing är ett av de mest missförstådda inslagen i Group Policy. Standardbeteendet är att användarinställningar i en GPO bara tillämpas om GPO:n är länkad till en OU där användaren ligger. Det är fel sätt att tänka när du har shared workstations, RDS-värdar eller kioskburkar. Där vill du att maskinen ska bestämma vilka användarinställningar som ska gälla, oavsett var användaren ligger i AD.

Slå då på User Group Policy loopback processing mode under Computer Configuration → Policies → Administrative Templates → System → Group Policy. Du väljer mellan två lägen:

• Replace: Användarens egna GPO:er ignoreras helt. Bara användarinställningarna i de GPO:er som är länkade till datorns OU tillämpas. Använd på kioskmaskiner.
• Merge: Användarens egna GPO:er körs först, sedan körs datorns OU:s användarinställningar ovanpå. Resultatet vinner. Använd på RDS-värdar där du vill behålla de flesta användarinställningar men skriva över ett par.

Block Inheritance är den andra knappen som folk slänger på i panik. Sätt den på en OU och alla överliggande GPO:er stoppas, utom de markerade Enforced. Problemet är att Enforced ofta används för säkerhetspolicyer (lösenordskrav, BitLocker-tvång) och då vinner de över din Block Inheritance ändå. Du har bara skapat en illusion av kontroll. För enhetshärdning som BitLocker rekommenderar vi vår felsökningsguide för BitLocker i Windows 11 som komplement.

SYSVOL-replikering och Event Viewer Operational-loggen

Här ligger problemen som tar längst att hitta, just för att de inte syns i gpresult. SYSVOL är den delade mapp på domänkontrollanterna där själva GPO-innehållet bor: Registry.pol-filerna, startup-script, ADMX-mallar. Om DFSR (Distributed File System Replication, som ersatte FRS för länge sedan) hänger sig, får inte alla DC:er den senaste versionen, och klienter som råkar tala med en eftersläpande DC ser en gammal policy.

Snabbtest från en admin-burk:

# Triggar en omedelbar AD-replikering på alla DC:er
repadmin /syncall /AdeP

# Kollar att SYSVOL-DFSR är frisk på alla DC:er
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    Write-Host "== $dc ==" -ForegroundColor Cyan
    dfsrdiag pollad /member:$dc
    dfsrdiag backlog /sendingmember:$dc /receivingmember:DC02 /rgname:"Domain System Volume" /rfname:SYSVOL Share
}

När SYSVOL-replikeringen är frisk men policyn ändå inte tillämpas på klienten är det Event Viewer Operational-loggen som ger svaret. Öppna Event Viewer → Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Filtrera på de senaste 24 timmarna och leta efter:

• Event 4016 / 5016: CSE (Client-Side Extension) startar eller avslutar. Tar någon CSE 30+ sekunder är det en flaskhals, ofta Drive Maps eller Software Installation.
• Event 6017: Slow link detection. Klienten har bedömt nätverket som långsamt (under 500 kbps) och hoppar över vissa CSE:er. Vanligt på VPN-anslutna klienter, se vår VPN-felsökning i Windows 11 för åtgärder.
• Event 7017: Misslyckad WMI-filter-utvärdering. Hela GPO:n hoppas över. Du måste fixa filterets WQL eller WMI-repository på klienten (winmgmt /verifyrepository).
• Event 5311: Lista över alla tillämpade GPO:er i den senaste cykeln. Utmärkt för att korrelera med gpresult.

Om WMI-repositoryt är korrupt (inte ovanligt på äldre Windows 10-burkar som migrerats) får du 0x80041002 i Operational-loggen. Räddningskommandot är Get-CimInstance Win32_ComputerSystem. Kraschar det, kör winmgmt /salvagerepository. Misslyckas det också får du bygga om: winmgmt /resetrepository. Räkna med en reboot och att vissa CSE:er behöver tid på sig att registrera sig på nytt.

Vanliga frågor

Vad är skillnaden mellan gpupdate och gpresult?

gpupdate applicerar policyerna på nytt. Det är en aktiv åtgärd som hämtar och kör Group Policy-bearbetningen. gpresult är passivt; det rapporterar bara vad som redan har tillämpats vid den senaste bakgrundscykeln. Felsökningsflödet är alltid: kör gpupdate /force, vänta att den slutförs, kör sedan gpresult /h för att se vad som blev resultatet.

Hur ser jag vilka GPO:er som tillämpas på en användare?

Kör gpresult /user CONTOSO\anna.svensson /h C:\Temp\anna.html /f medan användaren är inloggad på datorn. HTML-rapporten har separata sektioner för Computer Settings och User Settings. Under User Settings ser du både "Applied GPOs" och "Denied GPOs" med skäl. Behöver du köra det från GPMC istället, använd Group Policy Results-guiden under Group Policy Modeling-noden.

Hur felsöker jag WMI-filter i Group Policy?

Kopiera WQL-frågan från WMI-filterobjektet i GPMC och kör den på den drabbade klienten med Get-CimInstance -Query "<din-wql>". Returnerar den inget matchar inte filtret, och GPO:n hoppas över. Vanliga snubbeltrådar: hårdkodade versionssträngar som inte täcker nyaste Windows-build, BIOS-tillverkar-strängar med trailing space, och frågor mot WMI-klasser som kräver lokala adminrättigheter.

Vad är loopback processing i Group Policy?

Loopback processing tvingar Windows att bearbeta användarinställningarna i de GPO:er som är länkade till datorns OU, oavsett var användaren ligger i AD. Replace-läget ersätter användarens egna policyer helt; Merge-läget kombinerar dem med datorns. Används främst på kioskmaskiner, RDS-värdar och delade datorer där maskinen ska diktera användarupplevelsen.

Varför säger gpresult "Access Denied" på min GPO?

Klienten eller användaren saknar Read-rättigheter på GPO:n. Efter MS16-072 kräver bearbetning att även datorobjektet kan läsa GPO:n, även om det bara är användarinställningar i den. Lägg tillbaka Authenticated Users eller Domain Computers med Read-rättigheter under fliken Delegation i GPMC och kör gpupdate /force igen.