Active Directory'de Domain Controller Replikasyonu Nasıl Yönetilir?

Domain Controller'lar arasındaki replikasyon yönetimi, özellikle büyük ve dağıtık Network ortamlarında, Active Directory yapısının tutarlılığı ve performansı için kritik bir süreçtir. Active Directory replikasyonu, farklı Domain Controller'lar arasında verilerin senkronize edilmesini sağlar ve bu sayede her bir Controller, en güncel bilgiyi içerir. Replikasyon işlemleri, Network üzerindeki veri bütünlüğünü ve kullanıcıların doğru bilgiye erişimini garanti eder.

CMD komut satırı kullanarak replikasyon yönetimi, sistem yöneticilerine hızlı ve etkili bir müdahale imkanı tanır. Bu yöntem, replikasyon durumu hakkında ayrıntılı bilgi almayı, replikasyon işlemlerini manuel olarak başlatmayı ve olası sorunları tanımlamayı mümkün kılar. Özellikle beklenmedik sorunlar veya planlı bakım durumlarında, komut satırı aracılığıyla hızlı çözümler üretmek büyük avantaj sağlar.

CMD üzerinden replikasyon yönetimi, Domain Controller'lar arasındaki bağlantıları izlemeye ve replikasyon süreçlerinin sağlıklı bir şekilde ilerleyip ilerlemediğini kontrol etmeye olanak tanır. Replikasyon bağlantıları düzenli olarak izlenmeli ve olası kesintiler veya gecikmeler hızlıca tespit edilmelidir. Replikasyon süreçlerinin etkin bir şekilde yönetilmesi, veri tutarlılığını ve sistem performansını doğrudan etkiler.

Replikasyon yönetiminde, belirli zaman aralıklarıyla replikasyon işlemlerinin başlatılması ve izlenmesi önemlidir. Bu süreçlerin doğru bir şekilde yönetilmesi, Network'ün genel sağlığı açısından kritik bir rol oynar. Replikasyon süreçlerinde herhangi bir anormallik tespit edildiğinde, hızlıca müdahale edilerek sorunun kaynağı belirlenmeli ve gerekli düzeltici adımlar atılmalıdır. Bu, Network üzerindeki olası veri tutarsızlıklarının önüne geçilmesini sağlar.

Sonuç olarak, CMD komut satırı ile replikasyon yönetimi, Active Directory yapısının etkin bir şekilde yönetilmesini sağlar. Bu yöntem, sistem yöneticilerine daha fazla kontrol ve esneklik sunar. Replikasyon süreçlerinin doğru bir şekilde izlenmesi ve yönetilmesi, Network'ün güvenilirliğini artırır ve kullanıcı deneyimini iyileştirir. Bu nedenle, CMD komut satırı araçlarını kullanarak replikasyon yönetimini optimize etmek, her sistem yöneticisinin temel becerilerinden biri olmalıdır.

Active Directory Site yapım aşağıdaki gibidir:



 

Repadmin /replsummary Komutu İle Replikasyon Özetini İzleme

Repadmin /replsummary komutu ile Active Directory Sites and Services üzerindeki Site topoloji içinde yer alan Domain Contoller'ların replikasyonun özet bilgisini elde ediyorum.

Source DSA ve Destination DSA Nedir?

Her iki Directory System Agent (DSA) da, replikasyon sürecinin sorunsuz ve etkin bir şekilde gerçekleşmesi için birbirleriyle sürekli iletişim halindedir. Replikasyon, genellikle belirli zaman aralıklarında otomatik olarak gerçekleşir, ancak bazı durumlarda manuel müdahale gerekebilir. Bu süreçte, Source DSA ve Destination DSA'nın sağlıklı bir şekilde çalışması, Active Directory yapısının genel sağlığı ve performansı açısından büyük önem taşır.

Kısacası, Source DSA ve Destination DSA, Active Directory replikasyonunun iki kritik bileşeni olup, verilerin doğru ve güvenilir bir şekilde Domain Controller'lar arasında aktarılmasını sağlar. Bu bileşenlerin etkin bir şekilde yönetilmesi, Network üzerindeki veri tutarlılığını ve sistemin genel performansını doğrudan etkiler.

Repadmin /replsummary komutu ile karşımıza çıkan bilgilerde, her Domain Controller'ın Source DSA ve Destination DSA alanlarında da yer aldığını görebilmekteyiz. Bunun nedeni, Active Directory'nin Multi Master Domain Model yapısını kullanmasından dolayıdır. Multi Master Domain Model yapısı, Source DSA (Directory System Agent) ve Destination DSA (Directory System Agent) kavramlarıyla doğrudan ilişkilidir. Bu ilişkiyi anlamak için Multi Master Domain Model'in ne olduğunu ve nasıl çalıştığını kısaca açıklayalım.

Multi Master Domain Model Nedir?

Multi Master Domain Model, Active Directory'de kullanılan bir replikasyon modelidir. Bu modelde, her Domain Controller, hem verileri alabilir hem de bu verilerde değişiklik yapabilir. Yani, herhangi bir Domain Controller'da yapılan değişiklikler, diğer Domain Controller'lara replikasyon yoluyla dağıtılır. Bu model, veri tutarlılığı ve yüksek erişilebilirlik sağlamak için tasarlanmıştır.

