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

Büyük ve kurumsal firmalar, bazen bir ülklede birden fazla şehirde; bazen de birden fazla ülkede, birden fazla şehirde hizmet verebilmektedirler ve firmaların coğrafi olarak farklı lokasyonlardaki şubelerinde konumlandırılan, Domain yapısını işleten Domain Controller'ların da yönettiğimiz sistemler üzerinde mantıksal olarak ayrıştırılmaları gerekmektedir. Bu mantıksal ayrışmanın temek iki sebebini aşağıdaki gibi sıralayabiliriz;

1- Her Client'ın, bulunduğu Site (lokasyon) içindeki Domain Controller'dan Authentication (kimlik doğrulama) işlemlerini gereçleştirmesi gerekmektedir. Kısaca, Logon (oturum açma) trağini yönetilmesini sağlamak diyebilriz. Bunu biraz daha açacak olursak; Domain ortamının kurulması ile birlikte, Domain ortamına kurulan her Domain Controller (coğrafi olarak nerede olduğunun önemi olmaksızın) varsayılan olarak Default-First-Site-Name Site yapısı içinde bulunur. Ör. X şubesindeki birisi, Y şubesine gittiğinde bilgisayarını açıp, Authentication (kimlik doğrulama) işlemi gerçekleştirecektir. Ancak Authentication (kimlik doğrulama) işlemi gerçekleştireceği Domain Controller'lardan herhangi birisi, varsayılan tek bir Site (lokasyon) yapısı olan Default-First-Site-Name içinde bulunduğu için, o anda Authentication (kimlik doğrulama) işlemi gerçekleştirmeye çalıştığı Domain Controller, kişinin bulunduğu farklı bir şubede (Ör. Z şubesi) ise, ve bu iki şube arasındaki Internet hattı zayıfsa, Authentication (kimlik doğrulama) işleminin gerçekleşmesi çok uzun dakikalar, hatta saatler alabilir. Bu sebeple de kişi, hangi şubeye giderse gitsin, sadece ve sadece Domain ortamındaki o Site (lokasyon) içinde bulunan Domain Controller ile muhatap olmalıdır.

2- Domain yapısını işleten Domain Controller'ların NTDS.dit Database (veri tabanı) bilgileri birbirleri ile aynı ve tutarlı olmalıdır. Adına replikasyon dediğimiz bu Database (veri tabanı) bilgilerinin güncel tutulma işlemlerinin, Site'lar arasındaki Internet hatlarının durumuna göre planlamalarının yapılmasını sağlamak gerekmektedir.

Active Directory Partition Kavramı

2. maddeyi okuduktan sonra Replike olan nedir? sorusunu kendinize sormaya başlamış olabilirsiniz. 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

Bu Partition içinde Active Directory'deki User, Computer, Group, ya da Orgzniation Unit (OU) gibi nesnelerin Class ve Attribute bilgileri tutulur. Bir Forest ortamındaki tüm Domain Controller'lar, Schema Partition'ın salt-okunur (Read-Only) bir kopyasını barındırırlar ve bu Partition içindeki tüm nesneler, Forest içindeki tüm DC'lere replike olurlar.

2- Configuration Partition

Bu Partition içinde Forest bazında (Forest-Wide) Active Directory Domain (Forest) yapısının mantıksal topoloji bilgisi ve replikasyon topoloji bilgisi tutulur. Bir Forest ortamındaki tüm Domain Controller'lar, Configuration Partition'ın okunabilir/yazılabilir (Read/Write) bir kopyasını barındırır ve bu Partition içindeki tüm nesneler, Forest içindeki tüm DC'lere replike olurlar.

3- Domain Partition (Namig Context)

Bu Partition içinde bir Active Directory Domain içindeki User, Computer, Group, ya da Orgzniation Unit (OU) gibi nesnelerin dizin bilgileri tutulur. Bir Forest ortamındaki tüm Domain Controller'lar, Domain Partition'ın okunabilir/yazılabilir (Read/Write) bir kopyasını barındırır ve bu Partition içindeki tüm nesneler, Forest içindeki tüm DC'lere replike olurlar.

4- Application Partition

5- Application Partition

