Active Directory sağlık kontrolü: kurulum sonrası doğrulama rehberi

Active Directory sağlık kontrolü, yeni kurulan bir etki alanı denetleyicisinin (domain controller, DC) DNS’e doğru kaydolduğunu, SYSVOL’ü paylaştığını, diğer DC’lerle çoğaltma (replication) yaptığını, FSMO rollerini bildiğini ve saatini doğru kaynaktan aldığını komut satırı araçlarıyla kanıtlamaktır. Bu kontroller DC’yi üretime almadan önce yapılır; aynı liste periyodik sağlık kontrolü olarak da kullanılabilir.

Bu yazının ilk sürümünü 2018’de kendi kurulum notlarımdan derlemiştim. O dönemde SYSVOL çoğaltması için hâlâ File Replication Service (FRS) olayları izleniyordu. Bugün FRS kullanımdan kalktı, PowerShell’in Active Directory modülü olgunlaştı; rehberi Windows Server 2016–2025 ortamlarına göre yeniledim.

Başlamadan önce: araçlar, yetki ve örnek adlar

Komutları DC üzerinde ya da Uzak Sunucu Yönetim Araçları (RSAT) kurulu bir yönetim makinesinde, yönetici olarak açılmış bir PowerShell penceresinde çalıştırın. dcdiag, yükseltilmiş (elevated) oturum ister. Örneklerde etki alanı corp.example.com, yeni DC DC02 olarak geçiyor; kendi adlarınızla değiştirin. PowerShell’e yeniyseniz önce PowerShell’e giriş yazısına göz atabilirsiniz.

Adım 1: DC nesnesi, site ve alt ağ doğru mu?

Eski yöntem hâlâ geçerli: dssite.msc ile Active Directory Sites and Services konsolunu açın, Sites altında DC’nin sitesini, ardından Servers altında DC’yi bulun. DC’nin altında NTDS Settings nesnesi görünmelidir; yoksa yükseltme yarım kalmıştır.

İkinci kontrol IP alt ağıdır. DC’nin IP adresi, bağlı olduğu sitenin alt ağ (subnet) tanımı içinde olmalıdır. Aksi hâlde istemciler uzak sitedeki DC’ye gider, oturum açma yavaşlar. Aynı bilgiyi PowerShell ile tek ekranda alabilirsiniz:

Import-Module ActiveDirectory

Get-ADDomainController -Filter * |
    Select-Object Name, Site, IPv4Address, IsGlobalCatalog, IsReadOnly, OperatingSystem |
    Format-Table -AutoSize

Get-ADReplicationSubnet -Filter * | Select-Object Name, Site

# DC'nin kendini hangi sitede gördüğü
nltest /dsgetsite

Adım 2: DNS kaydı ve SRV kayıtları tamam mı?

İstemciler DC’yi DNS’teki hizmet (SRV) kayıtları üzerinden bulur. dcdiag’in DNS testi varsayılan çalıştırmada yer almaz; ayrıca istemeniz gerekir. Özet tablosunda her sütunun PASS olması beklenir.

dcdiag /test:dns /v /s:DC02

$domain = 'corp.example.com'
$forestRoot = (Get-ADForest).RootDomain
Resolve-DnsName -Type SRV "_ldap._tcp.dc._msdcs.$domain"
Resolve-DnsName -Type SRV "_kerberos._tcp.$domain"
Resolve-DnsName -Type SRV "_ldap._tcp.pdc._msdcs.$domain"
Resolve-DnsName -Type SRV "_gc._tcp.$forestRoot"

Yeni DC her listede görünmelidir. Global katalog (GC) ise _gc._tcp kaydı orman kök etki alanı bölgesinde bulunmalıdır. Eski notumda bu kontrolü Infoblox arayüzünden yapıyordum; DNS üçüncü parti bir üründe tutuluyorsa aynı kaydı o ürünün _tcp kabında arayın. Kayıt eksikse DC’de nltest /dsregdns komutu DC’ye özgü DNS kayıtlarını yeniden kaydeder.

DC’nin ağ kartında DNS sunucusu olarak yalnızca AD ile tümleşik DNS sunucuları yazılmalıdır. İnternet çözümlemesi için DNS sunucusunda yönlendirici (forwarder) kullanın; ağ kartına ISS’nin DNS adresini eklemek SRV kayıt sorunlarının klasik nedenidir.

Adım 3: SYSVOL ve NETLOGON paylaşılıyor mu?

Grup ilkeleri (GPO) ve oturum açma betikleri SYSVOL’den okunur. Kontrol sırası şöyle:

1. net share çıktısında SYSVOL ve NETLOGON paylaşımları olmalıdır.
2. dcdiag /test:netlogons komutu, çalıştıran kullanıcının iki paylaşımı okuyabildiğini doğrular. Çıktıda DC02 passed test NetLogons satırını arayın.
3. dcdiag /test:sysvolcheck, Netlogon’un SysvolReady kayıt defteri değerinin 1 olduğunu kontrol eder.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name SysvolReady