Source DSA ve Destination DSA İlişkisi

Multi Master Domain Model'de her Domain Controller, hem Source DSA hem de Destination DSA rolünü üstlenebilir.

1- Source DSA: Bir Domain Controller, verilerinde değişiklik yapıldığında, bu değişiklikleri diğer Domain Controller'lara replikasyon yoluyla göndermek için Source DSA rolünü üstlenir. Örneğin, bir kullanıcının parolasının değiştirildiği bir Domain Controller, bu değişikliği diğer Domain Controller'lara dağıtmak için Source DSA olarak hareket eder.

2- Destination DSA: Diğer Domain Controller'lar, bu değişiklikleri almak için Destination DSA rolünü üstlenir. Bu süreçte, Destination DSA rolündeki Domain Controller'lar, gelen verileri alır, kendi veri tabanlarına uygular ve gerektiğinde çakışmaları çözümlemekle sorumludur.

Largest Delta Nedir?

Largest Delta, Active Directory replikasyonunda kullanılan bir terimdir ve iki Active Directory nesnesi arasındaki en büyük değişikliği ifade eder. Bu terim, özellikle replikasyon işlemlerinin izlenmesi ve yönetilmesi sırasında önem kazanır. Largest Delta, en son başarılı replikasyon işlemi ile mevcut durum arasındaki en büyük zaman farkını temsil eder. Bu kavramı daha iyi anlamak için bazı temel bileşenleri ve ilişkili kavramları inceleyelim:

✅ Replikasyon Gecikmesi (Latency): Replikasyon gecikmesi, bir değişikliğin bir Domain Controller'dan diğerine geçişi sırasında geçen süredir. Largest Delta, bu gecikmelerin izlenmesinde önemli bir göstergedir.

✅ Değişiklikler Arasındaki Süre: Largest Delta, en son başarılı replikasyon işlemi ile mevcut zaman arasındaki en büyük süreyi temsil eder. Bu süre, replikasyon işlemlerindeki potansiyel sorunları veya gecikmeleri belirlemek için kullanılır.

fails/total, %% ve error Nedir?

Active Directory replikasyon denemesi sayısı, yapılandırma ayarlarına ve organizasyonun büyüklüğüne bağlı olarak değişir. Yukarıdaki Repadmin /replsummary komut çıktısında verilen sayılar, belirli bir zaman dilimi içinde yapılan replikasyon denemelerinin sayısını gösterir ve bu sayılar, ortamın genel durumu hakkında bilgi vermek için kullanılır. Replikasyon denemesi sayısı, her bir Partition için yapılan replikasyonların toplamıdır ve günlük, saatlik veya belirli aralıklarla yapılabilir.

repadmin /replsummary komutunu çalıştırdığınızda, Active Directory replikasyon durumu hakkında detaylı bilgi alırsınız. İlk tabloda, replikasyon süreci sırasında karşılaşılan temel parametreler ve bunların açıklamaları yer almaktadır. Şimdi bu parametrelerin ne anlama geldiğini kısaca özetleyelim:

SRV001

SRV002

SRV003

SRV004

Total alanındaki replikasyon denemelerinin sayısı, her bir Domain Controller'ın diğer Domain Controller'larla yaptığı toplam replikasyon denemelerinin sayısını gösterir. Bu denemeler, her bir Partition için yapılır ve belirli zaman aralıklarında gerçekleştirilir. Network bağlantısı, replikasyon frekansı, başarısız denemelerin yeniden yapılması gibi faktörler, toplam replikasyon denemesi sayısını etkiler. Bu nedenle, farklı Domain Controller'lar için farklı sayıda replikasyon denemesi görülebilir. Bunların potansiyel sebepleri, aşağıda sıralanan maddelerde yazılı olan durumlar olabilir.

1. Partition Sayısı

🔍 Açıklama: Active Directory'de Schema, Configuration, Domain, DnsForestZones ve DnsDomainZones olmak üzere toplam 5 Parition vardır.. Her Partition için ayrı replikasyon denemesi yapılır.

👉 Örnek: SRV001 her bir Partition için replikasyon yapar. Bu, toplamda 5 replikasyon denemesi anlamına gelir.

2. Domain Controller Sayısı

🔍 Açıklama: Organizasyondaki DC sayısı, replikasyon denemelerinin sayısını doğrudan etkiler. Her DC, diğer DC'lerle replikasyon yapar.

👉 Örnek: 4 DC (SRV001, SRV002, SRV003, SRV004) varsa, her bir DC diğer 3 DC ile replikasyon yapar.

3. Replikasyon Frekansı ve Zamanlaması

🔍 Açıklama: Replikasyon işlemleri belirli aralıklarla otomatik olarak gerçekleştirilir. Bu aralıklar, replikasyonun ne kadar sık yapıldığını belirler.

👉 Örnek: Intra-Site replikasyon (aynı site içindeki DC'ler) her 15 dakikada bir yapılabilir, Inter-Site replikasyon (farklı sitelerdeki DC'ler) daha seyrek yapılabilir (örneğin, her 3 saatte bir).

