Active Directory sağlık kontrolü: dcdiag ve repadmin çıktısı

Belirti

Active Directory çoğaltması sessiz bozulur. Kullanıcının fark ettiği şey "AD bozuk" değil, şunlardan biridir:

• Oturum açma yavaş veya tutarsız. Aynı kullanıcı bir sitede hemen, diğerinde bekleyerek ya da "parola yanlış" hatasıyla oturum açıyor.
• Parola değişikliği bir DC'de görünmüyor. Kullanıcı İstanbul'da parolasını değiştirdi, Ankara'daki DC eski parolayı kabul ediyor, yenisini reddediyor.
• GPO uygulanmıyor. gpresult /r eski sürümü gösteriyor; GPO'nun AD tarafı bir DC'de yeni, SYSVOL tarafı eski kalmış.
• Yeni hesap bazı DC'lerde yok. Yardım masasının açtığı kullanıcı uzak sitedeki uygulama sunucusunda "bulunamadı" hatası veriyor.
• Olay günlüğünde uyarılar. Directory Service günlüğünde KCC kaynaklı 1311 (topoloji sorunu) ve 1865 (bazı sitelere ulaşılamıyor), 2042 (bu DC çok uzun süredir çoğaltmadı), 2087/2088 (DNS çözümleme hatası), 1988 (lingering nesne); DFS Replication günlüğünde 2213 (kirli kapanma) ve 4012 (içerik tazeliği sınırı).

En tehlikelisi hiç belirti vermeyenidir. Microsoft'un USN rollback belgesine göre eski bir disk imajından açılan DC'nin ortakları kendini güncel sanır ve repadmin hiçbir hata göstermez; tek iz olay 2095 ve kayıt defterindeki Dsa Not Writable değeridir.

Neden

AD çok yöneticili (multi-master) çoğaltma kullanır: yazılabilir her DC değişiklik kabul eder ve bunu ortaklarına iletir. Site içindeki bağlantı nesnelerini Bilgi Tutarlılık Denetleyicisi (KCC, Knowledge Consistency Checker) kendisi kurar; siteler arası bağlantıları her sitedeki ISTG, köprübaşı (bridgehead) DC'ler arasında, site bağlantısının maliyetine ve zamanlamasına göre oluşturur. Bir bağlantı koptuğunda diğer DC'ler çalışmaya devam eder, bu yüzden sorun haftalarca fark edilmeyebilir.

Microsoft'un "Diagnose AD replication failures" makalesi çoğaltmanın bağımlılıklarını sırayla sayar: ağ bağlantısı ve portlar, ortağın adını IP'ye çeviren DNS, kimlik doğrulama ve yetkilendirme, Kerberos için 5 dakika içinde saat doğruluğu, dizin veritabanı, çoğaltma topolojisi ve çoğaltma motoru. Üstteki katmandaki hata çoğu zaman alttaki katmandan gelir: 1722 görüp RPC'yi suçlamadan önce DNS'e bakmak gerekir.

İki kavram hatanın ciddiyetini belirler. Tombstone ömrü (tombstone lifetime): silinen nesne bu süre boyunca "mezar taşı" olarak tutulur ki silme bilgisi tüm DC'lere ulaşsın. Windows Server 2003 SP1 ve sonrasıyla kurulan ormanlarda varsayılan 180 gündür. Bu süreden uzun çoğaltmayan DC, silinmiş nesneleri geri getirebilir. Strict replication consistency ise yeni ormanlarda varsayılan açıktır ve böyle bir DC'nin gönderdiği "yaşayan" eski nesneleri reddeder; 8606 hatası bu korumanın çalıştığını gösterir.

Çözüm

