Ryhmäkäytäntö ei sovellu Windows 11:ssä – Vianmääritysopas 2026 (gpresult, AES Kerberos, Event ID 4117)

Päivitetty: 22. kesäkuuta 2026

Jos ryhmäkäytäntö ei sovellu Windows 11 -työasemalla, syy on lähes aina yksi neljästä: gpsvc-palvelu ei toimi, suojaussuodatus estää käytön, WMI-suodatin ei osu kohteeseen tai Windows 11 24H2:n Kerberos-AES-vaatimus on jättänyt vanhan toimialueen ulkopuolelle. Tämä opas käy nämä syyt läpi 2026 vuoden työkaluilla – gpresult, uusi Event ID 4117 (KB5074109), parannettu Event ID 1096 -lokitus sekä paikalliseen gpedit.msc:ään tullut GPP-vianetsintälokitus – ja näyttää tarkat komennot, joilla saat käytännön takaisin toimimaan tunnissa.

• Aloita aina komennolla gpresult /h C:\Temp\gpo.html – se kertoo suoraan, mitkä GPO:t sovellettiin ja mitkä hylättiin (Security, WMI, Empty).
• Windows 11 24H2:n yleisin GPO-virhe (gpupdate epäonnistuu LDAP Bindiin) johtuu siitä, että uusi rakennus vaatii AES128/AES256_HMAC_SHA1 Kerberos-salausta – RC4 ei enää riitä.
• Tammikuun 2026 kumulatiivinen päivitys (KB5074109 / KB5073455) tuo Event ID 4117:n, joka korvaa Event ID 4098:n geneerisen virhetekstin tarkalla virhekoodilla, UNC-polulla ja CSE-nimellä.
• Helmikuun 2026 päivityksen jälkeen Event ID 1096 paljastaa registry.pol-tiedoston korruption – aiemmin tämä oli yksi vaikeimmin diagnosoitavista GPO-vioista.
• Käyttäjäpolitiikat eivät pomppaa terminaalipalvelimelle tai jaetulle koneelle ilman Loopback-prosessointia (Replace tai Merge) – tämä on edelleen yleisin syy "Käyttäjäkäytäntö ei sovellu" -tiketteihin.
• RSoP.msc on käytännössä kuollut – Microsoft suosittelee gpresult:ia, koska RSoP.msc ei näytä GPP- eikä useimpia CSE-asetuksia Windows 10/11:ssä.

Mistä aloittaa: ensimmäiset viisi minuuttia

No niin, kun käyttäjä soittaa ja sanoo "kirjoitinkartoitus ei tule" tai "työpöydän tausta ei vaihdu", ensimmäinen virhe on lähteä etsimään GPMC:stä. Itse avaan aina ensin järjestyksessä kolme asiaa: gpresult /r, gpsvc-palvelun tila ja Microsoft-Windows-GroupPolicy/Operational-tapahtumaloki. Näiden kolmen perusteella 80 % tiketeistä saa heti suunnan. Jos gpresult kertoo, että viimeinen sovellus oli yli kaksi tuntia sitten, tiedät jo että ongelma on joko verkossa tai gpsvc:ssä – ei GPO:ssa itsessään.

Käynnistä komentokehote järjestelmänvalvojana (Ctrl+Shift+Enter cmd:llä) – tämä on välttämätöntä, koska gpresult lukee RSoP-tietokannan kansiosta %SystemRoot%\System32, ja keskimmäinen integriteettitaso antaa "Access Denied" -virheen vaikka olisitkin paikallinen Admin. Sen jälkeen tämä yksi komento kertoo enemmän kuin kaksi tuntia GPMC:n selailua:

# Generoi HTML-raportti, joka näyttää SEKÄ tietokone- että käyttäjäkäytännöt
# /h = HTML, /f = ylikirjoitus, /scope:both on oletus
gpresult /h C:\Temp\gpo.html /f

# Avaa raportti selaimessa
start C:\Temp\gpo.html

