--- title: "Active Directory sağlık kontrolü: kurulum sonrası doğrulama rehberi" author: "Abdulaziz Akyol" author_url: https://www.abdulazizakyol.com/hakkimda/ url: https://www.abdulazizakyol.com/blog/ad-kurulumunun-dogrulanmasi/ language: tr published: 2018-10-01 updated: 2026-09-25 categories: ["Active Directory", "Sistem yönetimi"] tags: ["Active Directory", "dcdiag", "repadmin", "DFSR", "FSMO", "PowerShell", "Windows Server"] description: "Yeni DC kurulumundan sonra Active Directory'yi adım adım doğrulayın: dcdiag, repadmin, DNS SRV kayıtları, SYSVOL/DFSR, FSMO rolleri ve zaman eşitleme." --- # Active Directory sağlık kontrolü: kurulum sonrası doğrulama rehberi Yazar: [Abdulaziz Akyol](https://www.abdulazizakyol.com/hakkimda/) · 2018-10-01 ## Öne çıkanlar - Yeni bir etki alanı denetleyicisi (DC) üretime alınmadan önce site/alt ağ yerleşimi, DNS SRV kayıtları, SYSVOL ve NETLOGON paylaşımları, çoğaltma, FSMO rolleri ve zaman eşitlemesi doğrulanmalıdır. - dcdiag /v ve repadmin /replsummary çıktısında tek bir başarısız test ya da çoğaltma hatası bile DC'yi üretime almadan önce incelenmesi gereken bir bulgudur. - Windows Server 2019 ve sonraki sürümler, SYSVOL'ü hâlâ FRS ile çoğaltan bir etki alanına DC olarak eklenemez; önce dfsrmig ile DFSR'ye geçiş tamamlanmalıdır. - Etki alanındaki saatin kaynağı orman kök etki alanının PDC emülatörüdür; yalnızca bu DC dış bir NTP kaynağına, diğer DC'ler etki alanı hiyerarşisine bağlanmalıdır. - Get-ADDomainController, Get-ADReplicationPartnerMetadata ve Get-WinEvent ile bu kontrollerin çoğu PowerShell'de otomatikleştirilip düzenli çalıştırılabilir. 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ş](https://www.abdulazizakyol.com/blog/power-shell-giris/) 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: ```powershell 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. ```powershell 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. ```powershell 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: ```powershell 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 ```powershell 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: ```powershell Get-ADRootDSE -Server DC02 | Select-Object isGlobalCatalogReady ``` ## Adım 5: Çoğaltma sağlıklı mı? ```powershell 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: ```powershell 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. ```powershell 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. ```powershell # 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](https://www.abdulazizakyol.com/blog/hp-switch-genel-ayarlar/) 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: ```powershell $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:` | 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](https://www.abdulazizakyol.com/blog/vbscript-ten-powershell-e-yerel-kullanici-ve-grup-yonetimi/) yazısı iyi bir devam noktası. ## Sık sorulan sorular ### dcdiag hangi testleri varsayılan olarak çalıştırmaz? DNS testi varsayılan çalıştırmada yer almaz; dcdiag /test:dns ile ayrıca istenmelidir. Topology, CutoffServers ve OutboundSecureChannels testleri de yalnızca /c (kapsamlı) parametresiyle ya da /test ile açıkça çağrıldığında çalışır. ### Yeni DC'de SYSVOL ve NETLOGON paylaşımı neden görünmüyor? En sık neden, DFS Replication'ın SYSVOL için ilk eşitlemeyi (initial sync) tamamlamamış olmasıdır. DFS Replication günlüğünde 4614 olayı var ama 4604 olayı yoksa DC hâlâ kaynak ortaktan veri bekliyordur; kaynak DC'de 2213 (kirli kapanma) gibi bir hata olup olmadığına bakın. ### Active Directory çoğaltmasının sağlıklı olduğunu nasıl anlarım? repadmin /replsummary çıktısında fails sütununun sıfır olması, dcdiag /test:replications testinin geçmesi ve Get-ADReplicationFailure komutunun kayıt döndürmemesi temel göstergelerdir. En büyük gecikme (largest delta) değerinin site bağlantı zamanlamanızla uyumlu olup olmadığını da kontrol edin. ### SYSVOL için FRS'den DFSR'ye geçiş zorunlu mu? Evet. FRS, Windows Server 2008 R2 ile kullanımdan kaldırılmış (deprecated) durumdadır ve Windows Server 2019 ve sonrası bir sunucu, SYSVOL'ü FRS ile çoğaltan etki alanına DC olarak yükseltilemez. Geçiş dfsrmig aracıyla aşamalı yapılır ve Eliminated durumuna geçiş geri alınamaz. ## Kaynaklar 1. [Microsoft Learn — dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) 2. [Microsoft Learn — dfsrmig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dfsrmig) 3. [Microsoft Learn — NTFRS deprecation blocks promotion of replica DCs](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/ntfrs-deprecation-blocks-replic-dc-installation) 4. [Microsoft Learn — Get-ADReplicationPartnerMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationpartnermetadata) 5. [Microsoft Learn — Configure an authoritative time server](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-authoritative-time-server) 6. [Microsoft Learn — Troubleshoot missing SYSVOL and Netlogon shares](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-missing-sysvol-and-netlogon-shares) --- Abdulaziz Akyol, CX Teknoloji'nin (yapay zekâ, görüntü işleme ve IoT) kurucusudur. Asıl sürüm: https://www.abdulazizakyol.com/blog/ad-kurulumunun-dogrulanmasi/