GPO Uygulanmıyor: Group Policy Hata Tespiti ve Çözümü

Tarafındankomut
0 Comments

Pazartesi sabahı geldiniz, kullanıcılardan şikayetler yağmaya başladı: “Masaüstü arka planı değişmedi”, “USB diskler hala çalışıyor”, “Tarayıcı ayarları uygulanmamış.” GPO’larınızı dün akşam güzelce yapılandırdınız, test ettiniz, her şey mükemmeldi. Ama sabah gerçeklik farklı bir tablo gösteriyor. Group Policy uygulanmama sorunu, sysadmin hayatının en sinir bozucu problemlerinden biridir. Çünkü onlarca farklı nedeni olabilir ve hata mesajı genellikle “bir şeyler yanlış” kadar muğlak kalır. Bu yazıda, sistematik bir yaklaşımla GPO sorunlarını nasıl teşhis edip çözeceğinizi adım adım ele alacağız.

Önce Temel Kontrolleri Yap

Panik yapmadan önce en basit şeylerden başlamak gerekiyor. Yılların deneyimi şunu öğretti: büyük sorunların arkasında çoğunlukla küçük, gözden kaçan bir detay yatıyor.

Bilgisayar domain’e bağlı mı?

Bu soruyu sormak kulağa basit geliyor ama inanın, bazen en deneyimli adminler bile bunu atlıyor. Özellikle VPN üzerinden bağlanan uzak kullanıcılarda veya yakın zamanda yeniden image’lanan makinelerde domain bağlantısı kopmuş olabilir.

# PowerShell ile domain üyeliğini kontrol et
(Get-WmiObject Win32_ComputerSystem).Domain
(Get-WmiObject Win32_ComputerSystem).PartOfDomain

GP güncellemesi yapıldı mı?

GPO değişiklikleri otomatik olarak uygulanır ama varsayılan yenileme aralığı bilgisayarlar için 90 dakika + rastgele 0-30 dakikalık ofset, DC’ler için ise 5 dakikadır. Hemen test etmek istiyorsanız elle güncelleme yapın:

# Temel GP güncelleme komutu
gpupdate /force

# Güncelleme sonrası logout/login gerektiren politikalar için
gpupdate /force /logoff

# Sadece bilgisayar politikalarını güncelle
gpupdate /target:computer /force

# Sadece kullanıcı politikalarını güncelle
gpupdate /target:user /force

gpupdate /force çalıştırdıktan sonra “The processing of Group Policy failed” gibi bir hata görüyorsanız, sorun network veya Active Directory tarafında demektir. Eğer başarıyla tamamlandı ama politika hala uygulanmıyorsa, kapsam (scope) veya filtreleme sorununa bakmak gerekir.

GPRESULT ile Durum Analizi

gpresult komutu, GPO sorun gidermenin İsviçre çakısıdır. Hangi politikaların uygulandığını, hangilerinin filtrelendiğini ve neden reddedildiğini gösterir.

# Mevcut kullanıcı ve bilgisayar için özet rapor
gpresult /r

# Belirli bir kullanıcı için rapor (admin yetkisiyle)
gpresult /r /user DOMAINkullanici_adi

# HTML formatında detaylı rapor oluştur
gpresult /h C:Tempgp_rapor.html /f

# Hem kullanıcı hem bilgisayar için verbose çıktı
gpresult /v

# Uzak bir bilgisayar için rapor
gpresult /s UZAK-PC-ADI /r

gpresult /r çıktısında dikkat etmeniz gereken kritik bölümler şunlar:

  • Applied Group Policy Objects: Bu bölümde uygulanmış GPO’lar listelenir. Beklediğiniz GPO burada görünmüyorsa sorun var demektir.
  • The following GPOs were not applied because they were filtered out: Filtrelenen GPO’lar buraya düşer ve neden filtrelendiği de yazar. “Denied (Security)” veya “Disabled (GPO)” gibi açıklamalar görürsünüz.
  • The computer is a part of the following security groups: Bilgisayarın üye olduğu güvenlik grupları burada listelenir.