HTML-raportti listaa "Applied GPOs" -osiossa kaikki onnistuneet GPO:t aikajärjestyksessä sekä "Denied GPOs" -osiossa hylätyt – ja tärkein osa: syy. Syy on aina yksi neljästä: Empty (asetukset puuttuvat), Disabled (GPO:n osa pois päältä), WMI Filter denied tai Security denied. Tämän jälkeen tiedät tarkalleen, mihin kohtaan GPMC:ssä mennä.

Miten gpresult-komentoa käytetään tehokkaasti

Tier 1 -porukka usein kirjoittaa pelkän gpresult /r:n ja jää tuijottamaan tekstiseinää. Komennossa on kuitenkin valitsimia, jotka säästävät tunteja. Tässä komennot, jotka minulla on aina lähellä – kommentoituna niin, että ne voi liittää suoraan tikettiin tier 1:lle.

# Pelkkä yhteenveto, nopein katsaus
gpresult /r

# Vain käyttäjäpolitiikat (kun käyttäjä-CSE epäilyttää)
gpresult /r /scope:user

# Vain tietokonepolitiikat (käynnistyksen yhteydessä sovelletut)
gpresult /r /scope:computer

# Verbose-tila näyttää myös sovelletut rekisteriarvot
gpresult /v

# Erittäin verbose – kaikki CSE:t, GPP:t, suodattimet
gpresult /z > C:\Temp\gpresult-z.txt

# Etäkone toimialueen kautta (vaatii etäkäyttöoikeudet ja portin 135)
gpresult /s WS-PEKKA-01 /user TOIMIALUE\pekka.virtanen /h C:\Temp\pekka.html

# Vie leikepöydälle nopeasti chatiin liitettäväksi
gpresult /r | clip

Käytännön vinkki: /z on liian tiheä ihmisen luettavaksi, mutta erinomainen findstr-suodatukseen. Jos epäilet tiettyä CSE:tä – esimerkiksi karttojen ajureita tai kirjoitinasennusta – aja gpresult /z | findstr /i "printer drive map" ja näet vain ne rivit.

Miksi GPO ei sovellu: viisi yleisintä syytä

Olen tehnyt service desk -työtä toimialueympäristöissä yli vuosikymmenen ja voin sanoa, että GPO-tiketit jakautuvat hyvin tarkasti viiteen kategoriaan. Tässä järjestyksessä yleisimmästä harvinaisempaan – tämä on hyvä mielessä, kun avaat raporttia.

1. Suojaussuodatus (Security Filtering)

GPO:n Scope-välilehdellä Security Filtering -listan jäsenten täytyy olla niitä käyttäjiä tai tietokoneita, joihin GPO:n on määrä soveltua. Yleisin moka: poistetaan "Authenticated Users" ja unohdetaan lisätä "Domain Computers" -ryhmä, joka tarvitaan että tietokone-CSE:t (kuten käynnistysskriptit) saavat luettua GPO:n SYSVOL-kansiosta. Tämä rikkoutui MS16-072:n jälkeen ja särkee yhä viikoittain GPO:ita.

2. WMI-suodatin osuu väärin

WMI-suodattimet kuten SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.26100%" (24H2) toimivat hyvin – kunnes Microsoft julkaisee uuden build-numeron ja suodatin ei enää osu. Tarkista suodatin komennolla Get-WmiObject Win32_OperatingSystem | Select Version, BuildNumber kohdetyöasemalla.

3. OU-linkitys puuttuu tai on poissa päältä

GPMC:ssä linkki voi olla "Link Enabled = No" tai linkkiä ei ole edes luotu kohde-OU:hun. Klassinen näppituntumavirhe etenkin, jos sama GPO halutaan testata yhteen OU:hun ennen julkaisua.

4. Block Inheritance / Enforced -ristiriita

Kun johonkin OU:hun on asetettu "Block Inheritance" (sininen huutomerkki), kaikki ylätason GPO:t pysähtyvät – paitsi ne, joissa on Enforced (eli ennen "No Override"). Tämä yhdistelmä on hyvin yleinen vianmäärityskohde palvelinpuolen OU:issa.