4. Network Durumu ve Trafik

🔍 Açıklama: Network bağlantısı iyi değilse, replikasyon denemeleri başarısız olabilir ve yeniden denenmesi gerekebilir. Network trafiği ve bağlantı kalitesi, replikasyonun başarısını etkiler.

👉 Örnek: SRV002 ile SRV003 arasındaki Network bağlantısı zayıfsa, replikasyon denemeleri başarısız olabilir ve daha fazla deneme yapılabilir.

Replike Olan Nedir?

Active Directory verilerinin güncelliği, Partition adı verilen 5 adet mantıksal bölüm üzerinden sağlanır. Active Directory ortamında verilerin doğru ve güncel kalabilmesi için her Domain Controller, Active Directory NTDS.dit veri tabanında bulunan verileri replikasyon süreçleri ile senkronize eder. Bu senkronizasyon, verilerin tüm Domain Controller'lar arasında güncel ve tutarlı olmasını sağlar. NTDS.dit, her Domain Controller'da bulunan ve Active Directory'nin tüm verilerini depolayan ana veri tabanıdır. Bu veri tabanındaki veriler, belirli Partition'lara ayrılarak organize edilir.

Active Directory Partition'larının Active Directory NTDS.dit veri tabanı ile ilişkisi, Active Directory'nin işleyişinin temelini oluşturur. NTDS.dit, Active Directory'nin tüm verilerini depolayan ana veri tabanıdır ve her Domain Controller'da bulunur. NTDS.dit içindeki veriler, belirli Partition'lara ayrılarak organize edilir. Bu Partition'lar, veri tabanındaki farklı veri türlerini ve yapılandırmaları temsil eder.

NTDS.dit veri tabanının modüler yapısı, Partition'lar sayesinde sağlanır. Bu modüler yapı, veri tabanının yönetimini ve işleyişini daha verimli hale getirir. Partition'lar, veri tabanındaki farklı türdeki verileri ayrı bölümlerde saklayarak, değişikliklerin sadece ilgili Partition'a uygulanabilmesini mümkün kılar. Bu, özellikle büyük ve karmaşık Active Directory ortamlarında veri yönetimini kolaylaştırır.

Her Domain Controller'da bulunan NTDS.dit veri tabanı, Partition'lar arasındaki verileri replikasyon süreçleri ile senkronize eder. Replikasyon süreci, Multi-Master Replication modeli kullanılarak gerçekleştirilir. Bu modelde, her Domain Controller diğer Domain Controller'larla eşit statüde olup, veri tabanında değişiklik yapabilir ve bu değişiklikler diğer Domain Controller'lara replike edilir. Replikasyon süreci, veri tutarlılığını ve güncelliğini sağlar, böylece her Domain Controller, NTDS.dit veri tabanındaki en güncel bilgilere sahip olur.

Partition'ların NTDS.dit ile olan ilişkisi, veri tabanının ölçeklenebilirliğini ve yönetilebilirliğini artırır. Farklı veri türlerinin ayrı Partition'larda saklanması, veri tabanının genel performansını optimize eder. Örneğin, Configuration Partition'daki değişiklikler sadece bu Partition'da yapılır ve bu değişiklikler diğer Partition'ları etkilemez. Bu yapı, veri tabanının daha hızlı ve verimli bir şekilde yönetilmesini sağlar.

NTDS.dit'in Partition'larla olan ilişkisi, veri güvenliği ve bütünlüğü açısından da kritik öneme sahiptir. Veri tabanı, farklı veri türlerini ayrı Partition'larda saklayarak, olası veri bozulmalarının veya hatalarının yayılmasını önler. Ayrıca, bu yapı, veri tabanının yedeklenmesini ve kurtarılmasını kolaylaştırır. Her Partition, kendi içinde bağımsız olarak yönetilebilir, bu da veri bütünlüğünü ve sistem güvenliğini artırır.

1- Schema Partition

Active Directory’de User, Computer ve Group gibi nesneler teknik olarak birer Class’tır. Her Class, o nesne üzerinde hangi alanların bulunabileceğini tanımlar. Bu alanlar, Attribute olarak adlandırılır. Bir nesne oluşturulurken ya da güncellenirken Domain Controller, yalnızca o nesne türü için tanımlı olan alanlar üzerinden işlem yapar. Bu Class ve Attribute tanımları Schema Partition içinde tutulur. Schema Partition, Active Directory nesnelerinde hangi alanların bulunabileceğini ve bu alanlara ne tür değerler girilebileceğini tanımlayan bölümdür. Forest içindeki tüm Domain Controller’lar, nesnelerle ilgili işlemlerde bu tanımı esas alır. Bu nedenle bir Domain Controller’ın kabul ettiği bir nesne yapısı, Forest’taki diğer Domain Controller’lar için de aynıdır.

Örneğin User nesnesinde givenName, sn, mail ve telephoneNumber gibi alanlar bulunur. Bu alanlar User için Schema’da tanımlı olduğu için kullanılabilir. Bir Domain Controller, User nesnesi üzerinde işlem yaparken bu tanımlara göre hareket eder ve tanım dışı bir alan veya uyumsuz bir değerle işlem yapılmasına izin vermez.

