Group Policy Uygulanmıyor: gpresult ve Olay Günlükleriyle Teşhis

“GPO gelmiyor” şikâyeti geldiğinde ilk refleks gpupdate /force çalıştırıp beklemektir. Çoğu zaman hiçbir şey değişmez, çünkü neden yanlış OU, bir filtre, öncelik çakışması, ulaşılamayan SYSVOL ya da istemcinin GPO’yu hiç işlememesidir. Aşağıdaki sıra, bu olasılıkları en ucuz kontrolden en pahalısına doğru eler; her adımda hangi aracın neyi gösterdiğini ve hangi olay kaydının neye işaret ettiğini yazdık.

İşleme sırası ve öncelik

Teşhise başlamadan kazananın nasıl belirlendiğini netleştirin. Group Policy şu sırayla işlenir: yerel ilke, site, etki alanı, OU (üst OU’dan alt OU’ya). Aynı ayar birden fazla GPO’da tanımlıysa son işlenen kazanır; yani nesneye en yakın OU’daki GPO genellikle önde gelir.

• Bağlantı sırası: Aynı kapsayıcıya bağlı GPO’larda Link Order 1 en yüksek önceliğe sahiptir; en son o işlenir.
• Enforced: Zorlanmış bağlantı, alt OU’lardaki çakışan ayarlara karşı kazanır ve Block Inheritance tarafından kesilemez.
• Block Inheritance: OU’ya üstten gelen zorlanmamış GPO’ları keser. “Domain politikası bize gelmiyor” şikâyetinin sık nedenidir; çoğu zaman yıllar önce biri açmış ve unutulmuştur.
• Loopback: Bilgisayar GPO’sunda açılan bu ayar, kullanıcı ayarlarını kullanıcının değil bilgisayarın OU’suna göre belirler. Merge kipinde iki liste birleşir ve bilgisayar tarafı kazanır; Replace kipinde kullanıcının kendi OU’sundaki kullanıcı ayarları hiç işlenmez.

Arka plan yenilemesi varsayılan olarak üye bilgisayarlarda 90 dakika artı 0–30 dakika rastgele gecikme, DC’lerde 5 dakikadır. Güvenlik ayarları değişiklik olmasa da 16 saatte bir yeniden uygulanır. Yani “ayarı az önce değiştirdim, gelmedi” çoğu zaman sadece beklemedir.

İlk kontrol: kapsam ve bağlantı

Sorunların önemli kısmı sistem altyapısının derinlerine inmeden ilk adımda çözülür. GPMC’de GPO’yu seçin, Scope sekmesine ve ilgili nesneye bakın:

• Bilgisayar veya kullanıcı gerçekten GPO’nun bağlı olduğu OU’nun altında mı? Varsayılan CN=Computers ve CN=Users kapsayıcıdır, OU değildir; bunlara GPO bağlanamaz. Sahada en sık gördüğümüz hata budur: etki alanına yeni alınan makine Computers kapsayıcısında kalır ve hiçbir OU GPO’su ona ulaşmaz. redircmp ile varsayılan konumu bir OU’ya yönlendirin.
• Bağlantı etkin mi (Link Enabled)? Kapalı bağlantı GPO’yu tamamen devre dışı bırakır.
• GPO Status “User configuration settings disabled” veya “Computer configuration settings disabled” mı? Devre dışı yarıda tanımlı ayar yok sayılır.
• Ayar doğru yarıda mı? Kullanıcı yapılandırmasındaki bir ayar, bilgisayar nesnelerinin bulunduğu OU’ya bağlanırsa loopback olmadan kullanıcıya ulaşmaz.

Güvenlik ve WMI filtreleri

GPO’nun uygulanması için hedef nesnenin GPO üzerinde Read ve Apply group policy izinleri olmalıdır. 2016’daki MS16-072 güncellemesinden sonra kullanıcı GPO’ları bilgisayar hesabının güvenlik bağlamında okunur. Security Filtering’den Authenticated Users’ı kaldırıp yalnızca bir kullanıcı grubu eklerseniz, Delegation sekmesinde Domain Computers’a (veya Authenticated Users’a) Read izni vermeniz gerekir. Vermezseniz GPO sessizce atlanır. gpresult raporunda erişim reddi olarak görünür.