5. Group Policy Client -palvelu (gpsvc) ei toimi

Jos gpsvc on pysähtynyt, mikään GPO ei sovellu eikä gpupdate /force tee mitään. Tämä on harvinaisempaa, mutta yleensä syy on käyttäjä, joka on yrittänyt "optimoida" Windowsin sammuttamalla palveluita. Tarkista PowerShellillä:

# Tarkista palvelun tila ja käynnistystila
Get-Service gpsvc | Select Name, Status, StartType

# Jos pysähtynyt, käynnistä – pitää olla Automatic
Set-Service gpsvc -StartupType Automatic
Start-Service gpsvc

Jos Active Directory -puoli vaikuttaa ongelman taustalla – esimerkiksi käyttäjätili on lukittunut eikä Kerberos-lippua saa – kannattaa katsoa myös AD-tilien lukituksen vianmääritys samaan aikaan. Lukittu tili ei saa GPO:ta ladattua.

Windows 11 24H2 -ongelma: AES Kerberos -salaus pakolliseksi

Tämä on se ongelma, joka räjäytti hyvin monta järjestelmänvalvojaa loppuvuodesta 2025, ja rehellisesti sanottuna räjäyttää yhä. Kun työasema päivitettiin Windows 11 24H2:een, gpupdate /force alkoi tuottaa virheitä:

Computer policy could not be updated successfully. The following errors were
encountered:
The processing of Group Policy failed because of lack of network connectivity
to a domain controller. The LDAP Bind function call failed.

Verkko oli kuitenkin kunnossa, DNS osui, ping ja nslookup toimivat. Ongelma on Kerberos-salausalgoritmi: Windows 11 24H2 vaatii AES128_HMAC_SHA1 ja AES256_HMAC_SHA1 -salausta, eikä neuvottele enää RC4_HMAC_MD5:n kanssa kuten aiemmat versiot. Monessa pitkään pyörineessä toimialueessa on käytäntö "Network security: Configure encryption types allowed for Kerberos", jossa AES on jätetty pois päältä. Tämän GPO:n täytyy nyt sallia AES128_HMAC_SHA1 + AES256_HMAC_SHA1.

Korjaus: avaa GPMC, etsi käytäntö, jossa salaustyypit on rajoitettu, ja varmista, että vähintään nämä rastit ovat päällä:

• AES128_HMAC_SHA1
• AES256_HMAC_SHA1
• Future encryption types

Sen jälkeen toimialueen ohjaimien msDS-SupportedEncryptionTypes-attribuutti pitää nostaa arvoon 0x18 (24) tai parempi. PowerShellillä:

# Tarkista nykyiset salausalgoritmit kaikilta DC-koneilta
# AD-moduuli vaaditaan: Import-Module ActiveDirectory
Get-ADDomainController -Filter * | ForEach-Object {
    Get-ADComputer $_.Name -Properties msDS-SupportedEncryptionTypes |
    Select Name, @{N='EncTypes';E={$_.'msDS-SupportedEncryptionTypes'}}
}

# Jos arvo on 4 (vain RC4), nosta se arvoon 24 (AES128 + AES256)
# 28 = AES128 + AES256 + RC4 jos vanhoja klientteja tarvitaan
Set-ADComputer DC01 -Replace @{'msDS-SupportedEncryptionTypes'=24}

Microsoftin virallisessa Group Policy -vianmääritysoppaassa on dokumentoitu sama – mutta varoituksena: kun nostat DC:n salaustyyppejä, vanhat RC4-asiakkaat (esim. tietyt Linux-Samba-jäsenet tai vanhat NAS-laitteet) saattavat lakata autentikoimasta. Testaa pilottikoneella aina ensin.

Event ID 4117 ja parannettu 1096 – mitä 2026 päivitykset toivat