⚙️ Schema Değişiklikleri, Replikasyon ve Tutarlılık

Active Directory’de Schema üzerinde yapılacak değişiklikler, sıradan nesne işlemlerinden farklıdır. Yeni bir Class eklemek ya da mevcut bir Class’a yeni bir Attribute tanımlamak gibi işlemler, yalnızca Schema Master FSMO rolünü tutan Domain Controller üzerinden yapılabilir. Bu kısıtlama, Schema’nın Forest genelinde tek ve tutarlı kalmasını sağlamak için uygulanır.

Schema Master üzerinde yapılan değişiklikler doğrudan Schema Partition’a yazılır; Schema Partition, nesne tanımlarını ve geri dönüşü olmayan kuralları içerdiği için tek yazıcıya ihtiyaç duyar ve bu yazma yetkisi Schema Master FSMO rolü tarafından sağlanır.

Değişiklik tamamlandıktan sonra, Active Directory’nin replikasyon mekanizması devreye girer ve güncellenen Schema Partition bilgisi Forest içindeki diğer Domain Controller’lara dağıtılır. Bu süreç sonunda, tüm Domain Controller’lar aynı Schema tanımını kullanmaya devam eder.

Active Directory normalde Multi-Master Replication modeliyle çalışır. Yani Domain Controller’lar nesne oluşturma ve güncelleme işlemlerinde eşit yetkilere sahiptir. Ancak Schema gibi tüm Forest’ı etkileyen kritik yapılarda, değişiklik yetkisi bilinçli olarak tek bir Domain Controller’a, yani Schema Master FSMO rolüne verilmiştir. Bu yaklaşım, çakışmaları önler ve Forest genelinde tutarlılığın korunmasını sağlar.

2- Configuration Partition

Configuration Partition, Active Directory Forest’ında Domain Controller’ların yerleşimi ve replikasyon topolojisiyle ilgili bağlantı bilgilerini tutan bölümdür. Bu Partition içinde, Domain Controller’ların hangi Site içinde yer aldığı, hangi Subnet’lere hizmet verdiği ve diğer Domain Controller’larla hangi replikasyon bağlantıları üzerinden iletişim kuracağı bilgileri bulunur.

Bir Domain Controller çalışmaya başladığında, kendi Site bilgisini, replikasyon ortaklarını ve bağlantı yollarını Configuration Partition’da tanımlı nesnelere bakarak belirler. Aynı bilgiler, Client'ların en yakın Domain Controller’a yönlendirilmesi ve replikasyon trafiğinin doğru bağlantılar üzerinden akması için de kullanılır.

Forest içindeki tüm Domain Controller’lar bu yapılandırma bilgisinin aynısını kullanır. Bu nedenle Site yapısı, replikasyon bağlantıları ve Domain Controller konumları Forest genelinde tutarlı kalır. Active Directory’nin birden fazla Domain Controller olmasına rağmen düzenli çalışmasının sebebi, bu bilgilerin merkezi olarak Configuration Partition’da tutulmasıdır.

⚙️ Configuration Partition'da Değişiklikler, Replikasyon ve Tutarlılık

Active Directory’de Configuration Partition üzerinde yapılan değişiklikler, Forest genelini etkileyen yapılandırma değişiklikleridir. Site ekleme, Subnet tanımlama, Site Link oluşturma veya replikasyon bağlantılarını değiştirme gibi işlemler doğrudan Configuration Partition’a yazılır. Bu değişiklikler, kullanıcı veya bilgisayar nesnelerinden farklı olarak, tüm Domain Controller’ların çalışma şeklini etkiler.

Configuration Partition değişiklikleri, Multi-Master Replication modeliyle yönetilir. Yani yazılabilir bir Domain Controller üzerinden yapılan bir yapılandırma değişikliği, replikasyon süreci tamamlandığında Forest içindeki diğer Domain Controller’lara da dağıtılır. Bu sayede tüm Domain Controller’lar aynı Site yapısını, aynı Subnet eşleşmelerini ve aynı replikasyon topolojisini kullanmaya devam eder.

Bir Site veya Subnet tanımı değiştirildiğinde, Domain Controller’lar bu güncel bilgiyi Configuration Partition’dan okur. Replikasyon ortakları, bağlantı yolları ve Site bazlı replikasyon davranışı bu güncellenmiş yapılandırmaya göre yeniden şekillenir. Aynı şekilde Client'ların hangi Domain Controller’a yönlendirileceği de güncel Site ve Subnet bilgilerine dayanır.

Configuration Partition’ın Forest genelinde replike edilmesi, topoloji ve replikasyon bilgilerinin her Domain Controller’da tutarlı kalmasını sağlar. Bu mekanizma sayesinde Active Directory, farklı fiziksel lokasyonlara yayılmış olsa bile replikasyon trafiğini kontrollü biçimde yönetir ve servis keşfi süreçlerinde çakışma oluşmasını engeller.

3- Domain Partition (Naming Context)

Domain Partition, Active Directory’de bir Domain’e ait kullanıcı, grup ve bilgisayarların hesap kayıtlarının yer aldığı bölümdür. Bu kayıtlar; kullanıcı ve bilgisayar adları, parola durumları, grup üyelikleri, hesapların aktif veya kilitli olup olmadığı gibi Domain içinde günlük olarak yönetilen bilgileri içerir.