1. repadmin /replsummary ile genel tabloyu okuyun

   Komut ormandaki tüm DC'lerden özet toplar; ekranda her DC için bir nokta görürsünüz. Microsoft'un örneği kaynak ve hedef tablolarını birlikte, en eski başarılı çoğaltmaya göre sıralı verir:

   repadmin /replsummary * /bysrc /bydest /sort:delta

   Aşağıdaki çıktı kurgusal example.com ormanından, Şekil 1'deki durumu gösteren örnek çıktıdır:

   Replication Summary Start Time: 2026-10-29 09:12:44
   
   Beginning data collection for replication summary, this may take awhile:
     .....
   
   Source DSA          largest delta    fails/total %%   error
    ANK-DC01          2d.03h:31m:24s    5 /  10   50  (1722) The RPC server is unavailable.
    ANK-DC02                 07m:12s    0 /   5    0
    IST-DC01          2d.03h:29m:51s    5 /  10   50  (1722) The RPC server is unavailable.
    IST-DC02                 11m:40s    0 /   5    0
   
   Destination DSA     largest delta    fails/total %%   error
    ANK-DC01          2d.03h:29m:51s    5 /  10   50  (1722) The RPC server is unavailable.
    ANK-DC02                 09m:03s    0 /   5    0
    IST-DC01          2d.03h:31m:24s    5 /  10   50  (1722) The RPC server is unavailable.
    IST-DC02                 06m:55s    0 /   5    0

   Sütunlar: Source DSA tablosu o DC'den çıkan, Destination DSA tablosu o DC'ye giren çoğaltmayı özetler. largest delta, o DC'nin en geride kalan bölümünde son başarılı çoğaltmadan bu yana geçen süredir. fails/total başarısız ortak-bölüm bağlantısının toplama oranı, %% yüzdesi, error ise çoğaltmayı engelleyen son koddur. Örnekte iki köprübaşı birbirine iki gündür ulaşamıyor; site içi bağlantılar sağlıklı. Büyük ormanda yalnızca sorunlu satırları görmek için /errorsonly ekleyin.

2. repadmin /showrepl ile ortağı ve hata kodunu bulun

   Hata hangi DC'de görünüyorsa onun gelen (inbound) komşularını listeleyin. Her bölüm (domain, Configuration, Schema, DomainDnsZones, ForestDnsZones) için ayrı satır gelir:

   repadmin /showrepl IST-DC01

   Istanbul\IST-DC01
   DSA Options: IS_GC
   Site Options: (none)
   DSA object GUID: 5d0c2b1e-0000-0000-0000-000000000000
   DSA invocationID: 5d0c2b1e-0000-0000-0000-000000000000
   
   ==== INBOUND NEIGHBORS ======================================
   
   DC=example,DC=com
       Ankara\ANK-DC01 via RPC
           DSA object GUID: 3f2a9c47-0000-0000-0000-000000000000
           Last attempt @ 2026-10-29 08:55:02 failed, result 1722 (0x6ba):
               The RPC server is unavailable.
           418 consecutive failure(s).
           Last success @ 2026-10-27 05:41:20.

   Üç satır önemli: result sonrasındaki kod, consecutive failure(s) sayısı ve Last success tarihi. Son başarı tarihi tombstone ömrünün yarısına yaklaşıyorsa sorun acildir. Tüm ormanı tek tabloda görmek için Microsoft'un önerdiği PowerShell satırı:

   repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView

   Hedef DC'nin işlemekte zorlandığı bekleyen istekleri görmek için repadmin /queue IST-DC01 kullanın; kuyruk sürekli büyüyorsa DC kaynak veya disk sorunu yaşıyordur.

3. dcdiag ile DC bazında tarama yapın

   Önce tüm ormanı yalnızca hata basacak şekilde tarayın. Çıktı boşsa test edilen her şey geçti demektir:

   dcdiag /e /q

   Hata çıkan DC'yi ayrıntılı ve dosyaya yazarak inceleyin. /c varsayılan olmayan testleri (Topology, CutoffServers, OutboundSecureChannels) de çalıştırır; /q ve /v sözdiziminde birbirinin alternatifidir, aynı satıra yazmayın:

   dcdiag /s:IST-DC01 /c /v /f:C:\Raporlar\dcdiag-IST-DC01.txt

   Microsoft'un test listesine göre en çok iş gören testler: Connectivity (DNS kaydı, LDAP ve RPC bağlanabilirliği; atlanamaz), Advertising (DC kendini doğru rollerle duyuruyor mu), Replications (son deneme hatası ve 12 saati aşan gecikme), KccEvent (son 15 dakikadaki KCC hataları), DFSREvent (son 24 saatteki DFSR uyarıları), SystemLog (son 60 dakika), MachineAccount, NCSecDesc, NetLogons, ObjectsReplicated, RidManager, Services ve VerifyReferences. Dahili ağda ICMP engelliyse dcdiag beklendiği gibi çalışmaz; Microsoft bunu belgenin başında açıkça uyarıyor.