Tammikuun 2026 kumulatiivisen päivityksen mukana (KB5074109 24H2:lle ja KB5073455 25H2:lle) Microsoft viimein paransi Group Policy Preferences -lokitusta. Aiemmin Event ID 4098 oli geneerinen "Failed to apply" -teksti, jonka diagnostinen arvo oli lähellä nollaa. Uusi Event ID 4117 aktivoituu automaattisesti ja tuottaa muun muassa:

• Tarkka virhekategoria (Files, Shortcuts, Drive Maps, Printers, Registry...)
• UNC-polku, johon yritettiin päästä, ja virhekoodi
• Käytäntö-GUID ja GPO:n nimi
• Käyttäjä- vai tietokone-CSE

Avaa siis Event Viewer ja navigoi: Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Suodata Event ID 4117:n perusteella. Jos käytät SCOMia, Splunkia tai Azure Monitor Agentia, lisää 4117 monitoroitavien listalle – 4098 jää edelleen oletuksena, joten älä jätä sitä pois, mutta 4117 antaa reilusti enemmän tietoa.

Helmikuun 2026 päivitys taas paransi Event ID 1096:n viestiä. Tämä on klassinen registry.pol-tiedoston käsittelyssä syntyvä virhe ja oli aiemmin yksi pelottavimmista, koska viestissä ei juuri kerrottu mistä on kyse. Nyt 1096 sisältää tiedoston polun, korruptiotyypin ja viitteen siihen, onko vika paikallisessa LGPO:ssa vai toimialuepolitiikassa. AskDS-tiimin blogi käy korjausvaiheet läpi kohta kohdalta, mutta käytännössä paikallisen registry.pol:n poisto on yleensä riittävä:

# Tämä TYHJENTÄÄ paikallisen Group Policy -puolen rekisteripuun
# Käytä vain, jos olet varma, että paikallisia LGPO:ita ei tarvita
# (Toimialuepolitiikat eivät katoa – ne haetaan SYSVOLista uudelleen)

# Poista konepolitiikan registry.pol
Remove-Item "$env:SystemRoot\System32\GroupPolicy\Machine\registry.pol" -Force

# Poista käyttäjäpolitiikan registry.pol
Remove-Item "$env:SystemRoot\System32\GroupPolicy\User\registry.pol" -Force

# Pakota uudelleenhaku DC:ltä
gpupdate /force /sync

Helmikuun 2026 preview-päivityksestä alkaen GPP-vianetsintälokit voi nyt kytkeä päälle paikallisessa gpedit.msc:ssä, mikä on iso parannus: aiemmin ADMX-tiedostot piti kopioida DC:lle ja luoda GPO ennen kuin sai yhden työaseman lokin näkyviin.

Käyttäjäkäytäntö ei sovellu – Loopback-prosessointi

Tämä on kestosuosikki (jokaisessa työpaikassa, jossa olen ollut, sama tiketti tulee kerran kuussa): käyttäjä kirjautuu jaettuun työasemaan tai terminaalipalvelimeen, eikä käyttäjäkäytäntö (kuten kirjoitinkartoitukset tai Internet Explorer -asetukset) sovellu, vaikka gpresult /r /scope:user näyttää että ne pitäisi soveltua. Syy on yleensä se, että käyttäjä asuu eri OU:ssa kuin tietokone, ja kone-OU:hun linkitetyt käyttäjäpuolen asetukset eivät pomppaa läpi normaalin GPO-prosessoinnin kautta.

Korjaus on Loopback-prosessointi. Sen kahdesta tilasta valitse Mode huolellisesti:

• Merge: käyttäjä saa sekä OU:nsa että koneen OU:n käyttäjäkäytännöt. Ristiriidoissa kone-OU:n GPO voittaa. Sopii useimpiin tapauksiin.
• Replace: käyttäjä saa vain kone-OU:n käyttäjäkäytännöt. Käyttäjän omat OU-käytännöt jätetään huomiotta. Tämä on oikea valinta vain kiosk- tai erikoiskäyttötilanteissa.

