Windows Server 2008 R2'den Windows Server 2022'ye Domain Controller Migration

Windows Server 2008 R2'den Windows Server 2022'ye yapılan Domain Controller Migration, birçok kuruluş için önemli bir teknolojik atılımı temsil eder. Bu geçiş, Windows Server platformunda sunulan yeni özelliklerden ve güvenlik güncellemelerinden tam olarak yararlanmayı amaçlar. Windows Server 2022, daha güçlü güvenlik, gelişmiş performans ve daha iyi yönetim kapasitesi gibi özellikleri ile dikkat çeker, bu yüzden geçiş, IT altyapısının modernleştirilmesi ve güçlendirilmesi açısından hayati önem taşır.

Bu Migration süreci, öncelikle mevcut Domain Controller yapılandırmalarının detaylı bir şekilde gözden geçirilmesiyle başlar. Mevcut sistemlerin ve yapılandırmaların derinlemesine analizi, uyumsuzlukların ve potansiyel sorunların belirlenmesine yardımcı olur. Bu aşama, aynı zamanda sistem yedeklerinin alınmasını ve kritik verilerin güvence altına alınmasını da içerir, böylece herhangi bir veri kaybı veya kesinti riski en aza indirilmiş olur.

Test ortamının kurulması ve pilot Migration uygulamaları, bu büyük geçiş öncesinde kritik adımlardandır. Bu Test'ler, gerçek sistemler üzerinde uygulama yapmadan önce tüm senaryoların ve işlemlerin kontrol edilmesine olanak tanır. Pilot uygulamalar sırasında elde edilen geri bildirimler, gerçek Migration planlarının optimize edilmesi için değerlidir.

Gerçekleştirme aşamasında, tüm Domain Controller bileşenleri, uygulamaları ve hizmetleri dikkatlice yeni Windows Server 2022 ortamına taşınır. Bu işlem sırasında, Active Directory ve diğer hizmetlerin doğru bir şekilde yapılandırıldığından emin olunur. Yeni Server ortamında, geliştirilmiş güvenlik ayarları ve yönetim araçları devreye girer, bu da genel IT güvenliğini ve yönetilebilirliği önemli ölçüde artırır.

Windows Server 2008 R2’den, Windows Server 2022’ye Active Directory Migration işlemine geçmeden önce ilk etapta bu makaleyi yazdığım tarih itibari ile en yeni Windows Server versiyonu olan Windows Server 2022 özelliklerinden ve yeniliklerinden bahsetmek istiyorum.

Windows Server 2022 Yenilikleri

Teknoloji dünyasına artık iyiden iyiye yerleşen bulut teknolojileri, özellikle işletim sistemlerinin gelişen bu teknolojiye ayak uydurması ve entegre çalışabilmesi açısından çok önemlidir. Gelişen bu teknolojiye bu denli ayak uydurma ihtiyacı, aslında temelde güvenlik kaygıları ile doğru ortantılı bir şekilde gelişiyor. Eski nesil işletim sistemlerine verilen desteğin zamanla yitirilmesi, güvenlik açıklarını beraberinde getirdiği için sistemleri daha savunmasız hale getiriyor. Bir diğer önemli husus, bulut teknolojileri ile tam uyumlu ve Hybrid yapıda sorunsuz bir şekilde çalışabilecek, güvenlik seviyeleri artırılmış bir işletim sistemi ihtiyacının olmasıdır.

Windows Server 2022 yeniliklerini temel olarak üç ana başlıkta toplayabiliriz.

1- Advanced multi-layered Security

Bu sürümde Microsoft, çok katmanlı güvenlik mimarisi sunmaktadır. Secure-Core Server özelliği ile Microsoft’un donanım ortaklarının desteği sayesinde kritik sistemlerin güvenliği güçlendirilmiştir. Bu güçlendirme için özellikle donanım sağlayıcılar, donanımsal koruma çipleri (TPM), Firmware ve güvenli sürücüler temin etmektedir.

Bir diğer koruma katmanı ise bağlantı noktasındadır. En yeni nesil TLS 1.3 ile daha güvenli bir HTTPS trafiği, DNS-over-HTTPS (DoH) ile daha güvenli DNS trafiği ve AES-256 şifreleme desteği sunan en yeni nesil SMB ile artık bağlantı noktasında da son derece güvenli bir sunucu alt yapısı sunar.

1.1- Secured-Core Server

Secure-Core Server konsepti, temel olarak donanım ve sanallaştırma tabanlı güvenlik teknolojilerinin harmanlanarak kullanılması sonucunda bilinen ve bilinmeyen pek çok atak tipi için üst düzey bir koruma sağlar. Donanımların ön yükleme sırasındaki hak yükseltme, Firmware için zararlı kod enjekte edilmesinden tutunda kimlik hırsızlığının önüne geçilmesine kadar OS katmanında ve tabi ki donanım üreticilerinin sağladığı uygun ve sertifikalı donanımlar ile çok katmanlı bir koruma sağlar.

1.2- Secure connectivity

Sunucu koruması her ne kadar önemli ise sunucu ile iletişim halindeki istemcilerin, diğer sunucuların da güvenliğinin sağlanması için iletişim protokollerinin de güvenliği son derece önemlidir. Yani donanım ve sanallaştırma temelli olarak sıkı korunan bir sunucuya sızmak yerine bu sunucunun trafiğinin izlenmesi kimi zaman daha kolay olabilir. Böyle durumlara karşı çok katmanlı mimarinin gereği tüm iletişim içinde protokol güvenliği üst seviyededir.

En güncel TLS 1.3 sürümü sayesinde güvenli HTTPS trafiği sunar ki DoH gibi yeni nesil DNS sorgularının artık HTTPS protokolü ile yapılacağını düşündüğümüz zaman bunun önemi bir kez daha ön plana çıkıyor. DNS malum bir Windows sunucu için en kritik servislerden birisi ve yine SMB gibi en çok atak alan servis, protokollerin başında geliyor. Durum böyle olunca, DNS atakları için iletişim protokolü olarak HTTPS devreye girdi. Son olarak bir diğer en yaygın sunucu iletişim protokolü olan SMB için artık AES-256 bit şifreleme desteği sayesinde çok daha güvenli bir veri iletişimi söz konusu olacaktır. Burada özellikle Windows Server 2022 ile Cluster sistemler için bu veri şifreleme desteği sayesinde S2D gibi veri replikasyonu yapan sistemlerinde Cluster içerisindeki tüm haberleşmesi artık şifreli olabilmektedir. Yine RDMA sayesinde storage sanallaştırma ile daha çok hayatımıza giren S2D ile, başta Windows Server 2022 platformları için, performanstan ödün vermeden şifreleme yapabileceğiz. (RDMA ile SMB şifrelemesini kullanarak performanstan ödün vermeden endüstri standardı şifreleme elde edin.)

2- Hybrid capabilities with Azure

Malum günümüzde bulut bilişim, artık yoğun kullanılan bir alt yapı ancak hala her iş ihtiyacı için tek adres değil. Bu nedenle pek çok şirketin Hybrid bulut model yapısı kullandığını görebiliyoruz. Durum böyle olunca, Hybrid alt yapıların daha kolay yönetilmesi için pek çok üreticinin yatırım yaptığı da ortada. Eğer aktif bir Hybrid ortam yöneticisi iseniz, aslında bu ortamların ideal ürünler olmadan yönetiminin ne kadar zor olduğunu bilirsiniz. Microsoft da bu noktada Windows Server 2022 ile Hybrid bir alt yapı için gerekli olan tüm araçlar sunmaktadır.

Örneğin, Windows Admin Center ile hem yerleşik hem bulut sistemlerimizi tek bir ekran üzerinden yönetebildiğimiz gibi, Azure-Arc sayesinde de bulut hizmetlerimizi On-prem. kaynaklara genişletebiliyoruz. mesela; izleme, değişiklik yönetimi, loglama, yedekleme, replikasyon başta olmak üzere pek çok bulut temelli hizmeti, sadece bir Agent yardımı ile On-prem. sistemlere genişletebiliyoruz. Üstelik bunu tek bir ekrandan yönetebiliyoruz.

3- Flexible application platform