Gerçek dünyadan bir örnek: Bir müşteride USB devre dışı bırakma politikası uygulanmıyordu. gpresult /r çıktısına baktığımda GPO “Filtered Out” bölümündeydi ve yanında “Denied (Security)” yazıyordu. Sorun, GPO’nun güvenlik filtrelemesinde “Authenticated Users” grubunun kaldırılıp yerine yanlışlıkla sadece “Domain Users” eklenmesiydi. Bilgisayar hesapları “Domain Users” grubunda olmadığından, bilgisayar politikası uygulanmıyordu. Security filtering’e “Domain Computers” grubunu ekleyince sorun çözüldü.

Event Log’ları İnceleme

Windows Event Viewer, GPO sorunları için çok değerli bilgiler saklar. Applications and Services Logs > Microsoft > Windows > Group Policy > Operational log kanalı, GP işlemlerine özel detaylı olayları içerir.

# PowerShell ile son GP hatalarını filtrele
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
Where-Object {$_.LevelDisplayName -eq "Error" -or $_.LevelDisplayName -eq "Warning"} |
Select-Object TimeCreated, Id, Message |
Format-List

# Son 50 GP olayını listele
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 50 |
Format-Table TimeCreated, Id, LevelDisplayName, Message -AutoSize -Wrap

# Belirli bir Event ID'yi ara (örneğin 7016 = GP uzantısı başarısız)
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
Where-Object {$_.Id -eq 7016} |
Select-Object -First 10 |
Format-List

Sık karşılaşılan kritik Event ID’leri:

  • 7016: Bir GP uzantısı (CSE – Client Side Extension) başarısız oldu. Hangi uzantının başarısız olduğu ve hata kodu mesajda yer alır.
  • 7320: LDAP sorgusu başarısız oldu. Bu genellikle DC’ye erişim sorununun işaretidir.
  • 1085: Windows GP CSE başarısız. Uzantı adı ve hata kodu ile birlikte gelir.
  • 1006: GP, AD’dan politika bilgisini okuyamadı.
  • 1030: GP, SYSVOL’e erişemedi veya politika dosyalarını bulamadı.

SYSVOL ve NETLOGON Sorunları

GPO ayarları Active Directory veritabanında değil, SYSVOL paylaşımında saklanır. SYSVOL’e erişim sorunu, tüm GP uygulamasını çökertebilir.

# SYSVOL erişimini test et
dir \DOMAIN-ADISYSVOL

# NETLOGON paylaşımını kontrol et
dir \DOMAIN-ADINETLOGON

# GP için kullanılan SYSVOL yolunu doğrula
# GPO GUID'ini bul ve ilgili klasörü kontrol et
dir "\DOMAIN-ADISYSVOLDOMAIN-ADIPolicies"

# DFS Replication servisinin durumunu kontrol et
Get-Service DFSR | Select-Object Name, Status, StartType

# DFSR replikasyon sağlığını kontrol et
dfsrdiag ReplicationState

# SYSVOL replikasyon sorunlarını raporla
repadmin /showrepl

SYSVOL replikasyon sorunu çok sık karşılaşılan bir problemdir. Birden fazla DC olan ortamlarda, bir DC’de yapılan GPO değişikliği diğer DC’lere replike olmayabilir. Kullanıcı hangi DC’ye bağlandığına göre farklı GP davranışı görür. Bu durumu tespit etmek için:

# AD replikasyon durumunu kontrol et
repadmin /replsummary

# Belirli bir GPO'nun tüm DC'lerdeki versiyonlarını karşılaştır
# GPMC üzerinden yapılır ama PowerShell alternatifi:
Get-GPO -Name "GPO_Adi" | Select-Object DisplayName, Id, ModificationTime

# Tüm DC'lerde GP replikasyonunu test et
dcdiag /test:replications /v