Windows Server 2003 ile hayatımıza giren bu Partition; DNS, DHCP, Remote Access (RAS), RADIUS gibi dinamik olarak veri kullanımı gerektiren bir takım network ilişkili servislerin (uygulamaların) Active Directory içinde bilgilerini saklaması için kullanılan bir Partition türüdür. Bu dinamik Data'lar, varsayılan 1 gün olup, min. 5 dakikaya kadar düşürülebilir Time-To-Live (TTL) yaşam süresine (Life Span) sahiptir ki bu da Data'ların kullanılmadıkları zaman Active Directory'den otomatik olarak ne zaman silineceklerine dair bir zaman süresi belirlemiş olur. Bu Partition içinde tutulan uygulama tabanlı bilgiler, bertilen herhangi bir Domain Controller'a replike edilebilir. Application Partition ile Administrator kullanıcıları; Data'ların saklanması için Domain ya da Forest ortamındaki tüm Domain Controller'lar yerine, kendilerinin seçeceği herhangi bir Domain Controller'da alanlar oluşturarak, Application Partition kopyasının (replikasyon) da istedikleri herhangi bir Domain Controllar'a tutulmasını sağlama imkanına sahiptirler.

NOT: DNS Server üzerindeki Autorative Domain Zone, Active Directory Integrated Zone olarak yapılandırılmışsa, ek olarak ForestDnsZones'u da içerdiği için 2 tane Application Partition görmekteyiz.

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 Host Name, İş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 Host Name'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 Host Name'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 Host Name'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 Host Name'li yeni Domain Controller'ın eklenmesi işlemini tamamlamış bulunuyorum.

12- PowerShell komutu ile de Domain ortamımdaki Domain Controller'ların Host Name, İş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 Host Name'li DC'den alıyor. SRV002x, replikasyon bilgilerini SRV001x, SRV003x ve SRV004x Host Name'li DC'lerden alıyor.





15- Izmir-Site içinde 1 adet Domain Controller bulunuyor. SRV003x Host Name'li bu Domain Controller, replikasyon bilgilerini Istanbul-Site içindeki SRV002x Host Name'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 Host Name'li DC'lerden alıyor. SRV005x, replikasyon bilgilerini aynı Site içindeki SRV004x Host Name'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 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 Host Name (Ö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 Host Name'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 topolojimde yer alan Domain Contoller replikasyonlarının özet bilgisini elde ediyorum.

• largest delta: Domain Contoller'lar arasındaki en son replikasyondan beri geçen süreyi göstermektedir.
• fails: Domain Contoller'lar arasındaki Active Directory Partition repliklasyonlarının kaç tanesinin hatalı sonuçlandığı bilgisini verir.
• total: Domain Contoller'lar arasındaki Active Directory Partition repliklasyonları için yapılan bağlantı sayısıdır. Bu alanda normalde her bir Active Directory Partition için oluşturulan bağlantı sayısı 5 olması gerekirken, bundan daha yüksek bir değer görmemizdeki sebep, her bir Active Directory Partition için ayrı ayrı bağlantı kurduğu, başarısız olması durumunda bağlanıtının tekrar dendiği içindir.
• %%: Total ile Fail değerlerinin yüzdelik olarak gösterimini temsil eder. Ör. 10 bağlantı denemesi yapılıp, bunlardan 5 tanesi başarısız olursa ki hiç bir Partition replikasyonunun Fail olmaması gerekiyor, yüzdelik alanda 50 değeri görünecektir.
• error: Hatalı sonuçlanan Active Directory Partition repliklasyonları ile bilginin yer aldığı bilgi bölümüdür.

Burada karşımıza çıkan DSA (Directory System Agent), RPC (Remote Procedure Call-Uzak Yordam Çağrısı) protokolü ile replikasyon işleminin başlatılabilmesi ve Domain Controller'ların birbirleri ile iletişim kurabilmeleri için gerekli olan bağlantı altı yapısını kurar. 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 yapısını kullanmasından dolayıdır. Multi-Master, tüm Domain Controller'larin birbirlerine replikasyon yapabilmesi kavramıdır ve Multi-Master yapısı ile bir Fault-Tolerance (hata toleransı) oluşmuş, herhangi bir Domain Controller erişilemez durumda olsa dahi, replikasyon sürekliliği de korunmuş olur.

Ek olarak, komutu uyguladıktan sonra karşımıza çıkan noktalar gözünüze çapmış olabilir. Buradaki noktalardan ilk 3 tanesi, Progress'in başlatılması ile ilgili olan noktalar olup, bu örnekteki geri kalan 5 nokta ise, Domain ortamımda 5 tane Domain Controller bulunması sebebiyledir. Ortamınızda kaç tane Domain Controller varsa, 3+ n kadar Domain Controller sayısınca (.) nokta göreceksiniz.

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 Host Name'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, Host Name'i belirtitilen DC'den, diğer DC'lere Push Replication ile replikasyon bilgilerinin gönderir.





repadmin /syncall komutundaki;
 

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 Host Name yazan yere hangi Domain Controller'ın replikasyon hata bilgileri alınacaksa, o DC'nin Host Name'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...