Belki de buraya kadar anlattıklarımızın arasındaki en önemli başlık, özellikle uygulama geliştiriciler için daha esnek ve modern bir platform sunmasıdır. Çünkü artık yeni nesil servis modelinde çok daha hızlı, esnek, çevik, kendi kendine büyüyen ve küçülen sistemler tercih ediliyor. İzlemesi, yedeklenmesi, yedekten dönmesi, sorun çözmesi veya gelen taleplere karşı en iyi cevapları vermesi nedeni ile artık yazılımcılar, mikro servis mimarisine uygun yeni nesil uygulamalar geliştiriyorlar. Durum böyle olunca, yazılım ekipleri bu yeni nesil uygulamaların çalışması için yeni nesil platformlar bekliyor. Windows Server 2022 de tam bu noktada onlara cevap veriyor. Öncelikle SQL Server Performansından bahsedelim. Verilerin büyümesi ile veri tabanlarının ve onların ihtiyaç duyduğu donanımların büyümesi son derece normal. Durum böyle olunca Windows Server 2022 de toplam 48 TB RAM ve 2048 Core CPU desteği sunuyor.

AKS, çok yaygın kullanılmaya başlandı ancak özellikle Hybrid mimarilerde AKS üzerindeki bazı hizmetlerin yerleşik sistemlerde de olması gerekiyordu. Bu noktada Azure üzerindeki Kubernetes servisindeki Network Policy'leri artık On-prem. sistemler içinde desteklemeye başladı. Yani, iç ve dış yöne Network trafiğini IP adresi ve Port bazında sınırlayabiliyoruz. Aynı zamanda içerideki uygulamaların da kendi aralarındaki pod2pod trafiğini veya Namespace ile kısıtlama desteği sunuyor. Yine bu destek sayesinde Hybrid Cluster yapmak mümkün. Yani bir bacağı bulut, bir bacağı On-prem.'deki Kubernetes Cluster'ları kurabiliyoruz. Container (pod) sayısının otomatik artırarak yatay ölçekleme sunabiliyor.

Otomatik ölçekleme de CPU ve RAM sayısına göre sistem, kendisi ayarlama yapabiliyor. Malum, bazı özellikler Kubernestes ortamına daha sonradan geliyor, örneğin Multiple Subnet desteği ve Dual Stack (hem IPv4 hem IPv6) desteği Kubernetes ortamlarına geldiği için Windows Server 2022 de bu özellikleri desteklemeye başladı. Bir diğer yenlik, yine üretici temelli. Kubernetes Container açma, kapatma işlemleri için artık sadece Docker değil, Container desteği de geldi. Bu sayede artık Container sistemlerinide Windows Server 2022 ile yönetebiliyoruz.


 

Migration Nedir?

Kelime anlamı taşıma olan Migration, çok geniş bir yelpazede ele alınmaktadır. Taşıma işlemini fiziksel ya da sanal sistemlerin fonksiyonellik, işlevsellik ve performans bağlamında eski sürümden yeni sürüme geçiş işlemleridir şeklinde özetleyebiliriz. Bu geçiş ihtiyaçları, çeşitli sebeplerden ve ihtiyaçlardan dolayı yapılabilmektedir. Makale konumuz olan Windows Server 2008 R2’den, Windows Server 2022’ye Domain Controller (DC) Migration'ı baz alacak olursak bu ihityaç, tamanen bulut teknolojileri ile tam uyumlu ve Hybrid yapıda sorunsuz bir şekilde çalışabilecek, güvenlik seviyeleri artırılmış yeni nesil bir Windows Server gereksiniminden hasıl olmaktadır.

Migration işlemi, öncelikle detaylı bir planlama ve hazırlık aşamasını gerektirir. Bu aşamada, mevcut sistem yapılandırmaları, uygulamalar ve bağımlılıklar dikkatlice incelenir. Bu inceleme, potansiyel uyumsuzlukların ve teknik zorlukların önceden tespit edilmesini sağlayarak, migration sürecinin sorunsuz ve verimli bir şekilde gerçekleştirilmesine yardımcı olur. Planlama aşaması, aynı zamanda veri kaybı risklerini minimize etmek ve sistem kesintilerini en aza indirmek için kritik öneme sahiptir.

Sonraki adım, test ortamının kurulması ve pilot migration'ın gerçekleştirilmesidir. Bu test, gerçek sisteme uygulanmadan önce çeşitli senaryoların ve güncelleme işlemlerinin denendiği bir platform sunar. Test süreci, olası sorunların giderilmesi ve migration stratejisinin finetuning'i için değerli fırsatlar sağlar. Ayrıca, bu aşama, son kullanıcılar ve IT ekipleri için yeni sistemle ilgili eğitimlerin ve adaptasyon süreçlerinin başlatılmasına olanak tanır.

Gerçek migration işlemi başladığında, tüm sistemlerin, uygulamaların ve verilerin yeni sunucu ortamına taşınması gerektiği anlamına gelir. Bu süreç sırasında, veri bütünlüğü ve sistem performansı sürekli olarak izlenir. Windows Server 2016'ya geçiş, genellikle sistem yapılandırmalarının yeniden gözden geçirilmesi ve optimize edilmesi anlamına gelir ki bu da IT altyapısının genel etkinliğini artırır.

Migration Öncesi Mevcut Ortam Bilgisi Edinme

Senaryomdaki ortamımda Domain yapısını oluşturan Windows Server işletim sistemi Windows Server 2008 R2 olup, Primary Domain Controller görevindedir. Migration (taşıma) işlemi için kullanacağım Windows Server 2022 işletim sistemli makinam ise Additional Domain Controller görevindedir. Özetle, mevcut Domain ortamımda toplamda 2 adet Domain Controller bulunuyor ki sayı çok daha fazla da olabilir. Buradaki amaç, sadece taşıma süreçlerini anlatmak olduğu için bu sayı benim için yeterlidir.

Burada amacım özetle, işletim sistemi Windows Server 2008 R2 olan Domain Controller bir makinayı & makinaları, Windows Server 2022 işletim sistemi üzerinde Domain Controller yapmak ve eski nesil Windows Server üzerinde çalışan Domain Controller bir makinayı & makinaları ortamdan kaldırarak Domain ortamının Windows Server versiyonu bazında tamamen yenilenmesini sağlamak olacaktır. Bu bilgiler ışığında Windows Server 2008 R2’den, Windows Server 2022’ye Domain Controller Migration işlemine başlıyorum.

Migration işlemi öncesi bir takım kontroller yapacağım. Bu kontroller, eğer ortama yabancı iseniz, mutlaka ortam bilgisini detaylı bir şekilde öğrenme ve Domain Controller'ların sağlıklı bir şekilde çalışabilirliğinin kontrolünün yapılması olacaktır.

1- Windows Server 2008 R2 işletim sistemli Domain Controller makinam üzerinde bir takım bilgiler çekerek mevcut ortam hakkında bilgi edineceğim. Aşağıdaki PowerShell komutuyla ortamımdaki Domain Controller'ları ve işletim sistemi versiyon bilgilerini çekiyorum.

Aşağıdaki PowerShell komutuyla FSMO (Flexible Single Master Operation) rollerini barındıran Domain Controller bilgisini çekiyorum.

5 adet FSMO rolü içinde PDC rolü, hangi Domain Controller'da ise o Domain Controller, diğer rollere sahip olmasa bile direkt olarak Primary Domain Controller görevini üstlenecektir. Bu nedenle FSMO rol bilgisini çektiğinizde hangi makinanın Primary Domain Controller olduğunu bu bilgi ile öğrenebilirsiniz. Her ne kadar konumuz dışında olsa da bu 5 adet FSMO rolünün her birinin hangi görevleri icra ettiği bilgisini makalemin ilerleyen kısımlarında vereceğim.

PowerShell komutuyla, yukarıdaki bilgilere ek olarak, direkt olarak hangi makinanın Primary Domain Controller olduğu bilgisini edinebilirsiniz.



2- Aynı komutları Windows Server 2022 işletim sistemli Domain Controller makinam üzerinde de çalıştırdığımda aynı bilgileri elde ediyorum.



3- Windows Server 2008 R2 işletim sistemli Domain Controller makinam üzerinde

PowerShell komutlarıyla Domain Controller'lar arası Active Directory replikasyon trafiği ve KCC (Knowledge Consistency Checker) üzerinde herhangi bir sorun olup olmadığı bilgilerini çekiyorum. KCC (Knowledge Consistency Checker), her 5 dakikada bir çalışarak, Site içinde hangi Domain Controller'ın hangi Domain Controller ile replikasyon yapacağını belirleyen bir Intrasite (site içi) Replication Topology (replikasyon topolojisi) 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 ve bağlantı nesnelerinin otomatik olarak oluşmasını sağlar.