Bir kullanıcı, grup veya bilgisayar oluşturulduğunda, bu kayıtlar oluşturulduğu Domain’in Domain Partition’ına eklenir. Parola değiştirme, grup üyeliği düzenleme veya hesabı devre dışı bırakma gibi işlemler de yine aynı Domain Partition üzerinde yapılır. Bu bilgiler yalnızca ilgili Domain kapsamındaki Domain Controller’lar arasında paylaşılır.

Özetle Domain Partition, bir Domain içindeki kullanıcı ve bilgisayar hesaplarıyla ilgili kimlik, güvenlik ve yönetim bilgilerinin bulunduğu alandır.

⚙️ Domain Partition'da Nesne Değişiklikleri, Replikasyon ve Tutarlılık

Domain Partition üzerindeki değişiklikler Multi-Master Replication modeliyle çalışır. Yani bir kullanıcıyı abc.local Domain’inde hangi Domain Controller’da oluşturursan oluştur, bu değişiklik yalnızca abc.local Domain’ine ait diğer Domain Controller’lara yayılır. Forest içindeki diğer Domain'ler bu değişiklikten etkilenmez.

Domain Partition üzerinde yapılan bazı işlemler FSMO koordinasyonu gerektirir. Örneğin kullanıcı oluşturulurken SID üretimi için gerekli RID havuzlarının dağıtımı RID Master tarafından koordine edilir. Parola değişikliklerinin hızlı şekilde yayılması ve zaman uyumu PDC Emulator tarafından sağlanır. Domain’ler arası nesnelerle ilgili bazı kontrol işlemleri ise Infrastructure Master tarafından yürütülür. Ancak bu roller, Domain Partition’ı yöneten merkezi noktalar değildir; yalnızca belirli işlemlerde devreye girer.

4- Application Partition (DomainDnsZones)

Active Directory ortamında DNS, Client'ların ve Domain Controller’ların birbirini bulabilmesi için zorunlu bir altyapıdır. Bir kullanıcı oturum açarken, bir bilgisayar Domaine katılırken veya iki Domain Controller replikasyon başlatırken bu işlemlerin tamamı DNS kayıtları üzerinden yürür. Bu nedenle Active Directory ile ilişkili DNS bilgilerinin doğru, güncel ve tutarlı olması gerekir.

DNS’te tutulan bilgiler iki ana yapıdan oluşur: DNS Zone’lar ve bu Zone’ların içindeki DNS kayıtları. Örneğin abc.local bir DNS Zone’dur ve bu Zone içinde isim–IP eşleşmeleri için A kayıtları, servis keşfi için SRV kayıtları ve yetkili sunucuları tanımlayan NS kayıtları bulunur. Özellikle SRV kayıtları, Client'ların ve servislerin doğru Domain Controller’ı bulabilmesi açısından kritik öneme sahiptir.

Active Directory ile entegre DNS kullanılan ortamlarda bu DNS bilgileri dosya tabanlı olarak değil, Active Directory veritabanı içinde saklanır. Ancak DNS kayıtları; kullanıcı, grup veya bilgisayar hesapları değildir. Aynı şekilde Active Directory’nin site, replikasyon veya servis topolojisini tanımlayan Configuration verileri de değildir. Bu nedenle DNS verileri ne Domain Partition ne de Configuration Partition içinde tutulur.

Bu ihtiyacı karşılamak için Active Directory’de Application Partition adı verilen özel bir yapı kullanılır. DomainDnsZones, bir Domain’e ait DNS Zone’ların ve bu Zone’lar içindeki DNS kayıtlarının tutulduğu Application Partition’dır. Örneğin abc.local Domain’ine ait DNS Zone ve kayıtları DomainDnsZones altında saklanır ve bu bilgiler yalnızca abc.local Domain’ine ait Domain Controller’lar arasında replike edilir.

Bu yapı sayesinde DNS verileri Domain sınırları içinde tutulur ve yalnızca ilgili Domain’i ilgilendiren Domain Controller’lar arasında paylaşılır. Böylece gereksiz replikasyon trafiği oluşmaz ve her Domain kendi DNS kayıtlarını bağımsız şekilde yönetir. DomainDnsZones’un temel görevi, Active Directory’nin Domain düzeyinde ihtiyaç duyduğu DNS bilgilerinin doğru, tutarlı ve kontrollü biçimde dağıtılmasını sağlamaktır.

⚙️ DomainDnsZones Değişiklikleri, Replikasyon ve Tutarlılık

DomainDnsZones içinde yapılan değişiklikler, DNS Zone’lar ve bu Zone’lara ait DNS kayıtları üzerinde gerçekleşir. Yeni bir A kaydı eklenmesi, bir SRV kaydının güncellenmesi veya bir DNS kaydının silinmesi gibi işlemler doğrudan DomainDnsZones Application Partition’a yazılır. Bu değişiklikler kullanıcı, grup veya bilgisayar hesaplarını etkilemez; yalnızca DNS isim çözümleme ve servis keşfi süreçlerine yön verir.