Bir üretim ortamında yaşadığım durumu paylaşayım: 3 DC’li bir domain’de belirli bir şubedeki kullanıcılar için GPO uygulanmıyordu. gpresult /r çıktısı GPO’nun uygulandığını söylüyordu ama ayarlar geçerli değildi. Sorun, şube DC’sinin SYSVOL replikasyonunun 3 gün önce bozulmuş olmasıydı. Şubedeki tüm kullanıcılar bu DC’ye authenticate olduğundan eski GPO dosyalarını alıyorlardı. dfsrdiag ReplicationState komutu bize durumu net gösterdi.

Güvenlik Filtreleme ve WMI Filtre Sorunları

GPO’nun scope’u doğru ayarlanmış ama yine de uygulanmıyorsa, güvenlik filtreleme veya WMI filtrelerine bakmak gerekir.

Güvenlik Filtreleme Kontrolleri:

Bir GPO’nun uygulanması için hedef nesnenin (kullanıcı veya bilgisayar) GPO üzerinde en azından “Read” ve “Apply Group Policy” izinleri olması gerekir. GPMC’de GPO’nun Delegation sekmesinde veya Settings’te “Security Filtering” bölümünde bunu kontrol edebilirsiniz.

# PowerShell ile bir GPO'nun izinlerini listele
Get-GPPermission -Name "GPO_Adi" -All | 
Select-Object Trustee, Permission, Denied |
Format-Table -AutoSize

# Belirli bir grup veya kullanıcının izinlerini kontrol et
Get-GPPermission -Name "GPO_Adi" -TargetName "Domain Computers" -TargetType Group

WMI Filtre Sorunları:

WMI filtreleri GPO’nun belirli koşulları sağlayan makinelere uygulanmasını sağlar. Yanlış yazılmış bir WMI sorgusu, GPO’nun hiçbir makineye uygulanmamasına neden olabilir.

# WMI filtresini test et (makine üzerinde)
# Örnek: Windows 10 makineleri hedefleyen WMI sorgusu
$query = "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.0%' AND ProductType='1'"
Get-WmiObject -Query $query

# WMI servisinin durumunu kontrol et
Get-Service winmgmt | Select-Object Status

# WMI'ı yeniden başlat (sorun varsa)
Stop-Service winmgmt -Force
Start-Service winmgmt

# WMI repository'yi doğrula
winmgmt /verifyrepository

WMI filtre yazarken dikkat edilmesi gereken nokta: Sorgu herhangi bir hata döndürürse (syntax hatası, boş sonuç değil gerçek bir hata) GPO uygulanmaz ve Event Log’da bununla ilgili kayıt görürsünüz.

OU Bağlantısı ve Kalıtım Sorunları

GPO doğru OU’ya bağlı olmayabilir veya kalıtım engellenmiş olabilir. Bu da sık karşılaşılan bir senaryodur.

# Tüm GPO bağlantılarını listele
Get-GPO -All | ForEach-Object {
    $gpo = $_
    $links = Get-GPOReport -Guid $gpo.Id -ReportType XML
    Write-Output "$($gpo.DisplayName): $($gpo.GpoStatus)"
}

# Belirli bir OU'daki GPO bağlantılarını kontrol et
# RSAT PowerShell modülü gerektirir
Import-Module GroupPolicy
Get-GPInheritance -Target "OU=Bilgisayarlar,DC=domain,DC=com"

# Bir bilgisayarın hangi OU'da olduğunu bul
(Get-ADComputer -Identity "PC-ADI" -Properties DistinguishedName).DistinguishedName

# Bir kullanıcının hangi OU'da olduğunu bul
(Get-ADUser -Identity "kullanici" -Properties DistinguishedName).DistinguishedName

Get-GPInheritance komutunun çıktısında “Block Inheritance” ayarını kontrol edin. Eğer bir OU’da kalıtım engellenmiş ve GPO enforced (zorunlu) değilse, üst OU’lardan gelen GPO’lar bu OU’daki nesnelere uygulanmaz.

