Active Directory Sağlık Kontrolü: DNS, Replikasyon ve Saat

Active Directory sağlığını yalnızca kullanıcıların bugün oturum açabilmesiyle değerlendirmek eksik kalır. Replikasyon gecikmesi, yanlış DNS, zaman sapması veya unutulmuş servis bağımlılıkları bir süre görünmeden ilerleyebilir. Sorun, ilk controller bakıma alındığında veya bir uygulama yeni kaydı beklediğinde ortaya çıkabilir. Düzenli sağlık kontrolü bu gizli bağımlılıkları görünür kılmaya yardımcı olur.

Bu yazı yeni AD kurulumu değil, mevcut Windows Server tabanlı domainin değerlendirilmesi için bir çalışma düzeni sunar. Komutlar keşif ve tanılama amaçlıdır; otomatik onarım, controller kaldırma veya metadata temizliği yapmaz. Bir hata çıktısının görülmesi, tek başına uygulanacak düzeltmeyi belirlemez. Ortam geçmişi ve değişiklikler birlikte incelenmelidir.

1. Beklenen topolojiyi gerçek durumla karşılaştırın

Önce hangi domain controller'ların bulunması gerektiğini belirleyin. Envanterde yer alan ama artık çalışmayan sunucu ile geçici bakımda olan sunucu aynı şekilde ele alınmamalıdır. Controller adı, işletim sistemi, lokasyon, site, DNS rolü ve iş sahibini kaydedin. Bir sunucunun neden hâlâ listede bulunduğu bilinmiyorsa ilk iş bunu açıklığa kavuşturmaktır.

Get-ADDomainController -Filter *
Get-ADDomain
Get-ADForest

Bu çıktıları yetkili bir yönetim ortamında alın. Yönetim araçlarının bulunması ve hesabın gerekli okuma yetkilerine sahip olması gerekir. Sonuçları kontrol tarihiyle saklayın. Sonraki kontrolde yalnızca hata sayısını değil, topolojide beklenmeyen değişiklikleri de karşılaştırın. Sürekli aynı kontrolü yapmak, başlangıç referansı yoksa sınırlı fayda sağlar.

2. Replikasyonun son başarılı zamanını inceleyin

Microsoft replikasyon sorun giderme dokümanı, replikasyon durumunun DNS, kimlik, zaman ve bağlantı gibi bağımlılıklarla ilişkisini açıklar. Aşağıdaki çıktılarda başarısız eşleri ve gecikmeyi birlikte değerlendirin.

repadmin /replsummary
repadmin /showrepl

Bir bağlantının hata vermemesi kadar verinin beklenen sürede güncellenmesi de önemlidir. Belirli site bağlantıları veya geçici bakım pencereleri sonucu etkileyebilir. Aynı hata kodunun birden fazla nedeni olabileceğinden, ilgili olay günlüğünü ve son değişiklikleri inceleyin. Körlemesine zorunlu senkronizasyon çalıştırmak veya topolojiyi değiştirmek yerine nedeni daraltın.

3. DNS'i AD'nin parçası olarak değerlendirin

İstemciler controller bulmak için DNS servis kayıtlarına ihtiyaç duyar. Bir sunucunun dış alan adlarını çözebilmesi, AD kayıtlarının da sağlıklı olduğu anlamına gelmez. Controller'ın ve pilot istemcilerin hangi DNS adreslerini kullandığını görün. Genel çözümleyiciyle kurumsal çözümleyicinin aynı listede bulunması aralıklı sorunlar yaratabilir.

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.example.com
dcdiag /test:dns

Örnek domaini kendi ortamınıza göre değiştirin. DCDiag başvurusu, testlerin kapsamını ayrıntılandırır. Eski kayıtları silmeye geçmeden kaydın hangi hizmete ait olduğunu ve güncelleme davranışını belirleyin. Kullanılmayan kayıtla geçici olarak ulaşılamayan servis aynı durum değildir.

4. Saat ve kimlik bağımlılıklarını kontrol edin

Zaman tutarlılığı kimlik altyapısının önemli bağımlılıklarındandır. Sunucuların saat kaynağını, senkronizasyon durumunu ve sanallaştırma katmanının etkisini inceleyin. Domain hiyerarşisiyle uyumsuz, farklı kaynaklara bağlı sistemler teşhisi zorlaştırabilir. Tek bir sunucuda saati elle düzeltmek sorunun kökünü gidermeyebilir.

w32tm /query /status
w32tm /query /source

Bu çıktılar durumu anlamaya yardımcı olur; doğru zaman tasarımını kendiliğinden kurmaz. Kaynak değişikliği yapılacaksa rol ve topolojiye uygun plan hazırlayın. Sertifika sorunları, oturum hataları ve zaman şikâyetlerini ayrı olaylar gibi görmek yerine ortak bağımlılık ihtimalini değerlendirin.

5. Yetki ve servis hesabı gözden geçirmesini ekleyin

Domain sağlığı yalnızca servislerin çalışması değildir. Geniş yetkili hesapların kimler tarafından kullanıldığı, servis hesaplarının sahibi ve kullanım amacı da bilinmelidir. İşten ayrılan çalışanla ilişkili bir görevin hâlâ kişisel hesabın parolasıyla çalışması teknik bir işletim riskidir. Hesabı kapatmadan önce bağımlılığın anlaşılması gerekir.

Ayrı yönetici hesabı, düzenli yetki incelemesi ve uygulama sorumluları için anlaşılır erişim modeli oluşturun. Günlük iş hesabına eklenen kalıcı yüksek yetkiyi varsayılan çözüm saymayın. Hesap değişikliklerinde uygulama bağlantıları ve zamanlanmış görevler için doğrulama senaryoları hazırlayın. Yapılan işin kaydı, sonraki bakımın daha güvenilir olmasını sağlar.

6. Bulguları uygulanabilir bir rapora çevirin

Rapor yalnızca komut çıktılarının eklendiği dosya olmamalıdır. Her bulgu için etki, kanıt, önerilen inceleme, sorumlu ve hedef tarih yazın. Kritik hizmeti durdurabilecek bulgularla dokümantasyon eksiklerini ayırın. Aynı şekilde doğrulanmış arızayla araştırılması gereken işareti de birbirine karıştırmayın.

Örneğin varsayımsal bir şubede replikasyon gecikmesi bulunması, doğrudan yeni controller satın alma kararı gerektirmez. Önce bağlantı, site eşleşmesi, DNS ve olay geçmişi incelenir. Darboğaz belirlendikten sonra teknik değişiklik önerilir ve yeniden ölçülür. Böylece sağlık kontrolü, ürün listesine dönüşmeden işletme için karar desteği üretir.

CieloSync ile yönetilen IT kapsamınızın parçası olarak AD sağlık değerlendirmesi, bulgu takibi ve bakım planı hazırlayabilirsiniz. Mevcut yapınızı paylaşın; kontrolü topolojinize göre şekillendirelim.