DomainDnsZones, replikasyon açısından Domain kapsamlı çalışır. abc.local Domain’inde herhangi bir Domain Controller üzerinde yapılan bir DNS kaydı değişikliği, yalnızca Domain’ine ait diğer Domain Controller’lara replike edilir. Aynı Forest içinde yer alan diğer Domain’i bu DNS değişikliğini almaz. Bu yaklaşım, DNS verisinin yalnızca ilgili Domain sınırları içinde tutulmasını sağlar.

Replikasyon süreci, Active Directory’nin standart replikasyon mekanizması üzerinden yürütülür. DNS kayıtları için ayrı veya özel bir replikasyon altyapısı bulunmaz. DomainDnsZones içeriği, diğer Active Directory verileri gibi değişiklik bazlı olarak replike edilir ve bu sayede tüm Domain Controller’lar Domain’e ait DNS kayıtlarının aynı kopyasını kullanır.

DomainDnsZones üzerinde yapılan DNS kayıt değişiklikleri için özel bir FSMO rolü yoktur. DNS kayıtları Multi-Master Replication modeliyle yönetilir. Yetkili bir Domain Controller üzerinde yapılan DNS değişikliği, replikasyon tamamlandığında Domain kapsamındaki diğer Domain Controller’lar tarafından da geçerli kabul edilir.

Bu yapı sayesinde Active Directory ortamında DNS bilgileri her Domain Controller’da tutarlı kalır. Client'ların Domain Controller bulma, servis keşfi ve isim çözümleme işlemleri, bağlandıkları Domain Controller’dan bağımsız olarak aynı DNS verisine dayanır. DomainDnsZones’un bu replikasyon modeli, Active Directory’nin öngörülebilir ve stabil şekilde çalışmasını doğrudan destekler.

5- Application Partition (ForestDnsZones)

ForestDnsZones, Active Directory ortamında Forest genelini ilgilendiren DNS Zone’ların ve DNS kayıtlarının tutulduğu Application Partition’dır. Bu yapı, tek bir Domain’e değil, Forest içindeki tüm Domain’ler ve Domain Controller’lar için ortak olan DNS bilgilerini barındırır.

ForestDnsZones’un en bilinen ve en kritik içeriği, _msdcs. DNS Zone’udur. Bu Zone içinde Domain Controller’lara, Global Catalog sunucularına ve Forest genelinde kullanılan servis keşfi mekanizmalarına ait DNS kayıtları bulunur. Özellikle Domain Controller’ların birbirini Forest çapında bulabilmesi ve replikasyon topolojisinin doğru çalışabilmesi bu kayıtlar sayesinde mümkündür.

Active Directory ile entegre DNS kullanılan ortamlarda ForestDnsZones içindeki DNS verileri, dosya tabanlı olarak değil, Active Directory veritabanı içinde saklanır. Ancak bu veriler kullanıcı, grup veya bilgisayar hesapları değildir. Aynı şekilde Domain’e özgü DNS kayıtları da değildir. Bu nedenle ForestDnsZones, Domain Partition veya DomainDnsZones yerine Forest kapsamlı bir Application Partition olarak konumlandırılmıştır.

ForestDnsZones’un temel amacı, Forest genelinde ortak kullanılan DNS bilgilerinin tüm Domain Controller’lar tarafından aynı ve tutarlı şekilde kullanılmasını sağlamaktır. Bu yapı sayesinde farklı Domain’lerde yer alan Domain Controller’lar, Forest seviyesinde gerekli olan DNS kayıtlarına her zaman erişebilir.

⚙️ ForestDnsZones Değişiklikleri, Replikasyon ve Tutarlılık

ForestDnsZones içinde yapılan değişiklikler, Forest genelini ilgilendiren DNS Zone’lar ve bu Zone’lara ait DNS kayıtları üzerinde gerçekleşir. _msdcs Zone’u altındaki bir SRV kaydının eklenmesi, güncellenmesi veya silinmesi gibi işlemler doğrudan ForestDnsZones Application Partition’a yazılır. Bu değişiklikler, tek bir Domain’i değil, Forest içindeki tüm Domain Controller’ların davranışını etkiler.

ForestDnsZones, replikasyon açısından Forest kapsamlı çalışır. ForestDnsZones üzerinde yapılan bir DNS değişikliği, Forest içindeki tüm Domain Controller’lara replike edilir. DomainDnsZones’un aksine, bu replikasyon Domain sınırlarıyla kısıtlı değildir. Forest genelinde servis keşfi ve replikasyon süreçlerinin tutarlı kalabilmesi için bu kapsamlı replikasyon bilinçli olarak tercih edilmiştir.

Replikasyon süreci, Active Directory’nin standart replikasyon mekanizmasını kullanır. DNS kayıtları için ayrı bir replikasyon altyapısı yoktur; ForestDnsZones içeriği de diğer Active Directory verileri gibi değişiklik bazlı olarak replike edilir. Böylece Forest içindeki tüm Domain Controller’lar, Forest seviyesinde gerekli DNS kayıtlarının aynı kopyasına sahip olur.