Gerçek dünya senaryosu: “Sadece IT departmanındaki bilgisayarlara uygula” diyerek oluşturdunuz bir GPO ve Domain Computers OU’suna bağladınız. Ama IT bilgisayarları farklı bir alt OU’daysa ve o alt OU’da Block Inheritance aktifse, politika uygulanmaz.

Loopback Processing Sorunları

Terminal Server veya VDI ortamlarında sıkça karşılaşılan bir durum: Kullanıcı politikasının makineye bağlı olarak değişmesini istiyorsunuz ama olmuyorsa, Loopback Processing yapılandırmasına bakın.

# Loopback processing durumunu kontrol et
# Registry'den kontrol:
Get-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyHistory" |
Select-Object *

# GP Loopback Test
# gpresult /r çıktısında "Loopback Processing" satırını ara
gpresult /r | Select-String "Loopback"

# Daha detaylı GPO işleme bilgisi
gpresult /v | Select-String -Pattern "Loopback|Mode"

Slow Link Tespiti ve Network Sorunları

Windows, ağ bağlantısı yavaş algılandığında bazı GP uzantılarını devre dışı bırakır. Özellikle Software Installation ve Folder Redirection uzantıları varsayılan olarak yavaş bağlantıda çalışmaz.

# Network bağlantı hızını test et
# DC'ye ping latency kontrolü
Test-NetConnection -ComputerName "DC-ADI" -Port 389

# DNS çözümlemesini doğrula
Resolve-DnsName -Name "DOMAIN-ADI" -Type A

# DC'ye bağlantı portlarını kontrol et
# LDAP: 389, LDAPS: 636, Kerberos: 88, RPC: 135
Test-NetConnection -ComputerName "DC-ADI" -Port 389
Test-NetConnection -ComputerName "DC-ADI" -Port 88
Test-NetConnection -ComputerName "DC-ADI" -Port 135

# Slow Link eşiğini kontrol et (varsayılan 500 kbps)
Get-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsSystem" |
Select-Object GroupPolicyMinTransferRate -ErrorAction SilentlyContinue

Slow link algılama eşiği, GP ayarlarında değiştirilebilir. Eğer VPN kullanan uzak kullanıcılarınız var ve GP uygulanmıyorsa, bu eşiği düşürmek veya belirli uzantıların slow link’te de çalışmasını sağlamak gerekebilir.

GP Önbelleğini Temizleme

Bazen GPO sorunları bozuk önbellekten kaynaklanır. Özellikle GPO rebind (GPO silip yeniden oluşturma) senaryolarında önbellekte eski GUID’ler kalabilir.

# GP önbellek klasörünü temizle (dikkatli ol, admin yetkisi gerekir)
# Önce servisi durdur
Stop-Service gpsvc -Force

# Önbellek klasörünü temizle
Remove-Item "C:WindowsSystem32GroupPolicy" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:WindowsSystem32GroupPolicyUsers" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:ProgramDataMicrosoftGroup PolicyHistory" -Recurse -Force -ErrorAction SilentlyContinue

# Servisi yeniden başlat
Start-Service gpsvc

# Güncelleme yap
gpupdate /force

Dikkat: Bu işlemi yapmadan önce mevcut GP yapılandırmasının yedeğini almanız önerilir. Üretim ortamında önce bir test makinesinde deneyin.

Kerberos ve Kimlik Doğrulama Sorunları

GPO uygulaması için makine veya kullanıcının başarıyla authenticate olması şarttır. Kerberos sorunları GP’yi doğrudan etkiler.

# Mevcut Kerberos biletlerini listele
klist

# Kerberos biletlerini temizle ve yenile
klist purge
gpupdate /force

# Bilgisayar hesabının biletini kontrol et
klist -li 0x3e7

# Zaman senkronizasyonunu kontrol et (Kerberos için kritik, max 5 dk fark)
w32tm /query /status
w32tm /query /peers

# DC ile zaman farkını kontrol et
w32tm /stripchart /computer:DC-ADI /samples:5 /dataonly

