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:

  • /syncall kullanı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 yokHiçbir şey yapma
Küçük gecikmeler, hata yokBekle (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ı ortamSı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.

İlginizi Çekebilir