ForestDnsZones üzerinde yapılan DNS kayıt değişiklikleri için özel bir FSMO rolü bulunmaz. DNS kayıtlarının eklenmesi, güncellenmesi veya silinmesi işlemleri Multi-Master Replication modeliyle yürütülür. Yetkili bir Domain Controller üzerinde yapılan değişiklik, replikasyon tamamlandığında Forest genelindeki diğer Domain Controller’lar tarafından da geçerli kabul edilir.

Bu yapı sayesinde Active Directory ortamında Forest genelinde kullanılan DNS bilgileri her Domain Controller’da tutarlı kalır. Domain Controller’ların birbirini bulması, Global Catalog servislerinin keşfi ve Forest çapındaki replikasyon süreçleri, hangi Domain Controller devrede olursa olsun aynı DNS verisine dayanarak çalışır. ForestDnsZones, çok Domain’li Active Directory mimarisinde tutarlılığın korunmasında kritik bir rol oynar.

ForestDnsZones ve DomainDnsZones Yapılarının Karşılaştırılması

Aşağıdaki tabloda ForestDnsZones ile DomainDnsZones arasındaki yapısal ve operasyonel farklar teknik açıdan özetlenmiştir.

repadmin /showreps Komutu İle Replikasyon Kontrolü

repadmin /showreps kumutu ile 5 adet Active Directory Partition replikasyonunun nasıl işlediği ve hangi DC'ler ile replikasyon yaptığı bilgilerini elde ediyorum. Ayıca; bu komutlardan herangi birisini hangi Server üzerinde çalıştırırsanız, ilgili Server'ın bulunduğu Site içinde replikasyon yaptığı DC'leri görürsünüz. ör. komutumu; SRV001 Host Name'li DC üzerinde çalıştırıldığımda, SRV001 host name'li DC'nin bulunduğu Site içinde hangi DC(ler) ile replike olduğu ve AD Partition replikasyonlarının başarılı mı yoksa başarısız mı olduğu bilgilerini görüyorum.

repadmin /showrepl  Komutu İle Replikasyon Kontrolü

Yukarıdaki komuta ek olarak repadmin /showrepl kumutu, herhangi bir DC üzerinde çalıştırıldığında, belirtilen DC'nin, bulunduğu Site içinde hangi DC(ler) ile replike olduğu bilgisini verir.

Ör. repadmin /showrepl SRV002 komutunu SRV001 host name'li DC üzerinde çalıştırdığımızda, SRV002 host name'li DC'min hangi Domain Controller'lar ile replike olduğu ve replikasyonların nasıl işlediği bilgilerini elde ederim.

repadmin /syncall /AdeP Komutu İle Manuel Replikasyon

Normal şartlarda Active Directory Sites and Services üzerinden Domain Controller'lar arasındaki replikasyonları yönebilirsiniz ancak buradaki replikasyon trafiğini manuel olarak yürütmek için, tüm DC'lere üzerinde tek tek Replicate Now seçeneğini seçmeniz gerekmektedir.





repadmin /Syncall /AdeP komutu yerine, aşağıdaki komutu da kullanabilirsiniz. Bu komutun kullanımı, dağıtık yapıda Active Directory Site yapınız varsa, Active Directory'deki replikasyon sorunlarını çözmek veya veri tutarlılığını sağlamak için idealdir. Bu komut, tüm Domain Controller'lar arasında tam ve zorunlu bir replikasyon işlemi gerçekleştirerek, veri uyuşmazlıklarının önüne geçer ve Active Directory ortamındaki tüm Domain Controller'lar arasında replikasyonu zorlar. Her bir Domain Controller için repadmin /syncall komutu ayrı ayrı çalıştırılır.

Komutun Çalışma Prensibi

Bu komut, Active Directory ortamındaki tüm Domain Controller'lar arasında tam bir replikasyon işlemi başlatır. İşlem şu adımları takip eder:

1- Get-ADDomainController -Filter * ile tüm Domain Controller'lar alınır ve isimleri bir liste olarak döndürülür.

2- Foreach-Object döngüsü ile her bir Domain Controller ismi için repadmin /syncall komutu çalıştırılır. repadmin /syncall, belirtilen Domain Controller'ın tüm replikasyon partnerleri ile replikasyonu zorlar.

3- Replikasyon işlemi, Domain'in Distinguished Name'i kullanılarak yapılır ve belirtilen parametrelerle (/AdePq) detaylandırılır.

• /A: Tüm Naming Context'ler için replikasyonu zorlar.
• /d: Replikasyon hakkında ayrıntılı bilgi verir.
• /e: Tüm site'lar arasında replikasyonu zorlar.
• /P: Yalnızca giden bağlantılar için PUSH Replication ile replikasyonu başlatır.
• /q: Komutun çıktısını sessiz moda alır, yalnızca hata mesajlarını gösterir.

Push Replication, aslında Active Directory'nin doğal çalışma yöntemlerinden biri değildir; Active Directory varsayılan olarak Pull Replication yöntemini kullanır. Ancak, bazı durumlarda belirli bir Domain Controller'dan diğerlerine verileri Push etmek gerekebilir. Bu tür senaryolarda, Push Replication komutları kullanarak, belirli bir DC'nin değişikliklerini hemen diğer DC'lere göndermek isteyebilirsiniz.