Asetus löytyy: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode. Lisää tämä GPO koneen OU:hun (esim. kioskikoneiden OU) ja muista linkata se sinne, missä koneet ovat – ei sinne, missä käyttäjät ovat.

registry.pol-korruption tunnistaminen ja korjaus

Korruptoitu registry.pol-tiedosto on ilkeä – paikallinen koneella oleva korruptio voi estää myös toimialuekäytäntöjen rekisteriasetusten soveltumisen, vaikka itse GPO:t olisivat täysin terveitä DC-puolella. Tämä yllätti meidätkin pari vuotta sitten, kun yritimme metsästää syytä siihen, miksi sama Internet Explorer -käytäntö meni läpi 800 koneella mutta ei kymmenellä. Vastaus: kaikilla niillä kymmenellä oli korruptoitunut paikallinen registry.pol, joka kaatoi koko CSE-ketjun ennen kuin domain-puoli ehti edes alkaa.

Korruption merkit Event Viewerissä (Microsoft-Windows-GroupPolicy/Operational):

• Event ID 1096 – "Application of Registry policy failed" (helmikuun 2026 päivityksen jälkeen tarkempi virheteksti)
• Event ID 7016 – CSE:n käsittely epäonnistui
• Event ID 1085 – tunniste-CSE:n virhe

Skripti, jota minä käytän vianmäärityksessä – kommentoituna, jotta tier 1 -porukka voi ajaa sen itse:

# Tarkista registry.pol-tiedostojen koko ja viimeisin muutos
# Tervetiedoston koko on tyypillisesti 100-50000 tavua. 0 tai > 10 MB on epäilyttävä.

$paths = @(
    "$env:SystemRoot\System32\GroupPolicy\Machine\registry.pol",
    "$env:SystemRoot\System32\GroupPolicy\User\registry.pol"
)

foreach ($p in $paths) {
    if (Test-Path $p) {
        $f = Get-Item $p
        Write-Host "$($f.FullName) – $($f.Length) tavua – $($f.LastWriteTime)"
    } else {
        Write-Host "$p – tiedostoa ei ole (ei välttämättä virhe)"
    }
}

# Tutki, alkavatko tiedostot tutuilla "PReg" magic bytesilla (50 52 65 67)
# Jos eivät, tiedosto on lähes varmasti korruptoitunut
foreach ($p in $paths) {
    if (Test-Path $p) {
        $bytes = [System.IO.File]::ReadAllBytes($p) | Select -First 4
        $hex = ($bytes | ForEach-Object { $_.ToString('X2') }) -join ' '
        Write-Host "$p alkaa: $hex (terve = 50 52 65 67)"
    }
}

PowerShell-diagnostiikka ja etäkoneiden tutkiminen

Kun tikettejä on jonossa eikä jokaiselle koneelle pääse fyysisesti, PowerShell on välttämätön. Tässä komentokokoelma, joka kattaa 95 % GPO-diagnostiikasta etänä. Windows 11 verkon vianmääritys PowerShellillä -oppaassa on lisäksi verkkopuolen komennot, joita yleensä tarvitset rinnalla.

# Aja gpresult etäkoneella ja palauta HTML paikalliseen kansioon
# Tämä vaatii PSRemoting-yhteyden (Enable-PSRemoting kohdekoneella) tai
# WinRM:n läpi avoinna olevan portin 5985
Invoke-Command -ComputerName WS-PEKKA-01 -ScriptBlock {
    gpresult /h C:\Temp\gpo.html /f
    Get-Content C:\Temp\gpo.html -Raw
} | Out-File C:\Temp\WS-PEKKA-01-gpo.html

# Hae GroupPolicy/Operational-tapahtumalokit etäkoneelta
Get-WinEvent -ComputerName WS-PEKKA-01 -FilterHashtable @{
    LogName='Microsoft-Windows-GroupPolicy/Operational';
    Level=1,2,3;          # Critical, Error, Warning
    StartTime=(Get-Date).AddHours(-24)
} | Select TimeCreated, Id, LevelDisplayName, Message |
    Format-Table -Wrap