WMI filtreleri istemcide değerlendirilir; sonuç yanlışsa GPO uygulanmaz. Aşağıdaki filtre yalnızca istemci işletim sistemlerini seçer (ProductType 1 istemci, 2 DC, 3 üye sunucu):

SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1"

Yanlış ad alanı (namespace), yazım hatası veya istemcide bozuk WMI deposu filtreyi her seferinde yanlış döndürür. Filtreyi doğrudan sorunlu makinede test edin:

Get-CimInstance -Query 'SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1"'

Sonuç boşsa filtre o makinede yanlış değerlendiriliyor. Group Policy Preferences kullanıyorsanız öğe düzeyinde hedefleme (item-level targeting) ayrı bir filtre katmanıdır: GPO uygulanmış görünür ama tercih öğesi hedefleme koşuluna takılmıştır. Raporda yeşil görünen GPO, ayarın geldiği anlamına gelmez.

gpresult ve RSoP ile analiz

Ortaya çıkan ilke kümesini (RSoP) görmenin temel aracı gpresult’tır; tüm parametreler gpresult komut başvurusunda listelenir. Bilgisayar verilerini görmek için komut istemini yönetici olarak açın:

gpresult /r /scope computer
gpresult /h C:\Temp\gp-rapor.html /f
gpresult /s PC-0412 /user CONTOSO\ayse.k /h C:\Temp\pc0412.html

HTML raporunda üç bölüme bakın: Applied GPOs (uygulananlar), Denied GPOs (reddedilenler ve nedeni: “Empty”, “Access Denied (Security Filtering)”, “False WMI Filter”, “Disabled Link”) ve Component Status (her istemci tarafı uzantının son çalışma sonucu). Ayarın hangi GPO’dan geldiğini gösteren Winning GPO sütunu öncelik çakışmasını doğrudan gösterir. Tartışmayı bitiren sütun budur.

Uzaktaki makine için aynı raporu PowerShell ile alabilirsiniz:

Get-GPResultantSetOfPolicy -Computer PC-0412 -User CONTOSO\ayse.k `
  -ReportType Html -Path C:\Temp\rsop-pc0412.html

Invoke-GPUpdate -Computer PC-0412 -Force -RandomDelayInMinutes 0

Değişikliğin henüz yayılmadığından şüpheleniyorsanız GPMC’deki Group Policy Modeling sihirbazıyla “bu kullanıcı bu bilgisayarda oturum açsaydı ne olurdu” senaryosunu çalıştırın. Modeling DC üzerinde hesaplanır; gerçek sonuçla (Results) farklıysa sorun istemci tarafındadır.

GroupPolicy Operational günlüğü

gpresult sonucu gösterir, olay günlüğü nedeni. İlgili günlük Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational altındadır. Her işleme döngüsü aynı Activity ID ile işaretlenir; bir döngüye ait tüm kayıtları bu kimlikle süzüp birlikte okuyun.

Hatalar ayrıca System günlüğüne GroupPolicy kaynağıyla düşer. Sahada en sık karşılaştıklarımız: 1058 (gpt.ini dosyasına erişilemedi; genellikle SYSVOL veya DNS), 1030 (GPO listesi sorgulanamadı), 1129 (DC’ye ağ bağlantısı olmadığı için işleme başarısız) ve 1085 (belirli bir istemci tarafı uzantısı başarısız). Son bir saatin hatalarını toplu görmek için:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'; Level=2,3; StartTime=(Get-Date).AddHours(-1)} |
  Select-Object TimeCreated, Id, Message | Format-List

Günlük yetmiyorsa ayrıntılı hata ayıklama kaydını açın: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics altında GPSvcDebugLevel adlı DWORD değerini 0x30002 yapın; çıktı %windir%\debug\usermode\gpsvc.log dosyasına yazılır. İş bitince değeri kaldırın; açık unutulan debug kaydı diski doldurur.

SYSVOL ve replikasyon kaynaklı sorunlar

Bir GPO iki parçadan oluşur: Active Directory’deki Group Policy Container (GPC) ve SYSVOL’deki Group Policy Template (GPT). İkisinin sürüm numarası DC’ler arasında farklıysa istemci, bağlandığı DC’ye göre eski veya eksik ayar alır. Tipik belirti: sorun yalnızca belirli bir sitede ya da belirli bir DC’ye bağlanan istemcilerde görülür. Aynı GPO, iki ofiste iki farklı davranır.

• GPMC’de etki alanını seçip Status sekmesindeki Detect Now ile tüm DC’lerde GPC/GPT tutarlılığını karşılaştırın.
• SYSVOL replikasyon mekanizmasını doğrulayın: dfsrmig /getglobalstate çıktısı “Eliminated” olmalı. Hâlâ FRS kullanılıyorsa bu, ayrıca kapatılması gereken bir geçiş borcudur.
• DFSR biriktirmesini (backlog) kontrol edin; DFS Replication günlüğünde 2213 (kirli kapanma sonrası replikasyonun durması) veya 4012 (uzun süre bağlantısız kalma) kayıtlarını arayın.

Get-DfsrBacklog -GroupName "Domain System Volume" -FolderName "SYSVOL Share" `
  -SourceComputerName DC01 -DestinationComputerName DC02 -Verbose