Neden Push Replication Kullanılır?

» Acil Durumlar: Bir DC'de yapılan kritik değişikliklerin hızlıca diğer DC'lere yayılması gerekiyorsa, manuel olarak bir Push Replication başlatarak bu süreci hızlandırabilirsiniz.

» Yapısal Değişiklikler: Özellikle şema değişiklikleri veya büyük yapısal değişiklikler gibi önemli güncellemelerde, bu değişikliklerin tüm DC'lere hemen yayılması istenebilir.

» Eşzamanlılık: Belirli bir DC'deki verilerin acilen tüm diğer DC'lerle uyumlu hale getirilmesi gerektiğinde, Push Replication faydalı olabilir.

Bundan dolayı da Push Replication başlatmak, özel durumlarda veri tutarlılığını hızla sağlamak için kullanılabilir.

Teknik Detaylar

» Replikasyon: Active Directory ortamında verilerin tutarlı olmasını sağlamak için Domain Controller'lar arasında veri değişimidir. Replikasyon, değişikliklerin tüm Domain Controller'lara yayılmasını sağlar.

» Domain Controller: Active Directory veri tabanını barındıran ve yönetim işlemlerini yürüten sunuculardır. Birden fazla Domain Controller, veri bütünlüğünü ve erişilebilirliği artırır.

» Distinguished Name (DN): Active Directory'deki objelerin benzersiz kimlikleridir. Active Directory Distinguished Name (DN), objelerin hiyerarşik konumunu belirtir.

Bu komut yerine repadmin /syncall /AdePq komutununun kullanımı, yalnızca mevcut Domain Controller'ın tüm replikasyon partnerleri ile replikasyonu başlatır. Diğer Domain Controller'lara etki etmez. Bu nedenle, daha dar kapsamlı bir replikasyon işlemi gerçekleştirir.

Bu yöntemle aynı zamanda tüm AD Partition'ları yerine, sadece istenen herhangi bir AD Partition'ın replikasyonu da sağlabilmektedir.

Active Directory Application Partition ForestDnsZones Replikasyonu

Foret ortamındaki tüm Domain Controller'lar, Application Partition ForestDnsZones replikasyonunu başarılı bir şekilde gerçekleştirdiler.



Active Directory Application Partition DomainDnsZones Replikasyonu
Foret ortamındaki tüm Domain Controller'lar, Application Partition DomainDnsZones replikasyonunu başarılı bir şekilde gerçekleştirdiler.



Active Directory Schema Partition Replikasyonu
Foret ortamındaki tüm Domain Controller'lar, Schema Partition replikasyonunu başarılı bir şekilde gerçekleştirdiler.



Active Directory Configuration Partition Replikasyonu
Foret ortamındaki tüm Domain Controller'lar, Configuration Partition replikasyonunu başarılı bir şekilde gerçekleştirdiler.



Active Directory Domain Partition Replikasyonu
Forest ortamındaki tüm Domain Controller'lar, Domain Partition replikasyonunu başarılı bir şekilde gerçekleştirdiler.



Bu makalede, Active Directory içindeki Partition yapılarının nasıl organize edildiğini ve bu yapılar arasında Domain Controller'lar üzerinden gerçekleşen replikasyon süreçlerinin mantığını detaylıca inceledik. Schema, Configuration ve Domain Partition'ların birbirinden ayrılması sadece yapısal bir fark değil; aynı zamanda replikasyonun hedefini, yönünü ve kapsadığı veri bütünlüğünü belirleyen temel bir tasarım kararıdır.

Özellikle farklı sitelarda bulunan Domain Controller'lar arasında yapılan replikasyonun ne şekilde optimize edildiğini, hangi replikasyon bağlantılarının nereden üretildiğini ve bu bağlantıların NTDS Settings altındaki Site Link yapısıyla nasıl ilişkilendirildiğini adım adım aktarmaya çalıştım. Her replikasyon işleminin ardında aslında Active Directory Topology'nin karar verdiği bağlantı grafiği, Knowledge Consistency Checker (KCC) algoritması ve Site bazlı maliyet hesaplamaları yer alıyor.

Ayrıca her bir Partition'ın replikasyon davranışının farklı olmasının sebeplerine de değindik. Global Catalog sunucularının yalnızca belirli Attribute Set'lerini barındırması, Configuration verisinin forest genelinde paylaşılması ya da Domain'e özgü verilerin yalnızca o Domain'deki controller'lara gönderilmesi gibi detaylar, bu farklılığın temelini oluşturuyor.

Yüzeyde sadece birkaç klasörden ibaretmiş gibi görünen bu yapıların, aslında Active Directory'nin dağıtık doğasında nasıl bir denge unsuru olduğunu fark ettiğinde sistemin derinliği çok daha görünür hale geliyor. Her bir Partition, tek başına birimler arası bütünlüğü ve yönetimi ayakta tutan küçük ama etkili bir yapı taşı gibi davranıyor. Bu yapıların nasıl çalıştığını anlamadan replikasyon sürecine dair doğru yorum yapmak pek mümkün olmuyor.

Faydalı olması dileğiyle...