4. DNS testini ayrıca çalıştırın

   DNS testi varsayılan çalışmaz; parametresiz /test:dns tüm DNS alt testlerini (/DnsAll) yapar ve sonda bir özet tablo basar (Auth, Basc, Forw, Del, Dyn, RReg, Ext):

   dcdiag /test:dns /e /v /f:C:\Raporlar\dcdiag-dns.txt

   8524 görüyorsanız hedef DC, kaynak DC'yi <DSA GUID>._msdcs.<orman kökü> CNAME kaydıyla çözemiyor demektir. GUID'i showrepl çıktısındaki "DSA object GUID" satırından alıp hedef DC'den sorgulayın:

   Resolve-DnsName -Name '3f2a9c47-0000-0000-0000-000000000000._msdcs.example.com' -Type CNAME

   Kayıt yoksa kaynak DC'de Netlogon hizmetini yeniden başlatmak kayıtları yeniden yazar. Microsoft'un 8524 makalesine göre sık nedenlerden biri de artık var olmayan bir DC'nin NTDS Settings nesnesinin AD'de kalmasıdır; bu durumda çözüm meta veri temizliğidir. DNS tarafının ayrıntılı teşhisi için nslookup, dig ve Resolve-DnsName ile DNS sorun giderme yazısına bakın.

5. SYSVOL ve DFSR durumunu kontrol edin

   GPO sorunlarının yarısı AD'de değil SYSVOL'dadır. Önce SYSVOL'un DFSR ile çoğaltıldığını PDC emülatöründe doğrulayın; beklenen çıktı Eliminated durumudur. Microsoft'a göre Windows Server 2019'dan itibaren yeni DC yükseltmek için SYSVOL'un DFSR ile çoğaltılması gerekiyor:

   dfsrmig /getglobalstate

   Ardından her DC'de SYSVOL replicated folder durumuna bakın. Microsoft'un belgesindeki değerler: 0 başlatılmadı, 2 ilk eşitleme, 4 normal, 5 hata:

   Get-CimInstance -Namespace 'root\microsoftdfs' -ClassName DfsrReplicatedFolderInfo -Filter "ReplicatedFolderName='SYSVOL share'" |
       Select-Object ReplicationGroupName, ReplicatedFolderName, State

   Durum 4 değilse DFS Replication günlüğüne bakın. Olay 2213 kirli kapanma (dirty shutdown) sonrası çoğaltmanın durduğunu söyler ve olay metninin kendisi ResumeReplication komutunu içerir; DFSR veritabanını silmeyin. Olay 4012 ise DC'nin MaxOfflineTimeInDays (varsayılan 60 gün) süresinden uzun çoğaltmadığını gösterir; burada çözüm Microsoft'un KB2218556 makalesindeki yetkisiz (non-authoritative) eşitlemedir.

6. Saat ve FSMO rollerini kontrol edin

   Kerberos varsayılan olarak 5 dakikadan büyük saat farkını reddeder; erişim reddedildi (5) ve 8453 hatalarının bir kısmı aslında saat sorunudur. DC'ler etki alanı hiyerarşisinden, orman kök etki alanının PDC emülatörü ise güvenilir bir dış kaynaktan zaman almalıdır:

   w32tm /query /status

   w32tm /monitor

   Rol sahiplerini iki yoldan görebilirsiniz:

   netdom query fsmo

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

   Listede artık var olmayan bir sunucu görüyorsanız rol devri (transfer) veya el koyma (seize) planlayın. dcdiag /e /test:KnowsOfRoleHolders tüm DC'lerin rol sahiplerini aynı bilip bilmediğini karşılaştırmanızı sağlar.