repadmin /replsummary

Etki alanı denetleyicilerinin genel sağlığını periyodik bakım kapsamında izlemek için Active Directory sağlık kontrolü yazısındaki adımları kullanın; bu sorunları kullanıcı aramadan önce yakalarlar.

Yavaş bağlantı ve ön plan işlemesi

İstemci DC ile arasındaki bağlantıyı varsayılan 500 kbps eşiğinin altında ölçerse yavaş bağlantı kabul eder. Kayıt defteri tabanlı ilkeler ve güvenlik ayarları yine uygulanır; yazılım yükleme, klasör yeniden yönlendirme ve bazı betik uzantıları atlanabilir. VPN kullanıcılarında “sürücü eşlemesi bazen gelmiyor” şikâyetinin nedeni çoğu zaman budur. 5314 olayı ölçülen hızı gösterir.

Bazı uzantılar yalnızca açılış ve oturum açmada, yani ön planda çalışır. Windows hızlı oturum açma için ağı beklemeden masaüstünü açar; bu uzantıların ilk girişte uygulanmasını istiyorsanız Always wait for the network at computer startup and logon ayarını etkinleştirin. Oturum açma süresi uzar. Bu yüzden ayarı yalnızca gereken bilgisayar gruplarına verin.

Belirtiden nedene: kontrol tablosu

Tabloyu yukarıdan aşağı izlemek, gpupdate’i tekrar tekrar çalıştırıp beklemekten hızlı sonuç verir. Aynı tür GPO sorunu sürekli tekrarlıyorsa mesele tek bir ayar değil, OU tasarımı ve GPO sayısıdır; Group Policy yapısının düzenli bakımını sunucu ve bulut yönetimi hizmetimiz içinde ele alıyoruz. Sorun bir DC değişiminden sonra başladıysa domain controller değişimi ve FSMO taşıma yazısındaki kontrollere de bakın.

Sık sorulan sorular

gpupdate /force çalıştırmak sorunu çözmezse ne yapmalıyım?

gpupdate yalnızca işlemeyi yeniden tetikler; GPO kapsam dışındaysa veya filtreye takılıyorsa sonuç değişmez. Önce gpresult /h raporunda GPO’nun uygulananlar mı yoksa reddedilenler listesinde mi olduğuna bakın, sonra GroupPolicy Operational günlüğündeki hata kayıtlarını okuyun.

Bilgisayar ayarları gpresult raporunda neden görünmüyor?

gpresult yönetici yetkisiyle çalışmadığında bilgisayar kapsamındaki verileri gösteremez. Komut istemini yönetici olarak açın veya /scope computer parametresiyle raporu yeniden alın.

Bazı ayarlar neden yalnızca yeniden başlatma ya da oturum açma sırasında uygulanıyor?

Yazılım yükleme ve klasör yeniden yönlendirme gibi uzantılar arka plan yenilemesinde çalışmaz; ön plan işlemesi ister. Bu ayarlar bir sonraki açılışta veya oturum açmada uygulanır; hızlı oturum açma iyileştirmesi yüzünden bazen iki açılış gerekir.

Security filtering’den Authenticated Users’ı kaldırınca GPO neden çalışmadı?

GPO’yu okuyabilmek için bilgisayar hesabının da Read izni olmalıdır. Authenticated Users’ı kaldırdıysanız Delegation sekmesinden Domain Computers grubuna yalnızca Read izni verin; Apply izni kullanıcı grubunda kalabilir.