4- Aynı komutları Windows Server 2022 işletim sistemli Domain Controller makinam üzerinde de çalıştırdığımda aynı bilgileri elde ediyorum.



5- Windows Server 2008 R2 işletim sistemli Domain Controller makinam üzerinde

PowerShell komutunu çalıştırarak Domain Functional Level (DFL) ve Forest Functional Level (FFL) bilgilerini çekiyorum. Mevcut Domain ortamımı ilk oluşturduğum sırada DFL ve FFL seviyelerini Windows Server 2008 R2 olarak ayarlamıştım.



6- Aynı komutu Windows Server 2022 işletim sistemli Domain Controller makinam üzerinde de çalıştırdığımda aynı bilgileri elde ediyorum.



7- DFL ve FFL seviyelerini kontrol ederken bu seviyelerin Windows Server 2003 olduğunu da görebilirsiniz. Bu, daha önceden Windows Server 2003'ten Windows Server 2008 R2'ye bir Migration yapıldığı ancak DFL ve FFL seviyelerinin Windows Server 2008 R2'ye yükseltilmediği anlamına gelmektedir. Böyle bir durumla karşılaşırsanız, Windows Server 2008 R2 işletim sistemli Primary Domain Controller'ınıza ek olarak Windows Server 2019 ya da Windows Server 2022 gibi yeni nesil işletim sistemli Additional Domain Controller(lar) kurarken, SYSVOL paylaşım klasörü içerik replikasyonu Windows Server 2003'te Files System Replication (FSR) ile gerçekleştiği ve Windows Server 2019 ya da Windows Server 2022 gibi yeni nesil Windows Server işletim sistemli Domain Controller(ların) SYSVOL paylaşım klasörü içerik replikasyonu Distributed Files System Replication (DFSR) üzerinden gerçekleştirdiği için

Verification of replica failed. The specified domain {Domain-Name} is still using the File Replication Service (FRS) to replicate the SYSVOL share. FRS is depreciated. The server being promoted does not support FRS and cannot be promoted as a replica into the specified domain. You MUST migrate the specified domain to use DFS Replication using the DFSRMIG command before continuing.

hatası ile karşılaşırsınız. Bu noktada öncelikle mevcut ortamda Windows Server 2008 R2 işletim sistemli Domain Controller(lar)'dan daha eski versiyonlu Domain Controller(lar) olmadığından emin olup, DFL ve FFL seviyelerini Windows Server 2008 R2'ye yükselttikten sonra FSR yapınızı DFSR'a dönüştürmeniz gerekecektir. Bu işleme de DFSR Migration dersek, yanlış bir tabir kullanmış olmayız.




DFSR, RDC yani Remote Differential Compression (uzak diferansiyel sıkıştırma) olarak bilinen yeni bir sıkıştırma algoritması kullanır. RDC, sınırlı bant genişliğine sahip bir Network üzerinden dosyaları verimli bir şekilde güncellemek için kullanılabilen bir "diff-over-the wire" istemci-sunucu protokolüdür. RDC, dosyalardaki verilerin eklenmesini, kaldırılmasını ve yeniden düzenlenmesini algılayarak DFS çoğaltma'nın dosyalar güncellenmesi ile yalnızca değiştirilen dosya bloklarının çoğaltmasını sağlar.

8- Mevcut ortamınızdaki SYSVOL paylaşım klasörü içerik replikasyonunun hangi yordamla gerçekleştiğini öğrenmek isterseniz, DFSRCheck.ps1 PowerShell Script'ini kullanabilirsiniz.




9- Sıra, Domain Controller'lar üzerinde DCDIAG komutu ile bir sağlık taraması yani Health Check yapmak olacak. DCDIAG komutunun çok farklı yöntemleri mevcut, burada makale dışına çıkmak istemediğim için bu komutu sadece, eğer varsa, sorunları listelemesi için

komutlarını yazarak, ortamımdaki tüm Domain Controller'lar için tek bir PowerShell konsolundan çalıştırarak kullanacağım. Komutu, hem Windows Server 2008 R2 işletim sistemli Domain Controller hem de Windows Server 2022 işletim sistemli Domain Controller üzerinde ayrı ayrı çalıştırıyorum. Aslında böyle bir gereksinim yok ancak sonucu size tam olarak göstermek için bu şekilde uyguluyorum.

FSMO (Flexible Single Master Operation) Rollerinin İncelenmesi

Domain ortamının ilk kurulduğu ilk Server, Domain Controller görevindedir. Bir Domain Controller'ın Domain ortamının yönetimi için sahip olduğu bir takım görevler vardır ve FSMO (Flexible Single Master Operation) adı verilen, toplamda 5 rolden oluşan bu görevleri özetle Active Directory'nin bel kemiğini oluşturan Schema (şema) yapısı içindeki Active Directory nesnelerinin yönetimi, Dizin yapısının kayıt işlemlerinin yönetimi, Group Policy nesnelerinin ortamdaki diğer Domain Controller'lar ile senkronizasyon sağlaması için gerekli olan SYSVOL paylaşım erişiminin yöneti, Active Directory'de oluşturulan Active Directory nesnelerinin kimlik bilgilerinin yönetimi olarak sıralayabiliriz.

10- Windows Server 2008 R2 işletim sistemli Domain Controller makinam üzerinde FSMO rollerinin bu DC üzerinde olduğunu kontrol etmiştik. Sıra, Windows Server 2008 R2 işletim sistemli Domain Controller makinam üzerindeki FSMO rolleri taşıma işlemine geldi ancak FSMO rolleri taşıma işlemi öncesi, taşıma işlemini yapacağımız rolleri detaylıca incelemekte fayda olduğunu düşünüyorum.

1- Schema Master

Active Directory (AD) ortamında Schema Master FSMO rolü, Şema üzerinde yapılan değişikliklerin yönetiminden sorumlu olan hayati bir bileşendir. AD Şema'sı, ortamınızdaki tüm Object Class'lar (nesne sınıfları) ve Attribute'lerin (öz niteliklerinin) nasıl yapılandırıldığını belirler. Dolayısıyla, bu rol, Active Directory'nin genişletilebilirliğini ve esnekliğini sağlamak için kritik bir görev üstlenir.

Şema'da yeni bir Class veya Attribute eklemek gibi bir değişiklik yapmak istediğinizde bu değişiklikler, yalnızca Schema Master rolünü üstlenen Domain Controller üzerinden yapılabilir. Bu, Schema Extention (şema genişletmeleri) veya diğer önemli değişiklikler sırasında yalnızca bir otoritenin tüm işlemleri kontrol ettiğinden emin olmanızı sağlar. Böylece, Active Directory Forest yapısındaki tüm Domain Controller'lar, bu değişikliklerin doğruluğundan emin olarak senkronize olabilir.

Schema Master rolü devre dışı kaldığında, Şema üzerinde herhangi bir değişiklik yapılması engellenir, ancak bu durum AD'nin genel işleyişini aksatmaz. Yani, kullanıcılar, Gruplar ve diğer AD nesneleri normal şekilde yönetilmeye devam edebilir; ancak Şema üzerinde yapılacak yeni değişiklikler beklemeye alınır. Özellikle, Exchange Server gibi uygulamalar, AD Şema'sını genişletmek zorunda kaldıklarında, Schema Master'ın etkin ve erişilebilir olması hayati önem taşır.

Bir Forest içinde yalnızca bir Schema Master olabileceğini hatırlatmakta fayda var. Bu durum, Şema değişiklikleri sırasında olası çakışmaları ve tutarsızlıkları önlemek amacıyla tasarlanmıştır. Schema Master rolünün başka bir Domain Controller'a devredilmesi, dikkatle planlanması gereken bir süreçtir. Yanlış bir adım, AD ortamında ciddi sorunlara yol açabilir. Genellikle, bu rol, yüksek kapasiteli ve güvenilirliği kanıtlanmış bir Domain Controller üzerinde barındırılır.

Schema Master rolünün doğru yönetimi, özellikle büyük ve karmaşık AD ortamlarında kritik bir rol oynar. Şema değişiklikleri, AD'nin temel yapısını etkilediği için, burada yapılacak hataların tüm ortamı etkileme potansiyeli vardır. Bu nedenle, Schema Master rolünü devralacak olan Domain Controller'ın iyi yapılandırılması ve güvenliğinin sağlanması şarttır.

Bu rol, Forest içerisinde tektir.

2- Domain Naming Master

Domain Naming Master FSMO rolü, Active Directory (AD) ortamında oldukça kritik bir görev üstlenir. Bu rol, AD Forest'ındaki Domain adlandırma süreçlerini kontrol eden merkezi bir otorite olarak çalışır. Yeni bir Domain oluşturulması veya mevcut bir Domain'in silinmesi gibi işlemler, yalnızca Domain Naming Master tarafından gerçekleştirilir. Bu, AD ortamında benzersiz ve çakışmasız bir adlandırma şeması sağlamak için son derece önemlidir.

Daha başka bir ifade ile Active Directory (AD) ortamında her Domain'in benzersiz bir isimle tanımlanmasını sağlar ve aynı isim alanına sahip iki Domain'in bulunmasını engeller. Bu, AD ortamında isim çakışmalarının önlenmesi ve sistemin tutarlı bir şekilde çalışması için kritik bir rol oynar. Yani, bu rol sayesinde bir Forest içinde aynı isme sahip birden fazla Domain oluşturulamaz, bu da adlandırma şemasının benzersiz ve çakışmasız kalmasını garanti eder.

AD ortamında bir Forest, birden fazla Domain içerebilir. Her Domain, kendi içindeki nesneleri ve kaynakları yönetmek için belirli bir isim alanı kullanır. Domain Naming Master, bu Domain'lerin isim alanlarının benzersizliğini garanti altına alır. Yeni bir Domain eklenmek istendiğinde, bu işlem Domain Naming Master FSMO rolüne sahip Domain Controller tarafından kontrol edilir ve onaylanır. Böylece, aynı Forest içinde aynı isim alanına sahip birden fazla Domain oluşturulması engellenir.

Domain Naming Master rolü, yalnızca bir Forest içinde bulunur ve bu rolü barındıran Domain Controller, diğer tüm Domain Controller'lar arasında adlandırma işlemleriyle ilgili tek yetkili olarak kabul edilir. Eğer bu rolün barındırıldığı Domain Controller devre dışı kalırsa, yeni Domain oluşturma veya mevcut bir Domain'i kaldırma gibi işlemler gerçekleştirilemez. Ancak, bu durum, var olan Domain'lerin çalışmasını etkilemez; sadece yeni adlandırma işlemleri yapılamaz.

Bu rolün önemi, özellikle büyük ve karmaşık AD ortamlarında daha da belirginleşir. Domain Naming Master, Forest içindeki her Domain'in benzersiz bir isimle tanımlanmasını sağlar ve bu isimlerin çakışmasını önler. Bu, AD'nin bütünlüğünü ve tutarlılığını korumak için kritik bir işlevdir.

Domain Naming Master FSMO rolünün devredilmesi gerektiğinde, bu işlem dikkatle planlanmalı ve gerçekleştirilmelidir. Yanlış yapılandırmalar, AD ortamında ciddi sorunlara yol açabilir ve Forest'taki Domain'lerin isimlendirme bütünlüğünü tehlikeye atabilir. Bu nedenle, Domain Naming Master rolünün doğru bir şekilde yönetilmesi ve güvenliğinin sağlanması, AD ortamının uzun vadeli başarısı için vazgeçilmezdir.

Bu rol, Forest içerisinde tektir.

3- PDC Emulator

Active Directory ortamında, belirli kritik yönetim görevlerinin tek bir Domain Controller üzerinde toplanması gerekir. Bu görevlerden biri olan PDC Emulator FSMO rolü, bu sorumluluğu üstlenen Domain Controller'ın, organizasyon içinde merkezi bir otorite olarak hizmet vermesini sağlar. PDC Emulator FSMO rolünü üstlenen bir Domain Controller, diğer hiçbir FSMO rolünü barındırmasa bile, sistemde Primary Domain Controller (PDC) olarak görev yapar ve bu rol, birkaç kritik işlevin sorumluluğunu taşır.

PDC Emulator FSMO rolünü tutan bir Domain Controller, özellikle zaman senkronizasyonu, parola değişiklikleri ve Kerberos Authentication (kimlik doğrulama) süreçlerinde merkezi bir rol oynar. Tüm sistemin zaman senkronizasyonu, PDC Emulator FSMO rolünü üstlenen Domain Controller tarafından yönetilir, bu da sistem genelindeki tüm cihazların saatlerinin doğru ve uyumlu olmasını sağlar. Zaman senkronizasyonu, güvenlik açısından kritik olan zaman damgalı işlemler ve log kayıtlarının tutarlılığı için hayati öneme sahiptir.

Ayrıca, PDC Emulator, parola değişikliklerinin anında replikasyonunu (Urgent Replication) sağlayarak, kullanıcıların güncellenmiş şifrelerinin hızlı bir şekilde diğer Domain Controller'lar tarafından tanınmasını mümkün kılar. Bu işlev, kullanıcıların hesaplarının güvenliğini artırır ve sistemdeki kimlik doğrulama süreçlerinin tutarlılığını sağlar. Kerberos Authentication sürecinde de PDC Emulator, belirli durumlarda merkezi bir otorite olarak hareket eder, bu da kimlik doğrulamanın güvenli ve hızlı bir şekilde yapılmasını sağlar.

PDC Emulator FSMO Erişilemezse?

PDC Emulator FSMO rolünü tutan Domain Controller erişilemez hale geldiğinde, parola değişiklikleri, zaman senkronizasyonu ve Kerberos Authentication (kimlik doğrulama) süreçlerinde belirli aksaklıklar meydana gelir. Ancak, bu süreçlerin bir kısmı geçici çözümlerle sürdürülebilir.

1- Parola Değişiklikleri

PDC Emulator FSMO rolünü tutan Domain Controller, kullanıcıların parolalarını değiştirdiklerinde, bu değişikliklerin acil replikasyon (Urgent Replication) ile diğer Domain Controller'lara hemen yansıtılmasını sağlar. PDC erişilemez hale geldiğinde, bu acil replikasyon gerçekleşmez. Sonuç olarak, parola değişiklikleri hemen diğer Domain Controller'lara yayılmaz ve bu durum geçici bir süreyle kimlik doğrulama süreçlerinde tutarsızlıklara neden olabilir. Diğer DC'ler kullanıcıların eski parolalarını kabul etmeye devam edebilir ve bu da kullanıcıların geçici olarak yeni parolalarıyla oturum açamamalarına yol açabilir.

PDC Emulator FSMO rolü olmadan da parola değişikliği yapabilmenizin nedeni, her Domain Controller'ın kendi veritabanı olan NTDS.dit içinde kullanıcı hesapları ve şifre bilgilerini yerel olarak tutmasıdır. Bir kullanıcı parolasını değiştirdiğinde, bu değişiklik ilk olarak kullanıcıya hizmet veren DC tarafından işlenir ve hemen bu DC'nin veritabanına kaydedilir.

PDC Emulator rolü, bu parola değişikliğinin acil replikasyon (Urgent Replication) ile diğer DC'lere hemen yayılmasını sağlar. Ancak, PDC erişilemez olduğunda bile, parola değişikliği yerel DC üzerinde gerçekleştirilebilir. Parolanın tüm DC'ler arasında senkronize edilmesi biraz gecikebilir, ancak bu, parola değişikliğini engellemez. Bu yüzden, PDC olmadığında bile kullanıcılar parolalarını değiştirebilirler, sadece bu değişikliklerin diğer DC'ler tarafından tanınması biraz zaman alabilir.

2- Zaman Senkronizasyonu

PDC Emulator FSMO rolü, Active Directory ortamındaki zaman senkronizasyonundan sorumludur. PDC Emulator, orman içindeki diğer DC'lere zaman kaynağı olarak hizmet eder. PDC erişilemez hale geldiğinde, diğer DC'ler zaman senkronizasyonu için alternatif zaman kaynaklarına başvurur. Bu, genellikle harici bir zaman sunucusu (NTP) veya alternatif bir DC olabilir. Zaman senkronizasyonu geçici olarak etkilenebilir, ancak düzgün yapılandırılmış bir Network'te bu etki minimal olur ve sistem genelindeki zaman senkronizasyonu sürdürülebilir.

3- Kerberos Authentication

PDC Emulator FSMO rolü, Kerberos Authentication sürecinde belirli senaryolarda merkezi bir rol oynar, özellikle de kullanıcıların hesap kilitleme veya parolalarının doğrulanması gibi durumlarda. PDC Emulator erişilemez hale geldiğinde, Kerberos Authentication süreci devam eder, ancak hesap kilitleme gibi olayların doğrulanması gecikebilir veya hatalı olabilir. Diğer DC'ler, PDC ile iletişim kuramadan kendi lokal veritabanlarındaki bilgilere dayanarak kimlik doğrulama işlemlerini sürdürür, ancak bu süreçte bazı tutarsızlıklar ortaya çıkabilir.

NOT: PDC Emulator FSMO rolü, Group Policy değişikliklerinden doğrudan sorumlu değildir. Group Policy'ler, AD ortamında tüm Domain Controller'lar arasında senkronize edilir ve herhangi bir Domain Controller'da yapılan değişiklikler, normal AD replikasyon süreciyle diğer Domain Controller'lara yayılır. PDC Emulator'ün görevleri arasında Group Policy yönetimi bulunmaz; bu, Domain Controller'ların genel replikasyon işlevlerinin bir parçasıdır.

Bu rol, Domain bazlı olup, Forest ortamındaki tüm Domain'lerde bulunur.

4- RID Master

Active Directory Domain yapısı içerisindeki her bir obje, benzersiz bir kimlik numarasıyla tanımlanır. Bu benzersiz kimlik numaraları, Active Directory nesnesi oluşturulduğunda sistem tarafından otomatik olarak atanır ve bu numaralara Relative Identifier (RID) adı verilir. RID, nesnenin Domain içerisindeki benzersizliğini sağlayan bir bileşendir ve nesneye atanan Security Identifier (SID) numarasının bir parçası olarak kullanılır. Her Domain'in kendine ait sabit bir SID'si vardır, bu SID, Domain içerisindeki tüm nesnelerin kimliğini oluştururken temel alınır. RID ise, bu sabit SID'nin sonuna eklenen ve nesnenin Domain içinde benzersiz olmasını sağlayan numaradır.

Örneğin, bir Active Directory Domain'inde bir User nesesi oluşturulduğunda, bu User nesesine otomatik olarak bir SID atanır. Bu SID, iki ana bileşenden oluşur. Bunlar, Domain'in sabit SID'si (Domain SID) ve bu Domain içinde yalnızca o User nesesine atanmış olan benzersiz RID numarasıdır. Domain içerisindeki her nesnenin benzersiz olmasını sağlayan bu sistem, Active Directory'nin güvenli ve tutarlı bir kimlik yönetimi yapısına sahip olmasını mümkün kılar.

RID Master FSMO rolü, Domain içerisindeki her Domain Controller'a belirli bir miktarda RID havuzu tahsis etmekle görevlidir. Bu havuzlar, Domain Controller'ların yeni nesneler oluştururken kullanacakları RID numaralarını içerir. Domain Controller'lar, tahsis edilen bu havuzlardan yeni nesnelere RID ataması yapar. Ancak, bir Domain Controller'ın RID havuzu tükenirse, yeni bir RID havuzu almak için RID Master'a başvurması gerekir. Bu talep üzerine RID Master, ilgili Domain Controller'a yeni bir RID havuzu tahsis eder. Bu işlem, Domain içerisindeki SID'lerin benzersizliğini ve çakışma yaşanmamasını garanti altına alır.

RID Master rolü, sadece RID havuzlarının dağıtımından sorumlu olmakla kalmaz, aynı zamanda Domain'ler arası nesne taşımalarında da kritik bir görev üstlenir. Bir nesne, bir Domain'den başka bir Domain'e taşındığında, eski Domain’deki RID bileşeni geçersiz hale gelir ve yeni Domain'de bu nesneye yeni bir RID atanır. Bu süreç, RID Master tarafından yönetilir ve Domain'ler arası güvenli ve tutarlı bir kimlik yönetimi sağlanmış olur.

Bu rolün sorunsuz çalışmaması, Domain içerisinde ciddi operasyonel aksaklıklara neden olabilir. Örneğin, Domain Controller'lar yeni nesneler oluşturamaz hale gelebilir veya mevcut nesneler üzerinde gerekli işlemler yapılamayabilir. Bu da Domain içerisindeki tüm operasyonları durma noktasına getirebilir ve sistemin güvenliği açısından ciddi zafiyetlere yol açabilir. RID Master'ın sürekli erişilebilir ve işlevsel olması, Active Directory yapısının stabilitesi ve güvenliği için kritik öneme sahiptir.

RID Master FSMO rolü, Domain içerisindeki diğer tüm Domain Controller'larla uyumlu bir şekilde çalışmalı ve her zaman erişilebilir olmalıdır. Erişimde yaşanacak herhangi bir kesinti, Domain'deki kimlik yönetim süreçlerini olumsuz yönde etkileyebilir. Bu yüzden, bu rolü barındıran sunucunun performansı ve güvenliği, Active Directory'nin genel sağlığı açısından büyük bir öneme sahiptir.

RID Master FSMO rolü, varsayılan olarak Domain yapısının ilk kurulduğu Primary Domain Controller üzerindedir. RID Master FSMO rolünü tutan Domain Controller, kendi üzerindeki RID havuzunda 1,073,741,823 (1 milyar 73 milyon 741 bin 823) adet RID numarası barındırır ki bu rakam, 2,147,483,647 (2 milyar 147 milyon 483 bin 647) üst sırınına kadar artırılabilmektedir.



RID Matser'ı barındıran Domain Controller'ın işlevsiz kalması ve yapınızdaki herhangi bir diğer Domain Controller'ın da barındırdığı bu sınırlı RID numarasının tükenmesi durumunda, RID numarasının tükendiği Domain Controller üzerinde yeni Active Directory nesneleri oluşturulamayacaktır ve the directory service has exhausted the pool of relative identifiers hatası oluşacaktır.

Bu rol, Domain bazlı olup, Forest ortamındaki tüm Domain'lerde bulunur.

5- Infrastructure Master

Infrastructure Master rolü, bir Active Directory (AD) Domain'inde önemli bir işleve sahiptir. Bu rol, Domain içindeki nesneler arasındaki referansları günceller. Özellikle, bir nesne başka bir Domain'deki bir nesneye referans verdiğinde, Infrastructure Master bu referansların doğru ve güncel olmasını sağlar. Örneğin, bir kullanıcı bir gruba eklendiğinde ve bu grup başka bir Domain'de olduğunda, Infrastructure Master bu üyeliğin doğru şekilde yansıtılmasını sağlar.

Senaryo

Domain-A'daki bir kullanıcı (User-A), Domain-B'deki bir gruba (Group-B) üye olsun. User-A'nın Distinguished Name (DN) bilgisi değiştiğinde, bu değişikliğin Domain-B'deki referanslarda güncellenmesi gerekir.

Adımlar

1- DN Değişikliği

» User-A'nın DN bilgisi değişti. Örneğin;

"CN=User-A,OU=OU-1,DC=Domain-A,DC=com" iken,
"CN=User-A,OU=OU-2,DC=Domain-A,DC=com" oldu.

2- Değişikliğin Algılanması

» Domain-A'daki Domain controller, User-A'nın DN değişikliğini algılar ve kaydeder.

3- Replikasyon Başlatma

» Domain-A'daki Domain controller, bu DN değişikliğini diğer Domain controller'lara ve Global Catalog (GC) sunucularına iletir.

4- Global Catalog'un Güncellenmesi

» GC, bu DN değişikliğini alır ve kendi veritabanında günceller. GC, tüm Domain'lerden gelen belirli özniteliklerin kısmi kopyalarını içerir.

5- Infrastructure Master'ın (IM) Rolü

» IM, bu DN değişikliğini fark eder ve referansları güncellemek için harekete geçer. » IM, User-A'nın yeni DN bilgilerini almak için GC'ye başvurur.

6- Referansların Güncellenmesi

» IM, GC'den aldığı yeni DN bilgilerini kullanarak, Domain-B'deki Group-B gibi referansları günceller.

» Böylece, Group-B'nin üye listesinde User-A'nın yeni DN bilgisi doğru şekilde yer alır.

Özet

1- Değişiklik Algılama: UserA'nın DN bilgisi değiştiğinde, bu değişiklik DomainA'daki Domain controller tarafından algılanır ve kaydedilir.

2- Replikasyon: Değişiklik, diğer Domain controller'lara ve GC sunucularına iletilir.

3- IM'in Güncelleme İşlemi: IM, bu değişikliği fark eder ve IM, GC'den güncel DN bilgilerini alır. Daha sonra IM, DomainB'deki referansları günceller, böylece UserA'nın yeni DN bilgisi doğru şekilde yansır.

Infrastructure Master (IM) ve Global Catalog (GC) İlişkisi

IM (Infrastructure Master) ve GC (Global Catalog) rollerinin aynı sunucuda olmaması, Microsoft'un Active Directory tasarımı ve yönetimi konusunda önerdiği bir Best Practice yaklaşımdır. Ancak bu öneri, belirli koşullar ve yapılandırmalar için geçerlidir. Microsoft’un bu öneriyi yapmasının nedeni, Active Directory ortamında veri tutarlılığını ve doğru referans yönetimini sağlamaktır.

IM ve GC Neden Aynı Sunucuda Olmamalı?

1. Veri Tutarlılığı Sorunları

» Durum: IM, Domain içindeki nesnelerin diğer Domain’lerdeki nesnelere verdiği referansları yönetir ve günceller. GC ise tüm forest’taki tüm Domain’lerin kısmi bir kopyasını tutar.

» Sorun: IM ve GC aynı sunucuda bulunduğunda, IM referans bilgilerini kendi sunucusundaki GC’den alır. Ancak, bu durumda IM, referans bilgilerini diğer Domain’lerdeki değişikliklerle karşılaştırmaz. Çünkü GC, bu bilgileri zaten içerir.

» Sonuç: IM, güncel olmayan bilgileri kullanarak referans güncellemelerini yapabilir. Bu da, referans verilen nesnelerin (örneğin, başka bir Domain’deki kullanıcılar veya gruplar) doğru şekilde güncellenmemesine ve veri tutarsızlıklarına yol açabilir.

2. GC’nin Tamamlayıcı Rolü

» Durum: GC, tüm forest’taki nesnelerin bir kopyasını tutar, ancak yalnızca kısmi bir replikasyon içerir (örneğin, yalnızca en sık kullanılan öznitelikler replike edilir).

» Sorun: IM, referans bilgilerini güncellerken, bu kısmi verilerle çalışır. Eğer IM ve GC aynı sunucuda olursa, IM’in referans güncellemeleri bu kısmi verilere dayanarak yapılır ve bu, eksik veya hatalı güncellemelerle sonuçlanabilir.

» Sonuç: IM’in aynı sunucuda çalıştığı GC’den aldığı bilgiler, her zaman en güncel olmayabilir. Bu da, diğer Domain’lerdeki nesnelerin doğru şekilde yönetilmesini engelleyebilir.

IM ve GC Neden Ayrı Sunucuda Olmalı?

1. Veri Tutarlılığını Sağlama

» Durum: IM, kendi Domain’inde yer alan nesnelerin diğer Domain’lerdeki referanslarını günceller ve yönetir.

» Fayda: IM'in cross-Domain referanslarını güncellerken her zaman GC'den bilgi alması, IM'in doğru ve güncel bilgilerle çalışmasını sağlar. GC, tüm Domain'lerdeki nesnelerin bir kopyasını tuttuğu için, IM bu bilgileri kullanarak referansların en güncel ve doğru şekilde güncellenmesini sağlar. Bu durum, veri tutarlılığını korur ve referans hatalarını önler.

» Sonuç: Bu yaklaşım, IM’in daha güncel ve doğru bilgilerle çalışmasını sağlar. Böylece, Cross-Domain referansları doğru şekilde güncellenir ve veri tutarlılığı korunur.

2. GC’nin Kapsamlı Verisi

» Durum: GC, tüm forest’taki Domain’ler hakkında kısmi veri replikasyonu yapar. Ancak bu veriler, tam ve güncel bilgiler içermeyebilir.

» Fayda: IM, GC’den bağımsız olarak çalıştığında, diğer Domain controller’lardan aldığı tam verilerle çalışır. Bu, IM’in Cross-Domain referanslarını doğru şekilde yönetmesini sağlar.

» Sonuç: IM’in, Domain’ler arası referans güncellemelerini daha doğru ve güvenilir bir şekilde yapması sağlanır.

3. Performans ve Yük Dağılımı

» Durum: IM ve GC, her biri kendi görevlerini yerine getirmek için belirli kaynaklara ihtiyaç duyar.

» Fayda: Bu rollerin farklı sunucularda olması, sunucu üzerindeki yükü dağıtır ve her iki rolün de performansını artırır.

» Sonuç: Sunucuların performansı ve işlevselliği artar, IM ve GC’nin görevleri daha verimli bir şekilde yerine getirilir.

Özet

» IM ve GC Aynı Sunucuda: IM, kendi sunucusundaki GC'den bilgileri alır. Bu GC, bilgilerinin güncel olup olmadığını anında kontrol edemez çünkü güncellemeler periyodik olarak gelir.

» IM ve GC Ayrı Sunucularda: IM, harici GC sunucularından bilgileri alır. Bu GC sunucuları, geniş bir replikasyon ağına sahip olduğundan, IM'in aldığı bilgilerin güncel olma olasılığı daha yüksektir.

Bu süreç, çapraz Domain referanslarının doğru ve güncel kalmasını sağlar. IM, referansları güncellerken GC'den aldığı bilgileri kullanır, böylece Active Directory'nin tutarlılığı korunur.

Bu rol, Domain bazlı olup, Forest ortamındaki tüm Domain'lerde bulunur.

Yukarıda bahsettiğim "Forest ortamındaki tüm Domain'lerde bulunur." ve "Forest bazında tektir." ifadlerimin altını doldurmam gerkirse örneğin, Forest yapınızda 3 ayrı Domain olduğunu, bunlardan 1 tanesinin Forest'ın ilk oluşturulduğu Parent Domain, diğer 2 tanesinin de Child Domain olduğunu varsayalım. İster Parent Domain, isterse de Child Domain olsun; Domain ortamının ilk kurulduğu ilk Server, Domain Controller görevindedir. Bu sebeple de aynı Forest içindeki farklı Domain'leri oluşturuan ilk Server'lar da kendi bulundukları Domain'ler içine Domain Controller görevindedir ancak buradaki FSMO rolleri noktasında bir ayrım söz konusudur.

Child Domain'ler, aynı Forest içindeki Parent Domain'e bağlıdırlar. Aynı Forest içindeki herhangi bir Domain'deki, herhangi bir Domain Controller'da FSMO rolleri sorgulama işlemi gerçekleştirdiğinizde çıkacak olan sonuçta, Schema Master ve Domain Naming Master FSMO rollerinin her zaman  her ikisinin de Forest bazında tek olduğunu görürsünüz. Bahsettiğim örnek yapıdaki gibi bir yapıda aksi belirtilmedikçe, yani roller taşınmadıkça bu iki Forest bazlı FSMO rolü, Parent Domain'deki Domain Controller'da bulunacaktır.



Bu roller elbette ki Child Domain'lerdeki Domain Controller'dan herhangi bir tanesine de taşınabilir! Burada unutulmaması gereken tek şeyin, bu iki FSMO rolünün tüm Forest ortamında tek olduğudur ki zaten yukarıdaki şemaya baktığınızda, hem Parent Domain'deki Domain Controller'lardaki hem de Child Domain'deki Domain Controller'lardaki kalan 3 FMO rolünün, sadece ilgili Domain'e ait olarak tüm Domain Controller'larda bulunduğunu görürsünüz.

FSMO (Flexible Single Master Operation) Rollerinin Transferi

FSMO (Flexible Single Master Operation) rollerinin transferi işlemine başlamadan önce bilmenizde fayda olduğunu düşündüğüm nokta; FSMO rollerinin transferi, başka bir ifade ile başka bir Domain Controller'a ya da birden çok Domain Controller'a taşıma işlemi, sadece bu makalenin konusu olan Migration işlemi için değil, aynı zamanda Load Balancing (yük dengeleme) amacı ile de kullanılabilmektedir. Yukarıda belirttiğimiz 5 rolün, tek bir Domain Controller'de barındırılması gibi zorunluluğun olmadığıdır.

Ben, bu makalemde tüm FSMO (Flexible Single Master Operation) rollerini, rollerin barındırıldığı Windows Server 2008 R2 işletim sistemli Domain Controller'dan, Domain ortamına sonradan eklediğim Windows Server 2022 işletim sistemli Additional Domain Controller'a taşıyarak hem PDC Emulator'ın taşınması ile bu Additional Domain Controller'ı Primary Domain Controller'a dönüştürmüş olacağım ki bu durumda Windows Server 2008 işletim sistemli eski Primary Domain Controller artık Additional Domain Controller olmuş olacak hem de PDC Emulator'dan kalan tüm rollerin taşınması ile tüm Forest ortamından Windows Server 2008 işletim sistemli Domain Controller'ları Demote edebilir, yani ortamdan kaldırabilir duruma gelebileceğim. Bu makalemde FSMO (Flexible Single Master Operation) Rollerinin Transferi işlemlerini GUI (Graphical User Interface) üzeinden yapacağım. Aynı işlemleri alternatif olarak CMD (Command Promt) ya da tek seferde PowerShell ile de gerçekleştirebilirsiniz.

RID Master, PDC Emulator ve Infrastructure Master Rollerinin Transferi

11- RID Master, PDC Emulator ve Infrastructure Master rollerin Transfer işlemi, Active Directory Users and Computers üzerinden yapılmaktadır. Herhangi bir öncelik sırası yoktur ancak ben ilk olarak RID Master FSMO rol aktarım işlemini gerçekleştireceğim.

11.1- Tüm Roller, Windows Server 2008 R2 işletim sistemli Domain Controller'da olduğu için, bu DC üzerinde Active Directory Users and Computers'ı açıyor, Domain üzerinde sağ tıklayarak Operations Masters... seçeneğini seçiyorum.



11.2- Karşıma pencerede RID, PDC ve Infrastructure sekmeleri yer alıyor.
RID sekmesi altında işaretli alan, FSMO rollerinin taşınacağı hedef Domain Controller'ı göstermelidir ancak varsayılan olarak, daha önce herhangi bir değişiklik yapılmadıysa, rollerinin taşınacağı hedef Domain Controller yerine, rollerin tutulduğu Domain Controller'ı gösterecektir. Bu yüzden ilk olarak rollerinin taşınacağı hedef Domain Controller seçimi yapmak zorundayız.



11.3- Hedef Domain Controller seçim için yine Domain üzerinde sağ tıklayıp, bu sefer Change Domain Controller... seçeneğini seçiyorum.



11.4- Change Directory Server penceresinde This Domain Controller or AD LDS instance seçeğini seçerek, FSMO rollerinin taşınacağı hedef Domain Controller'ı seçerek OK butonuna basıyorum.



11.5- Tekrar Domain üzerinde sağ tıklayarak Operations Masters... seçeneğini seçtiğimde, işaretli alanın bu sefer rollerinin taşınacağı hedef Domain Controller olarak değiştiğini görebiliyorum. RID Master FSMO rol Transfer işlemi için Change... butonuna basıyorum.



11.6- Karşıma çıkan diyalog kutusunda Yes butonuna basarak işlemi onaylıyorum.



11.7- RID Master FSMO rol Transfer işlemi başarılı bir şekilde gerçekleştirildi.




11.8- RID sekmesi altında RID Master FSMO rol Transfer işlemi için yaptığım işlemlerin aynısını PDC Emulator FSMO rolü için PDC sekmesi altında, Infrastructure Master FSMO rolü için ise Infrastructure sekmeleri altında gerçekleştiriyorum.










12- Buraya kadarki adımlarda gerçekleştirdiğim işlemlerde; RID Master, PDC Emulator ve Infrastructure Master rollerinin Windows Server 2022 işletim sistemli Domain Controller'a aktardım. Tekrar

PowerShell komutuyla FSMO (Flexible Single Master Operation) rollerini barındıran Domain Controller bilgisini çektiğimde RID Master, PDC Emulator ve Infrastructure Master rollerinin Windows Server 2022 işletim sistemli Domain Controller'a aktarılmıştır. Ek olarak, tek başına PDC Emulator rolünün taşınmasının, bu rolün taşındığı hedef DC'yi Primary Domain Controller görevine getirdiğinden bahsetmiştim. Tekrar

PowerShell komutuyla Primary Domain Controller görevini Windows Server 2022 işletim sistemli Domain Controller'ın üstlendiğini görebiliyorum.

Domain Naming Master Rol Transferi

13- Domain Naming Master FSMO rol taşıma işlemi, Active Directory Domains and Trusts üzerinden gerçekleştirilmektedir. Bu sefer Active Directory Users and Computers üzerinde Domain üzerinde sağ tıklayıp bu sefer Change Domain Controller... seçeneğini seçtiğimiz gibi, burada bu seçimi yapmıyoruz çünkü Active Directory Users and Computers üzerinde yaptığımız seçim, burada da geçerli olmaktadır.

Active Directory Domains and Trusts üzerinde sağ tıklayarak Operations Masters... seçeneğini seçiyorum.



13.1- Rollerinin taşınacağı hedef Domain Controller'ın, rolü taşımak istediğim Domain Controller olduğunu görebiliyorum. Domain Naming Master rol Transfer işlemi için Change... butonuna basıyorum.



13.2- Karşıma çıkan diyalog kutusunda Yes butonuna basarak işlemi onaylıyorum.



13.3- FSMO rol Transfer işlemi başarılı bir şekilde gerçekleştirildi.

Schema Master Rol Transferi

14- Schema Master rol Transfer işlemi, Active Directory Schema Management Tool üzerinden yapılmaktadır ancak bu Management Tool, varsayılan olarak Active Directory Users and Computers ve Active Directory Domains and Trusts gibi Administrative Tools içinden erişilebilir durumda değildir.

14.1- Active Directory Schema (Management Tool) erişimi için RUN (çalıştır) üzerinde MMC yazarak Consol açıp, File menüsünden Add/Remove Snap-in... seçeneğini seçiyorum.



14.2- Açılan pencerede sol taraftaki listede Active Directory Schema'nın görülmediğini göreceksiniz.



14.3- Bunu görünür hale getirebilmek için RUN (çalıştır) üzerinde regsvr32 schmmgmt.dll komutunu kullanarak schmmgmt.dll'ini tetikletiyorum.




14.4- schmmgmt.dll'ini tetiklettikten sonra Active Directory Schema görünür hale geldi. Tool'u seçerek ortadaki Add > butonuna basarak listenin sağ tarafına aldıktan sonra OK butonuna basarak pencereyi kapatıyorum.



14.5- Active Directory Schema üzerinde sağ tıklayıp, açılan menüden Operations Master... seçeneğini seçiyorum.



14.6- Active Directory Users and Computers üzerinde RID, PDC ve Infrastructure sekmeleri altında olduğu gibi Schema Master rolünün taşınacağı hedef Domain Controller yerine, rollerin tutulduğu Domain Controller'ı göstermektedir.



14.7- Hedef Domain Controller seçim için yine Active Directory Schema üzerinde sağ tıklayıp bu sefer Change Active Directory Domain Controller... seçeneğini seçiyorum.



14.8- Change Directory Server penceresinde This Domain Controller or AD LDS instance seçeğini seçerek, FSMO rollerinin taşınacağı hedef Domain Controller'ı seçerek OK butonuna basıyorum.



14.9- Tekrar Active Directory Schema üzerinde sağ tıklayarak Operations Masters... seçeneğini seçtiğimde işaretli alanın bu sefer rollerinin taşınacağı hedef Domain Controller olarak değiştiğini görebiliyorum. RID Master FSMO rol Transfer işlemi için Change... butonuna basıyorum.




14.10- Karşıma çıkan diyalog kutusunda Yes butonuna basarak işlemi onaylıyorum.



14.11- Schema Master FSMO rol Transfer işlemi başarılı bir şekilde gerçekleştirildi.




15- 5 adet FSMO rolünün Windows Server 2022 işletim sistemli Domain Controller'a aktarım işlemini tamamlamış oldum. Tekrar

PowerShell komutuyla FSMO (Flexible Single Master Operation) rollerini barındıran Domain Controller bilgisini çektiğimde RID Master, PDC Emulator ve Infrastructure Master rollerinin Windows Server 2022 işletim sistemli Domain Controller'a aktarılmıştır.

Domain Functional Level (DFL) ve Forest Functional Level (FFL) Durumu

Microsoft, piyasaya sürüldüğü her yeni nesil Windows Server işletim sistemine ek fonksiyonellik ve daha güçlü, daha kullanışlı özellikler eklemektedir ve bu yeni nesil işletim sistemlerinin geriye dönük uyumlu çalışmasını da istemektedir. Bu fonksiyonellik seviyeleri, ortamdaki Domain Controller'larda hangi gelişmiş özelliklerin yer alıcağını belirlemektedir. Burada seviyeyi belirleyen etken, en eski işletim sistemidir. Functional Level’ların yükseltilmesi; piyasaya sürülen yeni versiyon Windows Server'ların ek özelliklerini kullanabileceğiniz anlamına gelmektedir.

Migration için tüm işlemlerimizi tamamladıktan sonra Windows Server 2022 işletim sistemli sunucumuzu Primary Domain Controller olarak tanımladık. Forest'ımızdaki en güncel Windows Server işletim sistemi artık Windows Server 2022'dir ancak Domain Controller Migration işlemi gerçekleştirmeden önce Windows Server 2008 R2 işletim sistemi üzerinde çalışan Primary Domain Controller'ımızın Forest Functional Level'ı (FFL)'ı, kendisinin alabileceği en yünsek FFL değeri olarak Windows Server 2008 R2, Domain Functional Level'ı (DFL) ise, yine kendisinin alabileceği en yüksek değer olan Windows Server 2008 R2 seviyesindeydi.

Windows Server 2022 işletim sistemli sunucuyu mevcut Domain ortamında Additional Domain Controller olarak yapılandırdığımda Domain Controller olarak yapılandırdığım sunucu işletim sistemi, versiyon olarak mevcut Domain Controller'ın üstünde olsa bile Domain ortamı, Windows Server 2008 R2 işletim sistemli sunucu ile kurulduğu ve Promote etme adımında bu Functional Level seviyeleri bu şekilde seçildiği için mevcut Domain ortamında Additional Domain Controller olarak yapılandırılan üst versiyon sunucu, bu mevcut Funtional Level seviyelerine aynen olduğu gibi sahip olacaktır. Yani, Domain Controller Migration işlemi sonrasında Windows Server 2022 işletim sistemli Domain Controller'ın Primary Domain Controller olması, Functional Level değişliği yapmayacaktır.

16- Windows Server 2022 işletim sistemli Primary Domain Controller üzerinde aşağıdaki PowerShell komutuyla Domain Functional Level (DFL) ve Forest Functional Level (FFL) durumlarının Windows Server 2008 R2 olduğunu görüyorum.

17- Windows Server 2022 işletim sistemli Primary Domain Controller üzerinde aşağıdaki PowerShell komutunu çalıştırarak mevcut ortamımdaki tüm Domain Controller'ların bir listesini alıyorum.

18- Aynı şekilde yine Windows Server 2022 işletim sistemli Primary Domain Controller üzerinde aşağıdaki PowerShell komutunu çalıştırarak benzer şekilde mevcut ortamımdaki tüm Domain Controller'ların Host Name ve işletim sistemi versiyon bilgilerini alıyorum.

Domain Functional Level (DFL) ve Forest Functional Level (FFL) Yükseltme

Domain Controller Migration işleminden sonra mevcut Forest ortamınızda, ör. herhangi bir uygulama bağımlılığı sebebi ile, eski versiyon Domain Controller barındırma zorunluluğunuz yoksa, eski versiyon Domain Controller(lar)ın Forest ortamında bulunmasının da bir anlamı olmaycaktır. Çünkü Forest ortamınızda Domain Controller olarak en yüksek işletim sistemli Windows Server versiyonu artık Windows Server 2022 olduğu için, bu versiyonun getirdiği fonksiyonellik seviyeleri ile daha üst seviyedeki Windows Server fonksiyonellik nimetlerinden yararlanmanız faydanıza olacaktır.

Functinal Level'lar, piyasaya sürülen yeni versiyon Windows Server'ların ek özelliklerini kullanabileceğiniz anlamına geldiği gibi, aynı zamanda da ortamınızda barındırabileceğiniz Domain Controller'ların hangi versiyonda olabileğini de belirleyen unsurlardır. Functional Level kavramı ile daha derin ve detaylı bilgiye, Forest Functional Level (FFL) ve Domain Functional Level (DFL) Kavramı makalemden ulaşabilirsiniz.

19- Bu bilgiler ışığında mevcut Forest ortamınızdaki eski versiyon Domain Controller'ları Demote işlemine tabi tutmadan, yani Forest ortamından tamamen kaldırmadan, Functional Level Raise Etme, yani yükseltme işlemi yapamazsınız. Functional Level Raise Etme işlemi yapmaya kalktığınızda ise aşağıdaki hata ile karşılaşırsınız.



20- Mevcut Forest ortamımdaki eski versiyon Windows Server 2008 R2 Domain Controller'ımı Demote etmek suretiyle tamamen kaldrım. Windows Server 2022 işletim sistemli Primary Domain Controller üzerinde aşağıdaki PowerShell komutunu çalıştırarak mevcut ortamımdaki Domain Controller'ların bir listesini alıyorum. Görüldüğü gibi artık Forest ortamımda hiç bir eski versiyon Domain Controller bulunmuyor.

NOT: Makalemin bu kısmında, arka planda, Windows Server 2008 R2 işletim sistemli Domain Controller'ı Demote ettim.

21- Aynı şekilde yine Windows Server 2022 işletim sistemli Primary Domain Controller üzerinde aşağıdaki PowerShell komutunu çalıştırarak benzer şekilde mevcut ortamımdaki tüm Domain Controller'ların Host Name ve işletim sistemi versiyon bilgilerini alıyorum.

22- Artık Forest ortamımda hiç bir eski versiyon Domain Controller bulmadığına göre, Domain Functional Level (DFL) ve Forest Functional Level (FFL) Raise etme işlemini gerçekleştirebilirim. Bunun için aşağıdaki PowerShell komutlarını ayrı ayrı çalıştırak, Domain Functional Level (DFL) ve Forest Functional Level seviyelerimi Windows Server 2016 seviyesine yükseltiyorum.

Microsoft, Windows Server 2022'de de yeni bir Functional Level yükselemesi gerçekleştirmedi. Bu nedenle Windows Server 2022'de Raise edilebilecek en yüksek seviyeli Functional Level, Windows Server 2016'dır.



Görüldüğü üzere yeni platforma geçiş, sadece teknolojik bir güncelleme değil, aynı zamanda daha güvenli, verimli ve yönetilebilir bir IT altyapısına geçiş anlamına gelmektedir. Bu migration, özellikle güvenlik ve performans gibi kritik alanlarda önemli iyileştirmeler sağlamaktadır.

Yapılan bu detaylı inceleme ve analizler, Windows Server 2022'nin, modern güvenlik tehditlerine karşı koymada ve bulut teknolojileriyle entegrasyonda Windows Server 2008 R2'ye göre ne kadar üstün olduğunu göstermektedir. Ayrıca, bu geçiş süreci, mevcut sistemlerin sürdürülebilirliğini ve uyumluluğunu artırmakta, kuruluşların gelecekteki teknoloji güncellemelerine ve yeniliklerine adapte olmasını kolaylaştırmaktadır.

Sonuç olarak, Domain Controller'ın Windows Server 2022'ye başarılı bir şekilde taşınması, bir kuruluşun teknoloji yolculuğunda önemli bir dönüm noktasıdır. Bu geçiş, iş süreçlerinin kesintisizliğini ve veri güvenliğini önemli ölçüde artırarak, kuruluşun teknolojik olarak ileriye doğru büyük bir adım atmasını sağlar. Okuyuculara önerim, bu tür bir migration sürecini planlarken detaylı bir hazırlık ve uygun test süreçleri uygulamaları, böylece sistemlerinin ve verilerinin bu geçiş sırasında maksimum güvenlik ve performansla korunmasını sağlamalarıdır. Bu, sadece teknolojik bir geçiş değil, aynı zamanda kuruluşun genel başarısı için stratejik bir yatırımdır.

Faydalı olması dileğiyle...