Active Directory ortamlarında replikasyon normal koşullarda otomatik ve arka planda çalışan bir süreçtir. Ancak gerçek hayatta her zaman her şey planlandığı gibi ilerlemez. Büyük değişikliklerden sonra replikasyon hataları giderildiğinde ya da yalnızca ortamın güncel durumundan emin olmak istediğinde replikasyonu manuel olarak tetiklemek gerekebilir. İşte bu noktada repadmin /syncall komutu devreye girer.
/syncall bir domain controller üzerindeki dizin bölümlerini (naming context) replikasyon partnerleriyle senkronize etmeye zorlayan güçlü bir komuttur. Doğru kullanıldığında replikasyon sorunlarını hızlıca doğrulamak ve gecikmeleri ortadan kaldırmak için oldukça etkilidir.
Yerel Domain Controller’daki Tüm Naming Context’leri Senkronize Etmek
En temel kullanım senaryosunda, bulunduğun domain controller üzerinde barındırılan tüm naming context’leri (Domain, Configuration, Schema ve varsa Application Partition’lar) replikasyon partnerleriyle senkronize etmek isteyebilirsin.
Bunun için aşağıdaki komut yeterlidir:
repadmin /syncall
Bu komut varsayılan olarak:
- Sadece mevcut site içindeki replikasyon partnerlerini hedef alır
- Doğrudan bağlantılı (adjacent) domain controller’larla çalışır
- Otomatik replikasyon davranışını manuel olarak tetikler
Küçük ve tek site’lı ortamlarda bu kullanım çoğu zaman yeterlidir.
Belirli Bir Domain Controller ile Replikasyonu Zorlamak
Bazı senaryolarda replikasyon sorunlarının yalnızca belirli bir domain controller ile sınırlı olduğunu fark edebilirsin. Böyle durumlarda tüm ortamı hedef almak yerine, doğrudan ilgili DC ile senkronizasyon başlatmak daha kontrollü bir yaklaşım olacaktır.
repadmin /syncall <DCName>
Örnek:
repadmin /syncall DC02
Bu kullanım, özellikle “Bu DC gerçekten güncel mi?” sorusuna hızlı bir yanıt almak için oldukça etkilidir.
/SyncAll Komutunun Parametrelere Göre Davranışı
/syncall komutunun en önemli özelliklerinden biri, aldığı parametrelere göre çok farklı şekillerde davranabilmesidir. Örneğin:
repadmin /syncall /Adeu
Bu komut:
- Tüm naming context’leri senkronize eder
- Replikasyonu iki yönlü olarak zorlar
- İşlemi recursive şekilde ilerletir
- Mevcut site ile sınırlı kalmaz
Bu nedenle /syncall, “tek tip” bir komut olarak değil, bilinçli ve kontrollü şekilde kullanılması gereken bir araç olarak değerlendirilmelidir.
/SyncAll Parametreleri ve Anlamları
Aşağıda, /syncall ile birlikte en sık kullanılan parametreler ve pratikte ne işe yaradıkları açıklanmıştır:
- /a – Eğer herhangi bir domain controller’a ulaşılamazsa işlemi durdurur
- /A – Hedef DC üzerinde bulunan tüm naming context’leri senkronize eder
- /d – Çıktılarda sunucu isimlerini Distinguished Name (DN) formatında gösterir
- /e – Tüm site’ları kapsar (enterprise-wide). Kullanılmazsa yalnızca mevcut site hedeflenir
- /h – Yardım bilgisini görüntüler
- /i – Kullanıcı iptal edene kadar senkronizasyonu döngü halinde tekrarlar
- /I – Senkronizasyon yapmaz; bunun yerine yol boyunca
/showreplçalıştırarak durumu raporlar - /j – Sadece doğrudan (adjacent) replikasyon partnerlerini senkronize eder
- /p – Her mesajdan sonra duraklar, işlemi manuel olarak durdurma imkânı sağlar
- /P – Değişiklikleri belirtilen DC’den dışarı doğru iter (push replication)
- /q – Sessiz mod; gereksiz çıktıları bastırır
- /Q – Çok sessiz mod; yalnızca kritik hataları gösterir
- /s – Senkronizasyon yapmaz (no-op). Genellikle test ve doğrulama amaçlı kullanılır
- /S – İlk bağlantı kontrolünü atlar ve doğrudan senkronizasyonu dener
Gerçek Hayatta En Sık Kullanılan /SyncAll Senaryoları
Aşağıdaki örnekler, üretim ortamlarında en çok tercih edilen ve güvenli kabul edilen kullanımlardır:
“Bu DC üzerindeki her şeyi senkronize et”
repadmin /syncall /A /d
Tüm Site’ları Kapsayan, Sessiz (Enterprise-Wide) Senkronizasyon
repadmin /syncall /A /e /q
Merkezi (Hub) Bir DC’den Değişiklikleri Dışarı Doğru İt
repadmin /syncall /A /e /P
Bu son senaryo, özellikle büyük ve çok site’lı ortamlarda merkezi bir domain controller’ın referans alındığı yapılarda oldukça yaygındır.
replsummary + /showrepl + /syncall Birlikte Kullanım Akışı (Pratik Troubleshooting Yaklaşımı)
Active Directory replikasyon sorunlarını çözerken yapılan en büyük hatalardan biri, doğrudan repadmin /syncall çalıştırmaktır. Oysa sağlıklı bir yaklaşım, önce durumu analiz etmek ardından hedefli müdahalede bulunmaktır. Bu noktada RepAdmin’in üç temel komutu birlikte ve belirli bir sırayla kullanılmalıdır.
Adım 1 – Ortamın Genel Sağlığını Gör: /replsummary
Troubleshooting süreci her zaman büyük resimle başlamalıdır:
repadmin /replsummary
Bu komut sana şu soruların cevabını verir:
- Hangi domain controller’lar replikasyonda geride?
- Sorun tek bir DC’de mi yoksa yaygın mı?
- Replikasyon hiç mi çalışmıyor, yoksa sadece gecikmeli mi?
Eğer burada:
- Fails = 0 ve
- Largest Delta kabul edilebilir seviyedeyse
→ Ortam genel olarak sağlıklıdır ve /syncall çalıştırmak çoğu zaman gereksizdir.
Adım 2 – Sorunlu DC’yi Derinlemesine İncele: /showrepl
Eğer /replsummary çıktısında bir veya birkaç DC dikkatini çekiyorsa, sıradaki adım detaylı incelemedir:
repadmin /showrepl DC01
Bu aşamada şunlara odaklanmalısın:
- Replikasyon hangi DC ile başarısız?
- Hata sürekli mi, aralıklı mı?
- RPC, DNS veya bağlantı problemi mi var?
- Son başarılı replikasyon ne zaman gerçekleşmiş?
Bu analiz yapılmadan /syncall çalıştırmak, sorunu çözmek yerine gizleyebilir.
Adım 3 – Sorun Çözüldükten Sonra Manuel Senkronizasyon: /syncall
Eğer:
- Network, DNS veya RPC problemi çözüldüyse
- DC’ler birbirini sağlıklı görüyorsa
artık manuel senkronizasyon aşamasına geçebilirsin:
repadmin /syncall /A /d
Bu akışın mantığı şudur:
Önce tespit et → sonra doğrula → en son zorla
Bu yaklaşım, üretim ortamlarında en güvenli ve önerilen yöntemdir.
/syncall Hata Kodlarına Göre Troubleshooting Rehberi
repadmin /syncall çalıştırıldığında alınan hata kodları genellikle sorunun kök nedenini açıkça işaret eder. Aşağıda en sık karşılaşılan hata kodları ve yapılması gerekenler yer almaktadır.
1722 – The RPC Server Is Unavailable
Anlamı:
Domain controller’lar arasında RPC iletişimi kurulamıyor.
Kontrol Edilecekler:
- DNS kayıtları doğru mu?
- Firewall RPC portlarını (135 + dynamic ports) engelliyor mu?
- DC’ler birbirine ping atabiliyor mu?
Bu hata varken /syncall çalıştırmak işe yaramaz.
8453 – Replication Access Was Denied
Anlamı:
Yetkilendirme problemi var.
Olası Nedenler:
- Secure Channel bozuk
- DC account’ta sorun
- Yetki veya ACL problemleri
Çözüm:
nltest /sc_verify- Gerekirse DC account reset
58 – The Specified Server Cannot Perform The Requested Operation
Anlamı:
Hedef DC replikasyon isteğini işleyemiyor.
Olası Nedenler:
- DC üzerindeki servisler durmuş
- Disk veya performans problemi
- NTDS servis hatası
1908 / 8606 – Lingering Object / Tombstone Problemleri
Anlamı:
DC’ler arasında veri tutarsızlığı var.
Bu durumda:
/syncallkullanılmamalıdır- Önce lingering object temizliği yapılmalıdır
“Ne Zaman /syncall, Ne Zaman Beklemeli?” Karar Tablosu
Aşağıdaki tablo, üretim ortamlarında en sık sorulan soruya net bir rehber sunar:
| Durum | Önerilen Aksiyon |
|---|---|
| Replikasyon sağlıklı, gecikme yok | Hiçbir şey yapma |
| Küçük gecikmeler, hata yok | Bekle (otomatik replikasyon) |
| Tek DC geride, hata yok | /showrepl ile incele |
| DNS / RPC hatası var | Önce sorunu çöz |
| Sorun çözüldü | /syncall ile doğrula |
| Büyük değişiklik sonrası | Kontrollü /syncall |
| Lingering object şüphesi | /syncall kullanma |
| Büyük ve çok site’lı ortam | Sınırlı ve hedefli /syncall |
Altın kural:
/syncall bir çözüm değil, bir doğrulama ve tetikleme aracıdır.
repadmin /syncall, güçlü olduğu kadar dikkatli kullanılması gereken bir komuttur. Gereksiz ve sık çalıştırılması:
- Network trafiğini artırabilir
- Domain controller’lar üzerinde ek yük oluşturabilir
- Büyük ortamlarda gecikmelere ve performans sorunlarına yol açabilir
Bu nedenle /syncall komutu, bir sorun tespit edildiğinde veya doğrulama ihtiyacı doğduğunda kullanılmalıdır; rutin bir işlem gibi çalıştırılması önerilmez.