Get-WinEvent -FilterHashtable @{ LogName = 'DFS Replication'; Id = 4602, 4604, 4614 } -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message

2018 sürümünde FRS olaylarını (13508, 13509, 13516) izliyorduk. Bugün SYSVOL, DFS Replication (DFSR) ile çoğaltılır ve bakılacak olaylar farklıdır. Microsoft’un sorun giderme makalesine göre 4614, DFSR’nin ilk çoğaltmayı beklediğini; 4604, SYSVOL’ün ilk eşitlemeden sonra başlatıldığını; 4602 ise SYSVOL’ün birincil üye olarak başlatıldığını gösterir. 4614 var ama 4604 yoksa yeni DC hâlâ veri bekliyordur.

FRS hâlâ kullanılıyor mu?

Eski etki alanlarında SYSVOL hâlâ FRS ile çoğaltılıyor olabilir. Windows Server 2019 ve sonrası bir sunucu böyle bir etki alanına DC olarak yükseltilemez; kurulum sihirbazı DFSMIG ile geçiş yapmanızı ister. Durumu şöyle kontrol edin:

dfsrmig /getglobalstate      # PDC emülatöründe çalıştırın
dfsrmig /getmigrationstate

Geçiş tamamlanmışsa genel durum Eliminated olmalı ve tüm DC’ler bu duruma ulaşmış görünmelidir. Geçiş Start (0), Prepared (1), Redirected (2) ve Eliminated (3) aşamalarından geçer. Eliminated durumuna geçiş geri alınamaz; bu adımı çoğaltmanın sağlıklı olduğundan emin olduktan sonra atın.

Adım 4: Diğer DC’lerle iletişim ve DC bulucu

nltest /dclist:corp.example.com
nltest /dsgetdc:corp.example.com
nltest /server:DC02 /dsgetdc:corp.example.com /gc

İlk komutun son satırı The command completed successfully olmalıdır. /dsgetdc çıktısındaki Flags satırı, bulunan DC’nin yeteneklerini gösterir: GC, PDC, KDC, TIMESERV, WRITABLE gibi. Yeni DC’yi global katalog yaptıysanız üçüncü komutta Flags satırında GC görünmesi, GC’nin hazır olduğunu gösterir.

Aynı bilgi için eski notumda LDP aracını kullanıyordum: 389 numaralı porta bağlanıp RootDSE’deki isGlobalCatalogReady özniteliğinin TRUE olduğunu kontrol etmek. PowerShell karşılığı daha pratik:

Get-ADRootDSE -Server DC02 | Select-Object isGlobalCatalogReady

Adım 5: Çoğaltma sağlıklı mı?

repadmin /replsummary
repadmin /showrepl DC02
repadmin /showrepl * /csv > C:\Temp\repl.csv
dcdiag /test:replications /s:DC02

/replsummary tablosunda fails sütunu sıfır olmalıdır. largest delta değeri, son başarılı çoğaltmadan bu yana geçen süredir; site bağlantısı zamanlamanızla uyumlu değilse inceleyin. dcdiag’in Replications testi, gecikme 12 saati aştığında da uyarı verir. /showrepl her adlandırma bağlamı (naming context) için son denemenin sonucunu gösterir.

PowerShell tarafında aynı tabloyu nesne olarak alıp filtreleyebilirsiniz:

Get-ADReplicationPartnerMetadata -Target 'corp.example.com' -Scope Domain |
    Select-Object Server, Partner, LastReplicationSuccess, LastReplicationResult, ConsecutiveReplicationFailures |
    Sort-Object ConsecutiveReplicationFailures -Descending |
    Format-Table -AutoSize

Get-ADReplicationFailure -Target DC02

LastReplicationResult sıfırdan farklıysa ya da ConsecutiveReplicationFailures artıyorsa o ortaklık sorunludur.

Adım 6: FSMO rolleri doğru yerde mi?

Ormanda beş işlem yöneticisi (FSMO) rolü vardır. Şema yöneticisi (Schema Master) ve etki alanı adlandırma yöneticisi (Domain Naming Master) orman genelinde tektir. RID yöneticisi, PDC emülatörü ve altyapı yöneticisi (Infrastructure Master) her etki alanında birer tanedir.

netdom query fsmo

Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

dcdiag /test:knowsofroleholders /s:DC02
dcdiag /test:ridmanager /s:DC02

Eski sürümdeki /test:knowsofroleholders kontrolü hâlâ geçerli; bu test DC’nin beş rolü kimin taşıdığını bildiğini doğrular. RidManager testi, RID yöneticisine erişilebildiğini ve RID havuzunun geçerli olduğunu kontrol eder. RID yöneticisine ulaşılamazsa yeni kullanıcı, grup ve bilgisayar oluşturmak zamanla imkânsız hâle gelir.

Adım 7: Zaman eşitlemesi (w32tm)

Kerberos, istemci ile DC arasındaki saat farkına duyarlıdır; dcdiag belgesi varsayılan toleransı 300 saniye (5 dakika) olarak verir. Etki alanı üyeleri saati DC’lerden, DC’ler de PDC emülatöründen alır. Hiyerarşinin tepesindeki orman kök PDC emülatörü ise dış kaynağa bağlanmalıdır.