7. Düzeltmeden sonra eşitleyin ve yeniden doğrulayın

   Kök nedeni (port, DNS kaydı, saat, izin) giderdikten sonra kaynak DC'den tüm bölümleri, siteler arası dahil, dışarı doğru itin:

   repadmin /syncall IST-DC01 /AdeP

   Bayraklar Microsoft belgesine göre: A tüm bölümler, d mesajlarda ayırt edici ad, e diğer sitelerdeki DC'ler, P değişikliği dışarı itme. Ardından yalnızca hatalı satırları ve PowerShell karşılığını kontrol edin:

   repadmin /replsummary * /errorsonly

   Get-ADReplicationFailure -Target 'example.com' -Scope Forest
   Get-ADReplicationPartnerMetadata -Target 'example.com' -Scope Domain |
       Select-Object Server, Partner, LastReplicationSuccess, LastReplicationResult

   Get-ADReplicationUpToDatenessVectorTable -Target IST-DC01 hangi DC'nin hangi kaynaktan hangi USN'e kadar değişiklik aldığını gösterir; lingering nesne şüphesinde işe yarar. Son olarak dcdiag /e /q boş dönmeli.

Hata kodları: anlamı ve ilk bakılacak yer

Tablodaki İngilizce metinler, Microsoft'un sorun giderme makalelerinde ve repadmin çıktısında görünen mesajlardır; Türkçe arayüzlü sunucuda karşılıkları farklı görünebilir, kod ise aynı kalır.

Kalıcı önlem

Microsoft'un 8606 makalesindeki ölçüt benim izleme eşiğim: tombstone ömrünün yüzde 50'si kadar gelen çoğaltma yapmamış DC izleme listesine girer, yüzde 90'ına kadar düzelmeyen DC zorla kaldırılır. 180 günlük ormanda bu 90 ve 162 gün demek; ama haftalık rapor varsa bu sınırlara hiç yaklaşmazsınız. Yedek tarafında repadmin /showbackup * her bölümün son yedek zamanını gösterir; DC yedekleme sıklığı ve tombstone ilişkisi için VM yedekleme stratejisi listesine bakın. Strict replication consistency'nin açık olduğunu da okuyarak doğrulayın: Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'Strict Replication Consistency' değeri 1 olmalı.

Aşağıdaki betik yalnızca okur: tüm DC'lerin çoğaltma durumunu CSV olarak, dcdiag hatalarını metin olarak kaydeder ve sorun varsa çıkış kodunu 1 yapar. Görev Zamanlayıcı'nın "Son çalıştırma sonucu" alanı veya izleme aracınız bu kodu alarm olarak yakalar.

# AD-Saglik-Raporu.ps1 - yalnızca okur, hiçbir AD ayarını değiştirmez.
# Gereksinim: AD DS araçları (repadmin, dcdiag) ve ActiveDirectory modülü.
$klasor = 'C:\Raporlar\AD'
$tarih  = Get-Date -Format 'yyyy-MM-dd'
New-Item -ItemType Directory -Path $klasor -Force | Out-Null

# 1) Tüm DC'lerin gelen çoğaltma durumu
$csvYolu = Join-Path $klasor "showrepl-$tarih.csv"
repadmin /showrepl * /csv | Out-File -FilePath $csvYolu -Encoding utf8
$satirlar = Import-Csv -Path $csvYolu
$hataliSatir = $satirlar | Where-Object {
    $_.showrepl_COLUMNS -ne 'showrepl_INFO' -or ($_.'Number of Failures' -as [int]) -gt 0
}
if ($hataliSatir) {
    $hataliSatir | Export-Csv -Path (Join-Path $klasor "showrepl-hatalar-$tarih.csv") -NoTypeInformation -Encoding utf8
}