# Pakota GPO-päivitys etäkoneella ilman uudelleenkäynnistystä
Invoke-GPUpdate -Computer WS-PEKKA-01 -Force -RandomDelayInMinutes 0

Jos olet hybridi-Entra-ID-ympäristössä ja työasema on Entra-liittynyt mutta ei toimialueliittynyt, perinteinen GPO ei sovellu lainkaan – tarvitset Intune-konfiguraatioprofiileja tai Settings Catalog -käytäntöjä. Tämä on tärkeä rajata vianmäärityksen alkuvaiheessa: dsregcmd /status näyttää, onko kone "AzureAdJoined : YES" vai "DomainJoined : YES".

Jos koko Windows-päivityskerrosta epäilyttää (esim. tuore CU on jättänyt jotain rikki), Windows 11 KB5077181 -päivityksen ongelmat ja korjausohjeet -opas käy yhden tunnetun tapauksen läpi.

Usein kysytyt kysymykset

Miten pakotan ryhmäkäytännön päivittymään välittömästi?

Komento gpupdate /force /sync ajaa sekä kone- että käyttäjäkäytännöt heti ja synkronoi ne ennen kuin paluu komentokehotteeseen tapahtuu. Joissakin CSE:issä (esim. Folder Redirection, ohjelmaasennukset) muutos vaatii silti uloskirjautumisen tai uudelleenkäynnistyksen – gpupdate kertoo tämän viestissään.

Mikä on ero gpresultin ja rsop.msc:n välillä?

gpresult on komentorivityökalu, joka näyttää myös GPP:n ja kaikki CSE:t. rsop.msc on graafinen MMC, joka on ollut Windows 7:n jälkeen vajaa: se ei näytä GPP-asetuksia, kirjoitinkartoituksia eikä useimpia ei-rekisteripohjaisia laajennuksia. Microsoft suosittelee virallisesti gpresultia Vista SP1:n jälkeen.

Miksi GPO ei näy gpresult-raportissa lainkaan?

Jos GPO ei näy edes "Denied"-listalla, sitä ei lainkaan luettu. Yleisimmät syyt: GPO on linkittämättä mihinkään OU:hun, linkki on poissa päältä, koko GPO on disabled, tai SYSVOL-replikaatio ei ole valmistunut. Tarkista dfsrdiag pollad:lla, että SYSVOL on kunnossa kaikilla DC:illä.

Mikä on Event ID 4117 ja miten saan sen päälle?

Event ID 4117 on tammikuun 2026 kumulatiivisen päivityksen (KB5074109 / KB5073455) mukana tullut GPP-vianetsintätapahtuma, joka tuo tarkat virhekoodit ja UNC-polut Group Policy Preferences -virheisiin. Se aktivoituu automaattisesti, kun päivitys on asennettu – ei lisäkonfigurointia tarvita. Tapahtuma näkyy lokissa Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational.

Miksi käyttäjäkäytäntö ei sovellu jaetussa työasemassa?

Käyttäjäpuolen GPO:t soveltuvat oletuksena vain käyttäjän oman OU:n GPO:ista. Jos haluat, että koneen OU:n käyttäjäpuolen asetukset (kirjoittimet, kotihakemistot, IE-asetukset) soveltuvat kaikille koneeseen kirjautuville, ota käyttöön Configure user Group Policy loopback processing mode ja valitse Merge tai Replace tilanteen mukaan. Asetus tehdään kone-OU:hun linkattuun GPO:hon.

Miten korjaan Windows 11 24H2:n GPO LDAP Bind -virheen?

Lähes aina syy on Kerberos-salaustyypit. Lisää käytäntöön "Network security: Configure encryption types allowed for Kerberos" rastit AES128_HMAC_SHA1 ja AES256_HMAC_SHA1 ja varmista että toimialueen ohjaimien msDS-SupportedEncryptionTypes-attribuutti on vähintään 24 (AES128 + AES256). RC4-only ei enää riitä 24H2:lle.