# Yalnızca orman kök etki alanının PDC emülatöründe:
w32tm /config /manualpeerlist:"ntp1.example.com,0x8 ntp2.example.com,0x8" /syncfromflags:manual /reliable:yes /update

# Diğer tüm DC'lerde:
w32tm /config /syncfromflags:domhier /update
w32tm /resync

# Kontrol:
w32tm /query /source
w32tm /query /status
w32tm /monitor

/query /source çıktısı PDC emülatöründe dış NTP sunucusunu, diğer DC’lerde bir DC adını göstermelidir. Local CMOS Clock görüyorsanız eşitleme çalışmıyordur. Sanal DC’lerde hipervizörün saat eşitlemesi w32time ile çakışabilir; hipervizör üreticinizin DC’ler için önerdiği ayarı uygulayın. Ağ cihazlarınızın saatini de aynı kaynağa bağlamak olay günlüklerini karşılaştırmayı kolaylaştırır; switch tarafı için HP/Aruba switch temel yapılandırma yazısındaki SNTP bölümüne bakabilirsiniz.

Adım 8: Olay günlükleri

dcdiag’in SystemLog, KccEvent ve DFSREvent testleri son saatlerdeki hata ve uyarıları tarar. Daha geniş bir bakış için dört günlüğü birlikte süzmek işe yarar:

$since = (Get-Date).AddHours(-24)
'Directory Service', 'DFS Replication', 'DNS Server', 'System' | ForEach-Object {
    Get-WinEvent -FilterHashtable @{ LogName = $_; Level = 1, 2, 3; StartTime = $since } -ErrorAction SilentlyContinue
} | Sort-Object TimeCreated -Descending |
    Select-Object TimeCreated, LogName, Id, LevelDisplayName, ProviderName |
    Format-Table -AutoSize

Level 1, 2 ve 3 sırasıyla kritik, hata ve uyarı düzeyleridir. Kurulumdan hemen sonra birkaç geçici uyarı normaldir; aynı olay kimliğinin tekrar etmesi normal değildir.

Adım 9: Güvenlik ve denetim ayarları

Eski notumda bu başlık “sonra belirlenecek” diye kalmıştı. Bugünkü önerim: DC’lere uygulanan Default Domain Controllers Policy ilkesini değiştirmek yerine ayrı bir GPO ile Microsoft güvenlik temel çizgisini (security baseline) uygulamak ve gelişmiş denetim ilkesini (advanced audit policy) etkinleştirmek. Etkin denetim ayarlarını auditpol /get /category:* ile görebilirsiniz. Olayları merkezi bir günlük sistemine göndermiyorsanız DC’nin yerel güvenlik günlüğü kısa sürede dolar.

Tek raporda toplamak: dcdiag /v

Tüm varsayılan testleri ayrıntılı çıktıyla tek dosyaya almak için dcdiag /v /s:DC02 /f:C:\Temp\dcdiag-DC02.txt yeterlidir. Ormandaki tüm DC’lerde yalnızca hataları görmek için dcdiag /e /q kullanın. Büyük ortamlarda /e ile DNS testleri uzun sürebilir.

Kontrol listesi

Kontrol	Komut	Beklenen sonuç
NTDS Settings nesnesi	dssite.msc	DC altında mevcut
Site ve alt ağ	Get-ADDomainController, nltest /dsgetsite	DC doğru sitede
DNS ve SRV kayıtları	dcdiag /test:dns, Resolve-DnsName -Type SRV	Tüm testler PASS, DC listelerde
SYSVOL/NETLOGON	net share, dcdiag /test:netlogons	İki paylaşım var, test geçti
SYSVOL hazır	dcdiag /test:sysvolcheck	SysvolReady = 1
DFSR geçişi	dfsrmig /getmigrationstate	Tüm DC’ler Eliminated
DC bulucu	nltest /dsgetdc:<etki alanı>	Beklenen bayraklar (GC, KDC, WRITABLE)
GC hazır	Get-ADRootDSE	isGlobalCatalogReady = TRUE
Çoğaltma	repadmin /replsummary	fails = 0
FSMO	netdom query fsmo	Roller planlanan DC’lerde
Zaman	w32tm /query /source	PDC: dış NTP, diğerleri: DC
Olay günlükleri	Get-WinEvent	Tekrarlayan hata yok

Sonuç

Bir DC’nin “kuruldu” olması ile “sağlıklı” olması aynı şey değil. Sahada en sık gördüğüm hata, yükseltme sihirbazı başarıyla bittiği için DNS ve SYSVOL kontrolünün atlanması; sorun haftalar sonra GPO’ların bazı şubelerde uygulanmaması olarak ortaya çıkıyor. Bu listeyi her yeni DC’de ve ayda bir periyodik olarak çalıştırın, çıktıları saklayın. Yerel hesap ve grup işlemlerini de betikleştirmek isterseniz VBScript’ten PowerShell’e yerel kullanıcı ve grup yönetimi yazısı iyi bir devam noktası.