# Zaman servisini senkronize et
w32tm /resync /force

Kerberos’ta saat farkı 5 dakikayı geçerse kimlik doğrulama tamamen başarısız olur ve GPO uygulanamaz. Özellikle sanallaştırılmış ortamlarda VM’lerin zaman senkronizasyonu bozulabilir.

Sistematik Sorun Giderme Yaklaşımı

Tüm bu araçları bir araya getiren sistematik bir yaklaşım önemlidir. Sorunla karşılaştığınızda şu sırayla ilerleyin:

Adım 1 – Temel doğrulama:

  • Domain üyeliğini ve network bağlantısını kontrol et
  • gpupdate /force çalıştır ve hata alıp almadığına bak
  • gpresult /r ile hangi GPO’ların uygulandığını gör

Adım 2 – Filtreleme analizi:

  • Beklenen GPO “Applied” listesinde mi yoksa “Filtered” listesinde mi?
  • Filtreleniyorsa neden? Güvenlik filtreleme mi, WMI mi, GPO devre dışı mı?

Adım 3 – Kapsam kontrolü:

  • Nesne doğru OU’da mı?
  • GPO doğru OU’ya bağlı mı?
  • Block Inheritance var mı?

Adım 4 – Infrastructure kontrolü:

  • Event Log’larda 7016, 1030, 1006 gibi hatalar var mı?
  • SYSVOL ve NETLOGON erişimi sağlıklı mı?
  • DC replikasyonu düzgün çalışıyor mu?
  • Kerberos ve zaman senkronizasyonu sorunsuz mu?
# Hepsini bir arada özetleyen hızlı teşhis scripti
Write-Host "=== GP TESHIS RAPORU ===" -ForegroundColor Cyan
Write-Host "`n[Domain Bilgisi]"
(Get-WmiObject Win32_ComputerSystem) | Select-Object Name, Domain, PartOfDomain

Write-Host "`n[Son GP Hatalari]"
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 20 |
Where-Object {$_.Level -le 3} |
Select-Object TimeCreated, Id, Message |
Format-List

Write-Host "`n[Kerberos Biletleri]"
& klist

Write-Host "`n[SYSVOL Erisimi]"
$domain = (Get-WmiObject Win32_ComputerSystem).Domain
Test-Path "\$domainSYSVOL" | Write-Host

Write-Host "`n[Zaman Senkronizasyonu]"
w32tm /query /status | Select-String "Source|Last"

Sonuç

GPO sorunları can sıkıcıdır çünkü arka planda birbirini etkileyen onlarca mekanizma vardır. Ama sistematik bir yaklaşımla, bu yazıda ele aldığımız araçları ve kontrol noktalarını adım adım uygularsanız, sorunun kaynağını büyük olasılıkla bulursunuz.

En sık karşılaşılan sorunların özeti: Güvenlik filtrelemede yanlış grup seçimi, SYSVOL replikasyonu bozukluğu, Block Inheritance sürprizi, WMI filtrelerindeki syntax hataları ve Kerberos zaman senkronizasyonu problemleridir. Bunları önceden önlemek için ise GPO değişikliklerini test ortamında deneyin, büyük değişiklikleri belgelendirin ve DFSR sağlığını düzenli olarak izleyin.

gpresult /h ile ürettiğiniz HTML rapor, müşterilere veya üst yönetime sorunun kaynağını açıklamak için mükemmel bir araçtır. Renk kodlu, anlaşılır bir format sunar ve “neden uygulanmadı” sorusuna genellikle doğrudan yanıt verir.

Son olarak şunu da hatırlatmak isterim: GPO değişikliklerinden sonra mutlaka etkilenen makinelerin birinde gpupdate /force && gpresult /r yaparak doğrulama alışkanlığı edinin. Sorun oluştuktan sonra gidermek yerine önden doğrulamak, Pazartesi sabahı şikayetlerini önemli ölçüde azaltır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir