Windows Server 2019'da Active Directory Sites and Services Yapılandırma

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.

Özetle 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. 

Active Directory Partition Kavramı

Active Directory NTDS.dit Database (veri tabanı) içinde mantıksal olarak ayrılmış 5 adet Active Directory Partition bulunmaktadır. Domain ya da Forest ortamınızdaki tüm Domain Controller'ların güncel tutulması için, bu 5 adet Active Directory Partition kopyasının ortamdaki tüm Domain Controller'larda aynı güncellikte tutulması şarttır. Burada değineceğim konular ön bilgi niteliğinde olup, makalemin ilerleyen kısımlarında uygulama kısımlarına da değineceğim. Bu bölümler;

1- Schema Partition
2- Configuration Partition
3- Domain Partition (Naming Context)
4- Application Partition - DomainDnsZones
5- Application Partition - ForestDnsZones

⭐ 1- Schema Partition

📌 Temel Yapı Taşı ve İşleyişi

Active Directory'nin temel yapı taşlarından biri olan Schema Partition, tüm Active Directory Forest'ta tutarlılığı sağlamak için kritik bir rol oynar. Bu Partition, Active Directory'de tanımlanan tüm Class (Object) türlerini ve bu Class türlerinin sahip olabileceği tüm Attribute bilgilerini içerir. Schema Partition, Active Directory'nin nasıl çalışacağını belirler ve tüm Class türleri ile bunların sahip olabileceği Attribute'leri tanımlar.

Örneğin, bir User Class'ı için Name, Surname, E-mail gibi saklanabilecek Attribute bilgilerini içerir ve bu bilgilerin Text (metin), Number (sayı), Date (tarih) gibi hangi veri tipinde olacağını Schema Partition belirler. Bu tanımlamalar, Active Directory'nin işleyişini ve yapılandırmasını standart hale getirir ve tutarlılık sağlar.

📌 Schema Değişiklilleri, Replikasyon ve Tutarlılık

Schema yapısındaki değişiklikler, yalnızca Schema Master FSMO (Flexible Single Master Operations) rolünü tutan Domain Controller üzerinden gerçekleştirilir. Schema Master FSMO rolü tarafından yapılan bu değişiklikler, Schema Partition'a yansıtılır ve sonrasında da Multi-Master Replication modeli, kendi iç mekanizamasında FSMO rolü ve Partition'dan bağımsız olarak bir replikasyon süreci başlatarak, tüm Domain Controller'da Schema Partition güncelliği sağlanmış olur. Multi-Master Replication modeli, her bir Domain Controller'ın eşit olduğu ve hepsinin değişiklik yapabildiği bir sistemdir. Bu model, Schema değişikliklerinin merkezi olarak yönetilmesini sağlar ve tüm Forest genelinde tutarlılığı korur.

📌 Schema Master FSMO Rolü ve Schema Partition İlişkisi

Active Directory'nin temel yapı taşlarından biri olan Schema Master FSMO rolü, şema değişikliklerinin yönetilmesinde kritik bir rol oynar. Schema Master FSMO rolü, tüm Active Directory Forest'ında Schema Partition'da yapılacak değişiklikleri kontrol eden ve yöneten tek noktadır. Bu rol, şema değişikliklerinin merkezi olarak yönetilmesini sağlar.

Schema değişiklikleri, Active Directory'nin nasıl çalışacağını belirleyen kuralları içerir. Örneğin, yeni bir Class türü eklemek veya mevcut bir Class türüne yeni bir Attribute eklemek gibi değişiklikler, sadece Schema Master FSMO rolünü tutan Domain Controller'da yapılabilir. Bu değişiklikler Schema Master tarafından Schema Partition'a yansıtılır ve ardından Multi-Master Replication modeli ile tüm Domain Controller'lara replike edilir. Bu süreç, tüm Active Directory ortamında tutarlılığın korunmasını sağlar.

⭐ 2- Configuration Partition

📌 Temel Yapı Taşı ve İşleyişi

Configuration Partition, Active Directory yapısının merkezi bir bileşeni olup, tüm Forest genelinde geçerli olan ve Active Directory'nin çalışma şeklini belirleyen kritik yapılandırma bilgilerini içerir. Bu Partition, Active Directory genel yapılandırma ayarları, site-topoloji bilgileri, replikasyon ayarları, hizmet konfigürasyonları ve güvenlik ilişkileri bilgilerini tutar. Configuration Partition, Active Directory'nin işleyişini kontrol eden ana şema olarak düşünülebilir.

Configuration Partition, geniş bir veri yelpazesi içerir ve bu veri, farklı nesne türleri ve bunlara bağlı ilişkiler üzerinden organize edilir.

Bu Partition'da saklanan bazı kritik yapılandırma verileri şunlardır:

✅ 1- Active Directory Topolojisi

➜ Site ve Subnet nesneleri: Active Directory’deki fiziksel yapıyı tanımlar ve replikasyonun optimize edilmesi için kullanılır.

➜ SiteLink ve Connection Object nesneleri: Farklı Site'lar arasında veri replikasyonunun nasıl gerçekleşeceğini tanımlar. Bu bilgiler, replikasyon trafiğinin yönlendirilmesinde ve maliyetlerinin belirlenmesinde önemli rol oynar.

✅ 2- Replikasyon Bilgileri

➜ NTDS Settings: Her Domain Controller’a ait replikasyon ortaklarını ve replikasyon bağlantılarını içerir. Replikasyonun hangi aralıklarla yapılacağı, veri akışının nasıl yönlendirileceği gibi kritik ayarları barındırır.

➜ KCC (Knowledge Consistency Checker) Ayarları: Replikasyon topolojisinin otomatik olarak oluşturulmasını ve optimize edilmesini sağlar. KCC, Configuration Partition’daki bilgileri kullanarak her Domain Controller için en iyi replikasyon yolunu belirler.

✅ 3- Hizmet Yapılandırmaları

➜ Global Catalog Konfigürasyonu: Hangi Domain Controller'ların Global Catalog (GC) rolünü üstlendiği ve bu sunucuların nasıl konumlandırıldığı bilgilerini içerir.

➜ DNS Entegrasyonu: Active Directory Integrated DNS Zone ve SRV kayıtları yönetimi ve DNS Namespace ile ilgili yapılandırmaları içerir.

➥ Active Directory Integrated DNS Zones

Active Directory Integrated DNS Zones, DNS bilgilerini Active Directory veritabanı içinde saklayan ve replikasyonunu Active Directory replikasyon mekanizmasıyla yapan DNS Zone'larıdır. Bu yapı, DNS ve Active Directory'nin sıkı entegrasyonunu sağlar. Bu entegrasyonun getirdiği bazı avantajlar şunlardır:

a- Güvenli Replikasyon: DNS Zone bilgileri, Active Directory replikasyon mekanizması kullanılarak Domain Controller'lar arasında replicate edilir. Bu, DNS bilgilerini replikasyon için ayrı bir mekanizma kullanmaya gerek kalmadan güvenli bir şekilde dağıtır.

b- Yüksek Erişilebilirlik: DNS bilgileri, tüm Domain Controller'larda tutulduğundan, bir Domain Controller devre dışı kalsa bile DNS bilgileri diğer Domain Controller'lar üzerinden erişilebilir durumda kalır. Bu, sistemin sürekli çalışmasını sağlar.

c- DNS Zone Replikasyonu: DNS Zones, Active Directory veritabanında saklandığı için, DNS bilgilerinin replikasyonu Active Directory replikasyon trafiğiyle birlikte gerçekleşir. Bu, DNS bilgilerinin tüm Domain Controller'larda güncel kalmasını sağlar.

➥ SRV (Service Locator) Kayıtları

SRV kayıtları, Active Directory’nin çalışması için kritik olan hizmetlerin (örneğin, LDAP, Kerberos) nerede ve hangi portlar üzerinden erişilebileceğini tanımlar. Bu kayıtlar, DNS içinde saklanır ve DNS istemcileri bu hizmetlerin nerede bulunduğunu öğrenmek için bu kayıtları kullanır. Configuration Partition, SRV kayıtlarının nasıl yapılandırılacağını belirler. Örneğin:

a- LDAP Hizmeti: _ldap._tcp.dc._msdcs. SRV kaydı, LDAP hizmetinin hangi Domain Controller üzerinde çalıştığını ve hangi Port'u kullandığını tanımlar.

b- Kerberos Hizmeti: _kerberos._tcp.dc._msdcs. SRV kaydı, Kerberos kimlik doğrulama hizmetinin hangi Domain Controller üzerinde çalıştığını belirtir.

➥ DNS Namespace Yapılandırmaları

DNS Namespace, bir organizasyonun adlandırma yapısını belirler ve tüm DNS adlarının nasıl organize edileceğini tanımlar. Configuration Partition, DNS Namespace’in nasıl yapılandırılacağını içerir. Bu yapılandırma, Domain adlarının, alt Domain'lerin ve ilgili DNS Zone'ların nasıl organize edileceğini ve hangi kurallara göre yönetileceğini belirler.

a- Domain Adı Hiyerarşisi: Ana Domain adları ve alt Domain adları (örneğin, firatboyan.com, sub.firatboyan.com) bu Namespace kapsamında düzenlenir.

b- DNS Delegasyonu: Üst düzey DNS Zone’ların alt Zones’lara nasıl delege edileceği ve bu delegasyonun nasıl yönetileceği bilgisi burada yer alır.

Bu DNS Entegrasyonu yapısı, Active Directory’nin hem ad çözümleme hizmetlerini hem de kimlik doğrulama süreçlerini yönetir ve optimize eder. Configuration Partition bu bilgileri saklayarak, tüm Domain Controller'ların aynı DNS yapılandırmalarını kullanmasını sağlar ve sistemin bütünlüğünü korur.

➜ Uygulama Yayınlama: Exchange Server gibi Active Directory ile entegre çalışan uygulamaların konfigürasyon bilgilerini içerir.

➥ Exchange Server Hizmet Yayınlama

Exchange Server, Active Directory üzerinden çeşitli hizmetleri yayınlar. Bu yayınlama süreci, Active Directory’nin Configuration Partition’ında saklanan bilgileri kullanarak gerçekleştirilir. Örneğin bir Mailbox Server rolüne sahip sunucunun konumu ve bu sunucunun hangi AD Site yapısı içinde bulunduğu ve Transport hizmetlerinin nerede ve nasıl çalışacağını tanımlayan yapılandırma bilgileri bu Partition’da tutulur.

Ayrıca Port 25 SMTP, Port 443 OWA ve EWS gibi Exchange Server’a ait servis bağlantı noktaları ve sunucu rollerinin konumları da burada tanımlanır. Böylece bu bağlantı noktalarının hangi sunucularda kullanılacağı, Configuration Partition’da tanımlanır ve bu bilgiler, Client ve diğer Server'ların doğru hizmete ulaşmasını sağlar.

➥ SRV Kayıtları ve DNS Yayınlama

Exchange Server, Active Directory ile birlikte çalışan bir uygulama olarak SRV kayıtlarını kullanır. SRV kayıtları, belirli bir hizmetin (örneğin, SMTP veya Autodiscover) hangi sunucuda çalıştığını ve hangi bağlantı noktası üzerinden erişileceğini belirler. Bu kayıtlar Configuration Partition’da saklanır ve DNS ile birlikte tüm Domain Controller'lara replicate edilir. Bu sayede, istemciler doğru Exchange Server hizmetine yönlendirilir.

➥ LDAP Bağlantıları ve Kullanıcı Doğrulama

Exchange Server, Active Directory’nin LDAP (Lightweight Directory Access Protocol) hizmeti aracılığıyla kullanıcı bilgilerini ve adres defterlerini yayınlar. Configuration Partition, Exchange Server’ın bu LDAP bağlantıları için hangi Domain Controller'ları kullanacağını ve bu bağlantıların nasıl yapılandırılacağını tanımlar. Örneğin, Global Address List (GAL) yapılandırması ve kullanıcı postalarının yönetimi için gerekli LDAP ayarları burada bulunur.

➥ Event Logs (Olay Günlükleri) ve Hizmet Entegrasyonu

Exchange Server, Active Directory ile entegre çalıştığından, bu entegrasyona dair kritik yapılandırma bilgileri Configuration Partition’da saklanır. Örneğin, Exchange Server'ın hangi olay günlüklerine erişebileceği ve bu günlüklerde hangi verilerin kaydedileceği bilgileri, Configuration Partition’da yapılandırılır. Bu yapılandırmalar, hizmetlerin doğru çalışmasını ve olayların merkezi olarak izlenmesini sağlar.

✅ 4- FSMO (Flexible Single Master Operations) Rolleri

➜ Schema Master ve Domain Naming Master gibi FSMO rollerinin hangi Domain Controller’lara atandığını gösterir. Bu rollerin merkezi yönetimi ve replikasyon işlemleri Configuration Partition üzerinden takip edilir.

✅ 5- Forest Trust Bilgileri

➜ Forest’lar arası güven ilişkilerini (Trusts) içerir. Bu ilişkiler, kullanıcıların ve hizmetlerin farklı Forest’larda nasıl doğrulanacağını belirler.

📌 Configuration Değişiklikleri, Replikasyon ve Tutarlılık

Configuration yapısındaki değişiklikler, genellikle Domain Naming Master FSMO (Flexible Single Master Operations) rolünü tutan Domain Controller üzerinden gerçekleştirilir. Bu rol tarafından yapılan değişiklikler, Configuration Partition'a yansıtılır ve sonrasında da Multi-Master Replication modeli, kendi iç mekanizmasında FSMO rolü ve Partition'dan bağımsız olarak bir replikasyon süreci başlatarak, tüm Domain Controller'da Configuration Partition güncelliği sağlanmış olur. Multi-Master Replication modeli, her bir Domain Controller'ın eşit olduğu ve hepsinin değişiklik yapabildiği bir sistemdir. Bu model, Configuration değişikliklerinin merkezi olarak yönetilmesini sağlar ve tüm Forest genelinde tutarlılığı korur.

📌 Domain Naming Master FSMO Rolü ve Configuration Partition İlişkisi

Active Directory'nin temel yapı taşlarından biri olan Domain Naming Master FSMO rolü, Configuration değişikliklerinin yönetilmesinde kritik bir rol oynar. Domain Naming Master FSMO rolü, tüm Active Directory Forest'ında Configuration Partition'da yapılacak değişiklikleri kontrol eden ve yöneten tek noktadır. Bu rol, Configuration değişikliklerinin merkezi olarak yönetilmesini sağlar.

Configuration değişiklikleri, Active Directory'nin genel yapılandırma kurallarını içerir. Örneğin, yeni bir domain eklemek veya bir site topolojisini değiştirmek gibi değişiklikler, sadece Domain Naming Master FSMO rolünü tutan Domain Controller'da yapılabilir. Bu değişiklikler Domain Naming Master tarafından Configuration Partition'a yansıtılır ve ardından Multi-Master Replication modeli ile tüm Domain Controller'lara replike edilir. Bu süreç, tüm Active Directory ortamında tutarlılığın korunmasını sağlar.

⭐ 3- Domain Partition (Namig Context)

📌 Temel Yapı Taşı ve İşleyişi

Active Directory'nin temel yapı taşlarından biri olan Domain Partition, her domain içindeki tüm kullanıcı, grup, bilgisayar ve diğer nesne verilerini saklamak için kritik bir rol oynar. Bu Partition, her Domain Controller'da bulunan NTDS.dit veri tabanının büyük bir bölümünü oluşturur ve domain'e özgü tüm bilgileri içerir. Domain Partition, kullanıcı hesaplarından grup politikalarına kadar geniş bir yelpazeyi kapsar ve günlük yönetim ve operasyonlar için oldukça önemlidir. Bu tanımlamalar, Active Directory'nin işleyişini ve yapılandırmasını standart hale getirir ve tutarlılık sağlar.

📌 Domain Değişiklikleri, Replikasyon ve Tutarlılık

Domain yapısındaki değişiklikler, genellikle RID Master FSMO (Flexible Single Master Operations), PDC Emulator FSMO ve Infrastructure Master FSMO rollerini tutan Domain Controller'lar üzerinden gerçekleştirilir. Bu roller tarafından yapılan değişiklikler, Domain Partition'a yansıtılır ve sonrasında da Multi-Master Replication modeli, kendi iç mekanizmasında FSMO rolü ve Partition'dan bağımsız olarak bir replikasyon süreci başlatarak, tüm Domain Controller'da Domain Partition güncelliği sağlanmış olur. Multi-Master Replication modeli, her bir Domain Controller'ın eşit olduğu ve hepsinin değişiklik yapabildiği bir sistemdir. Bu model, Domain değişikliklerinin merkezi olarak yönetilmesini sağlar ve tüm Forest genelinde tutarlılığı korur.

📌 RID Master, PDC Emulator ve Infrastructure Master FSMO Rolleri ve Domain Partition İlişkisi

Active Directory'nin temel yapı taşlarından biri olan RID Master, PDC Emulator ve Infrastructure Master FSMO rolleri, Domain Partition'daki değişikliklerin yönetilmesinde kritik roller oynar. Bu roller, tüm Active Directory Forest'ında Domain Partition'da yapılacak değişiklikleri kontrol eden ve yöneten noktalardır. Bu roller, Domain değişikliklerinin merkezi olarak yönetilmesini sağlar.

Domain değişiklikleri, Active Directory'nin genel işleyiş kurallarını içerir. Örneğin, yeni bir kullanıcı eklemek, bir grubun üyeliğini değiştirmek veya bir bilgisayarı ortamdan kaldırmak gibi değişiklikler, bu FSMO rollerini tutan Domain Controller'lar üzerinden yapılabilir. Bu değişiklikler ilgili FSMO rolleri tarafından Domain Partition'a yansıtılır ve ardından Multi-Master Replication modeli ile tüm Domain Controller'lara replike edilir. Bu süreç, tüm Active Directory ortamında tutarlılığın korunmasını sağlar.

⭐ 4- Application Partition

⭐ 5- Application Partition

Active Directory'de Application Partition'lar, belirli verilerin ve uygulamaların replikasyonu için kullanılan özel Partition'lardır. Bu yapı, verilerin daha esnek, güvenli ve kontrollü bir şekilde yönetilmesini sağlar. Özellikle büyük ölçekli uygulamalar ve hizmetler için kritik öneme sahip olan Application Partition'lar, veri yönetimini optimize eder ve Network üzerindeki yükü azaltır. Bu Partition'lar, tüm Domain Controller'lar (DC) arasında değil, yalnızca belirli DC'ler arasında replikasyon yapar. Bu yapı, verilerin daha esnek ve kontrollü bir şekilde yönetilmesine olanak tanır.  

Replikasyon Türleri, Süreleri ve Protokolleri

Domain Controller'lar arası replikasyonlar, Intersite Replication (farklı Site'lar arası replikasyon) ve Intersite Replication (Site içi replikasyon) ve Urgent Replication olmak üzere 3'e ayrılır. Burada değineceğim konular ön bilgi niteliğinde olup, makalemin ilerleyen kısımlarında uygulama kısımlarına da değineceğim.

1- Intersite Replication

Aynı Site içindeki Domain Controller'ların birbirleri arasında gerçekleştirdikleri replikasyondur ve replikasyonlar, varsayılan olarak 5 dakikada bir gerçekleşir. Aynı Site içindeki Domain Controller'lar arasında RPC Over IP protokolü üzerinden gerçekleşmektedir. Replikasyondaki Data'lar, sıkıştırılmadan iletilir.

2- Intrasite Replication

Farklı Site'lardaki Domain Controller'lar arasındaki replikasyondur. Bu replikasyon türünde replikasyonlar, Birdgehead Server'lar arasında gerçekleştirilir ve replikasyonlar, varsayılan olarak 180 dakikada bir gerçekleşir. Farklı Site'lar arasındaki Domain Controller'lar arasında RPC Over IP ya da SMTP (Simple Mail Transfer Protocol) üzerinden gerçekleşmektedir. Replikasyondaki Data'lar, sıkıştırılarak iletilir.

3- Urgent Replication

Adından da anlaşılağı üzere, Active Directory nesnelerinin güvenlik ile ilgili Attiribute'larında değişiklik olması durumunda eplikasyon süresi beklenmeden gerçekleştirilen bir replikasyon türü olup, aşağıdaki durumlar söz konusu ise replikasyon süreleri beklenmeden replikasyon, anında tetiklenir;

👉 Account Lockout Policy
👉 Domain Password Policy
👉 Local Security Authority
👉 Domain Controller bilgisayar hesabının değişmesi  

Active Directory Site Yapısı ve Ortamı

Hedeflediğim ve kurmak istediğim Active Directory Site yapısı ve ortamı aşağıdaki gibi olacaktır.

1- Site Bilgisi

✔ Istanbul-Site.
✔ Izmir-Site.
✔ Antalya-Site.

2- Domain Controller Bilgisi

✔ Istanbul-Site, 2 Domain Controller.
✔ Izmir-Site, 1 Domain Controller.
✔ Antalya-Site, 1 Domain Controller'a sahip olacaktır.

3- Network Bilgisi

✔ 10.10.10.0 /24 (Istanbul-Site)
✔ 10.10.20.0 /24 (Izmir-Site)
✔ 10.10.30.0 /24 (Antalya-Site)






 

Mevcut Active Directory Site Yapısı ve Ortam Bilgisi

Mevcut Active Directory Site yapım ile ilgili detaylı bilgilere erişmek için, aşağıdaki PowerShell Script'i kullanıyorum.

Görüldüğü gibi tüm Domain Controller'lar, varsayılan site olan Default-First-Site-Name içinde yer almaktadırlar. Makalemin ilerleyen kısımlarında diğer detaylara da değineceğim. Mevcut Active Directory Site yapım ile ilgili detaylı bilgilere erişerek gerekli bilgileri edindikten sonra aşağıdaki PowerShell komutu ile de Domain ortamımdaki Domain Controller'ların Hostname, İşletim sistemi versiyonu ve IP adresi bilgilerini görebiliyoruz.

Active Directory Site Yapılandırması

Active Directory Site yapılandırma işlemi, Active Directory Domains and Services rolünün kurulumu ve Domain ortamının kurulumu ile yüklenen, Active Directory yönetim araçlarından birisi olan Active Directory Sites and Services üzerinden yapılmaktadır.

1- Active Directory Site yapılandırma işlemi için Active Directory Sites and Services'ı açıyorum.



2- Active Directory Site yapılandırması için öncelikle ilk tercih edilen yöntem olan, varsayılan Default-First-Site-Name Site isim bilgisini değiştirmek olarak. Bunun için site üzerinde sağ tıklıyor, Rename seçeneğini seçiyor, Istanbul-Site adını veriyorum.





3- Varsayılan Default-First-Site-Name Site adını Istanbul-Site olarak değiştirdikten sonra sıra, diğer Site'larımı oluşturmaya geldi.

3.1- 2. Site'ımı oluşturmak için en yukarıdaki Sites üzerinde sağ tıklayarak New > Site seçeneklerini tıklıyorum.



3.2- Açılan New Object - Site penceresinde Antalya-Site adını veriyor, DEFAULTIPSITELINK'i seçerek OK butonuna basarak pencereyi kapartıyorum.





4- Oluşturduğum Antalya-Site içine, adını Istanbul-Site olarak değiştirdiğim, eski varsayılan Default-First-Site-Name içindeki Domain Controller'lar üzerinde sağ tıklayarak Move... seçeneğini seçiyorum.



4.1- Açılan Move Server penceresinde Antalya-Site'ı seçerek OK butonuna basarak pencereyi kapartıyorum.



4.2- Görüldüğü gibi, SRV004x Hostname'li Domain Controller'ı Antalya-Site'ı içine taşıdık.



5- 3. Site'ımı oluşturmak için yine en yukarıdaki Sites üzerinde sağ tıklayarak New > Site seçeneklerini tıklıyorum.



5.1- Açılan New Object - Site penceresinde Izmir-Site adını veriyor, DEFAULTIPSITELINK'i seçerek OK butonuna basarak pencereyi kapartıyorum.

NOT: SITE LINK kavramına makalemin ilerleyen kısımlarında değineceğim.



5.2- Oluşturduğum Izmir-Site içine, adını Istanbul-Site olarak değiştirdiğim eski varsayılan Default-First-Site-Name içindeki Domain Controller'lar üzerinde sağ tıklayarak Move... seçeneğini seçiyorum.



5.3- Görüldüğü gibi, SRV003x Hostname'li Domain Controller'ı Izmir-Site'ı içine taşıdık.

NOT: Taşıma işlemlerini sürükle-bırak yöntemi ile iligli Site içine taşımak suretiyle de gerçekleştirebilirsiniz.



6- Görüldüğü gibi, Active Directory Sites and Services içinde üç ayrı Site'ı oluşturarak, her Site içinde bulunması gereken Domain Controller'ları ilgili Site'lara taşıdık.

Subnet Kavramı

Active Directory Sites and Services içinde üç ayrı Site'ı oluşturarak, her Site içinde bulunması gereken Domain Controller'ları ilgili Site'lara taşıdıktan sonra sıra, Site'larımızı Network ID'lerine göre de ayırmak olacak. Site'larımızın Network ID bilgilerine göre ayrılması ile Client'ların sadece kendi Network'lerindeki Domain Controller'larla ile iletişim kurması sağlanmış olacak ki zaten Site yapısı kurulum işlemi de bu amaç doğrultusunda yapılıyor.

7- Site'larımızın Network ID'lerine göre ayrılması için Subnets üzerinde sağ tıklayarak New Subnet... seçeneğini seçiyorum.



7.1- Prefix bölümünde sırasıyla tüm Site'larımızın Network ID bilgileri, Subnet Mask değerleri ile birlikte tanımlanacaktır. Öncelikle Istanbul-Site için 10.10.10.0/24 yazarak Select a site object for this prefix alanında Istanbul-Site'ı seçiyor, OK butonuna basarak pencereyi kapartıyorum.



7.2- Diğer Site'lar içinde sırasıyla Subnets üzerinde sağ tıklayarak New Subnet... seçeneğini seçiyorum ve Izmir-Site için 10.10.20.0/24, Antalya-Site için 10.10.30.0/24 yazarak Select a site object for this prefix alanında ilgili Site'ları seçerek Subnet ekleme işlemlerini tamamlıyorum.

Site Link Kavramı

Site Link, Siteler arasındaki fiziksel bağlantıyı temsil eden, Site'lar arasındaki replikasyonu ve bunun yönetimini sağlayan nesnedir. Varsayılan Site Link, DEFAULTIPSITELINK'tir. Hatırlarsanız, Site'larımızı oluştururken Site Link seçerek oluşturabiliyorduk ve seçtiğimiz bu Site Link, varsayılan Site Link olan DEFAULTIPSITELINK idi. Şimdi sıra, ortamımızda birden fazla Site kurulu olduğu için, Site'lar arasındaki replikasyonu ve bunun yönetimini sağlayacağımız diğer Site Link'leri oluşturmaya geldi. Oluşturacağım Site Link modeline göre repliasyon trafiği, sadece Merkez ofis ve şubeler arasında olacaktır. Şubelerin kendi arasında replikasyon trafiği oluşmayacaktır.








8- Makalemin başındaki şemada da belirttiğim gibi, ortamımızda 3 adet Site bulunuyor ve her 3'ü de DEFAULTIPSITELINK içinde yer alıyor. Şimdi bu Site'ları ayrı Site Link'lere ayıracağız. Bunun için Intersite-Site Trasnaports altındaki IP üzerinde sağ tıklayarak New Site Link... seçeneğini seçiyorm.



8.1- Açılan pencerede Site Link'ime Istanbul-Antalya adını vererek, sol bölümde bu Site Link içinde bulunacak Site'larımı Add >> butonuna basarak Sites in this site link alanına ekliyor, OK butonuna basarak pencereyi kapartıyorum.

Bilgi!: Bir Site Link içinde tek bir Site barındıramazsınız. Bir Site Link içinde en az 2 Site bulunmalıdır. 



8.2- Istanbul-Antalya Site Link'ini oluşturduktan sonra sıra, diğer Site Link'imi oluşturmaya geldi. Ancak burada DEFAULTIPSITELINK'i yeniden adlandıradak, bu Site Link üzerinde de düzenleme yapabilirim. Bunun için DEFAULTIPSITELINK üzerinde sağ tıklayarak Rename seçeneğini seçiyor, adını da Istanbul-Izmir olarak değiştiriyorum.





8.2- Istanbul-Izmir Site Link'i içinde Antalya Site'ını barındırmayacağım için, Antalya Site'ını seçip, << Remove butonuna basarak soldaki Sites not in this site link alanına taşıyor, OK butonuna basarak pencereyi kapartıyorum.





8.3- Site Link yaplandırma işlemlerinin sorunda 3 site için 2 tane Site Link oluşturmuş olduk.


 

Site Link Bridge Kavramı

Site Link Bridge, Site Link’leri birbirine bağlarlar. Varsayılan olarak tüm Site Link’ler Bridged durumdadır. Ayrıca Bridge yaratmaya gerek yoktur. Bu makalemde 3 Site için 2 tane Site Link oluşturmuş, her Site Link içine 2 Site eklemiştim. Bu 2 Site (Istanbul-Antlaya, Istanbul-Izmir), Site Link Bridge sayesinde otomatik olarak birbirlerine bağlanmışlardır. Ancak Network, tamamıyla Routed değilse; yani tüm Site'lar (Site Link'ler) birbirlerine Routing (yönlendirme) ile erişebilir durumda değilse, bu varsayılan durum değiştirilip, gereken yerlere Site Link Bridge’ler oluşturulmalıdır.

Site Link Cost ve Replication Interval Kavramları

Site Link'ler ile replikasyonun ne sıklıkla, hangi öncelik sırası ile ve hangi gün ve saatlerde yapılacağını belirtmiştim. Bir Site Link için varsayılan Cost değeri 100'dür ve değiştirilebilmektedir. Bir Site Link için varsayılan Replication Internal değeri de 180 dakikadır. Bu 180 dakika, Intersite Replication değeridir ve değiştirilebilmektedir. Cost belirleme özelliği sayesinde iki Site arasındaki bağlantıların güvenilirliği ve hızını ayarlayabiliriz. Bu şekilde replikasyon, toplam Cost değeri en düşük yoldan gerçekleşecektir.





8.4- Site'lar arası replikasyonlar, varsayılan olarak 7/24 180 dakikada bir olacak şekildedir. 180 dakikalik Intersite Replication Inverval değeri değiştirilebileceği gibi, Change Schedule... butonuna basarak, replikasyon gün ve saatleri de değiştirilebilir.

Site İçinde Yeni Domain Controller Eklenmesi

Mevcut Domain ortamına yeni bir Domain Controller eklerken, Active Directory Promote işlemi sırasında Domain Controller'ın hangi Site içinde tutulacağını seçmemiz gerekiyor. Mevcut topolojimizde Antalya Site'ı içine SRV005x Hostname'li bir Domain Controller daha ekliyorum.








9- Active Directory Promote işlemi sırasında, Domain Controller Options adımında, Site Name alanından Antalya-Site'ı seçiyorum.



10- Additional Options adımında, Replicate from alanında Any domain controller seçerek, replikasyon topolojisini KCC-Knowledge Consistency Checker'ın belirlemesini sağlayacağım.
KCC-Knowledge Consistency Checker kavramına makalemin ilerleyen kısımlarında değineceğim.



11- firatboyan.com Domain'inde Antalya-Site içinde SRV005x Hostname'li yeni Domain Controller'ın eklenmesi işlemini tamamlamış bulunuyorum.

12- PowerShell komutu ile de Domain ortamımdaki Domain Controller'ların Hostname, İşletim sistemi versiyonu ve IP adresi bilgilerini görebiliyorum.

13- Mevcut Active Directory Site yapım ile ilgili detaylı bilgilere erişmek için, aşağıdaki PowerShell Script'i kullanıyorum.

KCC-Knowledge Consistency Checker Kavramı

Makalemin başında Domain Controller'lar arası replikasyon türlerinin Intersite Replication (Site içi replikasyon), Intersite Replication (Site'lar arası replikasyon) ve Urgent Replication (acil replikasyon) olmak üzere ikiye ayrıldığından bahsetmiştim. İşte tam da burada KCC'nin önem ve görevi devreye giriyor. KCC, 5 dakikada bir çalışarak, Site içinde hangi Domain Controller'ın hangi Domain Controller ile replikasyon yapacağını belirleyen bir Intersite Replication Topology oluşturup, bağlantı nesnelerinin otomatik olarak oluşmasını sağlamaktadır. Topolojiyi oluştururken de Domain Controller'lar arasındaki en iyi bağlantıyı hesaplar ve en iyi yolun kullanılmasını sağlar. Herhangi bir Site içindeki bir Domain Controller'a ait Connection nesnesindeki automatically generated yazmasındaki sebep budur. Connection nesnelerini kendiniz de Manuel olarak oluşturabilmektesiniz.

Bir Site içindeki herbir Domain Contoller, KCC-Knowledge Consistency Checker görevindedir ve aynı Site içindeki KCC Domain Controller'lar replikasyon topolojisini oluşturmak için replikasyon hatalarının kontrolü için birbirleri ile RPC (Remote Procedure Call- Uzak Çağrı Yordamı) üzerinden haberleşirler. Active Directory Sites and Services Yapılandırması sonrası KCC'nin oluşturduğu topolojiyi inceleyelim.



14- Istanbul-Site içinde 2 adet Domain Controller bulunuyor. Bu Domain Controller'lardan SRV001x, replikasyon bilgilerini SRV002x Hostname'li DC'den alıyor. SRV002x, replikasyon bilgilerini SRV001x, SRV003x ve SRV004x Hostname'li DC'lerden alıyor.





15- Izmir-Site içinde 1 adet Domain Controller bulunuyor. SRV003x Hostname'li bu Domain Controller, replikasyon bilgilerini Istanbul-Site içindeki SRV002x Hostname'li DC'den alıyor.



16- Antalya-Site içinde 2 adet Domain Controller bulunuyor. Bu Domain Controller'lardan SRV004x, replikasyon bilgilerini aynı site içindeki SRV005x ve Istanbul-Site içindeki SRV002x Hostname'li DC'lerden alıyor. SRV005x, replikasyon bilgilerini aynı Site içindeki SRV004x Hostname'li DC'den alıyor.




NOT: Dikkat ettiyseniz Site'lar içindeki Domain Controller'lar, farklı Site'larda bulunan Domain Controller'lardan replikasyon bilgisi alıyor. Bu noktada da devreye ISTG-Intersite Topology Generator Kavramı giriyor.

ISTG (Intersite Topology Generator) Kavramı

KCC (Knowledge Consistency Checker), Intrasite Replication Tepology (Site içi replikasyon topolojisi) oluşturma görevinin yanında ISTG (Intersite Topology Generator) oluşturmakla da görevlidir. ISTG ile diğer Site'lardaki Domain Controller'larda oluşacak değişikliklerin, tüm Domain ya da Forest'taki diğer Site'lar içinde bulunan Domain Controller'larda da güncel tutulması sağlanır. Site'lar arası Replikasyon trafiğinde sadece ISTG rolündeki Domain Controller'lar görevlidir ve bu Domain Controller'lara Bridgehead Server denmektedir.

Bir Site içindeki en az 1 Domain Controller, Site'lar arası replikasyon topolojisini oluşturması ve Site'lar arasındaki replikasyon bilgisini çekmek için otomatik olarak ISTG, yani Bridgehead Server, olarak atanır. Bir Site içinde bulunan Bridgehead Server, herhangi bir sebeple ulaşılamaz durumda olursa, Site içindeki GUID değeri en yüksek bir sonraki Domain Controller otomatik olarak ISTG Server (Bridgehead Server) olarak atanır. Bir Site içinde oluşan herhangi bir değişiklikte bilgiler, önce Site içindeki Domain Controller'larda, daha sonra da Bridgehead Server'lar üzerinden diğer Site'lardaki Bridgehead Server'lara repilike olurlar. Replikasyon bilgisini alan diğer Site'lardaki Bridgehead Server'lar da bu replikasyon bilgisini kendi Site'ı içindeki Domain Controller'lara replike ederler.

KCC, bir Site içinde otomatik olarak birden fazla ISTG atayabilir ve otomatik olarak KCC tarafından atanan ISTG, manuel olarak da atabilir ancak ISTG'ye ulaşılamaması durumunda bu sefer Site içindeki GUID değeri en yüksek bir sonraki Domain Controller otomatik olarak Bridgehead Server olarak otomatik atanamaz! Böyle bir durumda Bridgehead Server yine elle, manuel olarak değiştirilmelidir!

ISTG, Intersite Replication bilgisinin alınması için en etkili yolun hesaplanmasında Least-Cost  (en düşük maliyet) bilgisini kullanır. Buna da Least-Cost Spanning Tree algoritması denir. Algoritmanın fikri, belirli bir ağın mesafe matrisini (ağırlık matrisi) okumak ve en düşük maliyetli yolu oluşturmak için en düşük maliyetli bağlantılar kümesini içeren tercih edilen bir bağlantı matrisini oluşturmaktır.

17- Istanbul-Site ve Antalya-Site için KCC tarafından otomatik olarak atanan ISTG-Intersite Topology Generator (Bridgehead) Server'lar aşağıdaki gibidir.



18- Izmir-Site için KCC tarafından otomatik olarak atanan Bridgehead Server'lar aşağıdaki gibidir. Burada bilinmesi gereken en önemli unsur; otomatik olarak KCC tarafından otomatik olarak atanan ISTG, BridgeheadServers olarak işaretlenir. Manuel olarak atanan ISTG ise PreferredRpcBridgeheadServers olarak işaretlenir.



19- ISTG-Intersite Topology Generator'ı Elle, manuel olarak atamak için Hostname (Ör. Istanbul-Site içindeki SRV002x) üzerinde sağ tıklayarak Properties seçeneğini seçiyorum.



20- Karşıma çıkan pencerenin alt kısımında Transports available for inter-site data transfer altında bulunnan IP'yi seçerek Add >> butonuna basıp, This server is a preferred bridgehead server for the following transports alanına ekliyorum.




21- Görüldüğü gibi Elle, manuel olarak atanan SRV002x Hostname'li ISTG-Intersite Topology Generator, PreferredRpcBridgeheadServers olarak işaretlemiştir.

Replikasyon Özetini İzleme

22- 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 (Directory System Agent) ve Destination DSA (Directory System Agent) Nedir?

Her iki 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 ile İ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:

Largest Delta'nın Anlamı

• 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.

Replikasyon Kontrolü

24-  5 adet Active Directory Partition replikasyonunun nasıl işlediği ve hangi DC'lerin hangi DC'ler ile replikasyon yaptığı bilgilerini repadmin /showreps ya da repadmin /showrepl kumutları ile elde edebiliriz. 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.

Force Replication Kavramı | Manuel Replication

Bazı durumlarda Domain ya da Forest ortamınızdaki tüm Domain Controller'ların, varsayılan replikasyon sürelerini beklemeden tamamının en güncel duruma getirilmesi gerekebilir. Bunun için 2 yöntem bulunmaktadır. Replikasyonların GUI (Graphical User Interface) üzerinden Manuel olarak, elle tetiklenme işlemini yapmak için;

25- NTDS Settings içindeki Connection Object'lerin üzerinde sağ tıklayarak Replicate Now seçeneğini seçerek, Connection Object üzerinde From Server kısımında hangi Domain Controller'ın Hostname'i yazıyorsa, Pull Replication yordamıyla o Domain Controller'dan replikasyon bilgilerini çekecektir.




Force Replication Kavramı | Repadmin /Syncall
Replikasyonların CMD (Command Promt) üzerinden, komutla tetiklenme işlemini yapmak için repadmin /syncall komutunu kullanacağız.

26- repadmin /syncall komutunu CMD (Command Promt) üzerinden /APed parametresi ile iki farklı şekilde kullanabiliriz.

1. Kullanım

repadmin /syncall /APed
Bu komut ile komutun çalıştırıldığı Domain Controller'dan, tüm Site'lardaki DC'lere Push Replication ile replikasyon bilgilerini göndermesi için kullanılmaktadır.

A parametresi: All- Tüm Active Directory Partition replikasyonları içindir.
P parametresi: Push- Repliksyonun, komutun çalıştırıldığı Domain Controller'dan tüm DC'lere gönderilmesi için.
e parametresi: Enterprise- Repliksyonun tüm Site'larda işletilmesi içindir.
d parametresi: Distinguished Name- Domain Controller'ların Komut çıktısındaki mesajlarda Distinguished Nam adı ile görüntülenmesini içindir.



2. Kullanım

repadmin /syncall /APed
Bu kullanımda komut, hangi DC'de çalıştırılırsa çalıştırılsın, Hostname'i belirtitilen DC'den, diğer DC'lere Push Replication ile replikasyon bilgilerinin gönderir.


 

Replikasyon Hatalarının Görüntülenmesi

Replikasyon işlemlerinde yaşanan sorun giderme için önemli bilgiler edilebiliceğiniz repadmin /showrepl /errorsonly komutu ile Domain Controller'lar üzerindeki replikasyon sorunları görüntüleyebilirsiniz. 

27- repadmin /showrepl /errorsonly komutunu hangi Domain Controller üzerinde çalıştırırsanız, o DC üzerindeki replikasyon sorunlarını götüntüleyecektir.



28- repadmin /showrepl  /errorsonly komutu ile Hostname yazan yere hangi Domain Controller'ın replikasyon hata bilgileri alınacaksa, o DC'nin Hostname'ini yazmamız gerekmektedir.

28.1- Istanbul-Site ve Izmir-Site için DC replikasyon hata bilgilerini çekiyorum. 



28.2- Antalya-Site için DC replikasyon hata bilgilerini çekiyorum. Komut çıktısında herhangi bir hata göstergesi bulunmamaktadır. Hata bulunması durumunda, hatalar detaylı bir şekilde yazacaktır.



Faydalı olması dileğiyle...