# 2) dcdiag: yalnızca hatalar (/q). İngilizce çıktıdaki "failed test" aranır.
$dcdiagYolu = Join-Path $klasor "dcdiag-$tarih.txt"
dcdiag /e /q "/f:$dcdiagYolu" | Out-Null
$dcdiagHata = Select-String -Path $dcdiagYolu -Pattern 'failed test' -SimpleMatch

# 3) PowerShell karşılığı: orman genelindeki güncel hatalar
$orman  = (Get-ADForest).Name
$psHata = Get-ADReplicationFailure -Target $orman -Scope Forest |
    Where-Object { $_.FailureCount -gt 0 }

# 4) Özet ve çıkış kodu
$ozet = "{0} | showrepl hatalı satır: {1} | dcdiag başarısız test: {2} | Get-ADReplicationFailure: {3}" -f `
    $tarih, @($hataliSatir).Count, @($dcdiagHata).Count, @($psHata).Count
$ozet | Out-File -FilePath (Join-Path $klasor 'ozet.log') -Append -Encoding utf8

if ($hataliSatir -or $dcdiagHata -or $psHata) {
    Write-Warning "AD sağlık raporunda sorun var: $ozet"
    exit 1
}
exit 0

Betiği haftalık bir göreve bağlamak için gMSA gibi parolası yönetilen bir hesap kullanın. Microsoft'a göre repadmin, hedeflenen her DC'de yönetici yetkisi ister; bu izinler devredilebilir.

$eylem = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NoProfile -ExecutionPolicy Bypass -File C:\Betikler\AD-Saglik-Raporu.ps1'
$tetik = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 07:00
$hesap = New-ScheduledTaskPrincipal -UserId '<ETKI-ALANI>\<GMSA-ADI>$' -LogonType Password -RunLevel Highest
Register-ScheduledTask -TaskName 'AD saglik raporu' -Action $eylem -Trigger $tetik -Principal $hesap

Siteleri ve alt ağları AD Sites and Services'te doğru tanımlamak da kalıcı önlemdir: tanımsız alt ağdaki istemci yanlış sitedeki DC'ye gider ve yavaşlığı çoğaltma sorunu sanırsınız. Alt ağ sınırlarını IP subnet hesaplama aracıyla kontrol edebilirsiniz.

İlgili hatalar

Kaynaklar

• Microsoft Learn, dcdiag (erişim: Ekim 2026)
• Microsoft Learn, Repadmin (erişim: Ekim 2026)
• Microsoft Learn, Repadmin /replsummary (erişim: Ekim 2026)
• Microsoft Learn, Repadmin /syncall (erişim: Ekim 2026)
• Microsoft Learn, Diagnose Active Directory replication failures (erişim: Ekim 2026)
• Microsoft Learn, Troubleshoot common Active Directory replication errors (erişim: Ekim 2026)
• Microsoft Learn, Replication error 8524 (erişim: Ekim 2026)
• Microsoft Learn, Replication error 1722 (erişim: Ekim 2026)
• Microsoft Learn, Replication error 8453 (erişim: Ekim 2026)
• Microsoft Learn, Replication error 8606 (erişim: Ekim 2026)
• Microsoft Learn, Replication error -2146893022 (erişim: Ekim 2026)
• Microsoft Learn, Active Directory replication error 1256 (erişim: Ekim 2026)
• Microsoft Learn, How to detect and recover from a USN rollback (erişim: Ekim 2026)
• Microsoft Learn, Troubleshoot missing SYSVOL and Netlogon shares for DFS Replication (erişim: Ekim 2026)
• Microsoft Learn, dfsrmig (erişim: Ekim 2026)
• Microsoft Learn, SYSVOL DFSR migration fails after in-place upgrade to Windows Server 2019 (erişim: Ekim 2026)
• Microsoft Learn, Enable Strict Replication Consistency (erişim: Ekim 2026)
• Microsoft Learn, Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042) (erişim: Ekim 2026)
• Microsoft Learn, Get-ADReplicationFailure ve Get-ADReplicationPartnerMetadata (erişim: Ekim 2026)
• Microsoft Learn, What's new in Windows Server 2025: Active Directory Domain Services (erişim: Ekim 2026)