Windows Server 2012 R2'den, Windows Server 2016'ya Domain Controller Migration

Windows Server 2012 R2'den Windows Server 2016'ya migration, modern IT altyapılarını güncel tutmak ve mevcut teknolojik gelişmelerden faydalanmak için kritik bir süreçtir. Bu geçiş, özellikle güvenlik, performans ve yönetim yeteneklerinde önemli iyileştirmeler sağlar, dolayısıyla kuruluşlar için stratejik bir değer taşır. Yeni özelliklerin ve gelişmiş güvenlik ayarlarının eklenmesi, Windows Server 2016'nın Windows Server 2012 R2'ye göre daha etkili bir platform olmasını sağlar.

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.

Senaryomuzda, ortamımızdaki Server bilgisayarın işletim sistemleri Windows Server 2012 R2'dir. Ortamımda, Migration (taşıma) işlemi için kullanacağım Windows Server 2012 R2 işletim sistemli bir Primary Domain Controller bulunmaktadır. Bu Windows Server 2012 R2 işletim sistemli Primary Domain Controller'ımı, yeni nesil, en son sürüm olan (Bu yazıyı yazdığım tarih itibari ile) Windows Server 2016 İşletim sistemli bir Server bilgisayara taşıyacağım. Burada amacım özetle, işletim sistemi Windows Server 2012 R2 olan Primary Domain Controller'ımı, Windows Server 2016 işletim sistemli bir Domain Controller yapmak olacaktır.

Kaynak ve Hedef Server Yapılandırmaları

Kaynak Ortam:

• Domain: firatboyan.com
• Hostname: SRV001A
• IP: 10.10.10.100
• DNS: 10.10.10.100
• FQDN: SRV001A.firatboyan.local
• İşletim Sistemi: Windows Server 2012 R2
• Görev: Primary Domain Controller
• Forest Funtional Level: Windows Server 2012 R2
• Domain Functional Level: Windows Server 2012 R2

Hedef Ortam:

Migration yapılacak hedef Server, işletim sistemi ilk kurulduğunda WORKGROUP olarak çalışan bir Standalone Server durumda olacaktır. İlk yapılması gereken; varsayılan olarak gelen, sistem tarafından atanan Hostname bilgisini değiştirmek ve statik IP ataması yapmak olacaktır. Bu adımlardan sonra da firatboyan.com Domain'ine Member Server olarak Join etmek olacaktır. Member Server olarak Join etme işlemi tamamlandıktan sonra, Active Directory Domain Services rolü kurularak Server, Additional Domain Controller durumuna getirilcektir. Tüm bu ifade ettiklerim yapıldıktan sonra ise tablo, aşağıdaki gibi olacaktır ve DC Migration (DC taşıma) işlemlerine başlayabilir duruma gelecektir.

• Domain: firatboyan.com
• Hostname: SRV001B
• IP: 10.10.10.200
• 1.DNS: 10.10.10.200
• 2.DNS: 10.10.10.100
• FQDN: SRV001B.firatboyan.local
• İşletim Sistemi: Windows Server 2016
• Görev: Additional Domain Controller
• Forest Funtional Level: Windows Server 2012 R2
• Domain Functional Level: Windows Server 2012 R2

NOT 1: Migration yapılacak hedef Server'a Active Directory Domain Services rolünü kurup, Additional Domain Controller olarak yapılandırmadan, Migration işlemini gerçekleştiremeyiz ancak ben, makalemin ana temasından sapmamak adına lab ortamım için, makalemi yazmadan önce, Windows Server 2016 işletim sistemli Server'ımı Member Server yaparak üzerinde Active Directory Domain Services rolünü kurup, Additional Domain Controller kurulum işlemini tamamladım.

Sizin kendi sistemlerinizde Migration Yapılacak Windows Server 2012 R2 işletim sistemli kaynak Server'ın Primary Domain Controller olarak çalışıyor, Migration Yapılacak Windows Server 2016 işletim sistemli hedef Server'ın da Member Server yapıldıktan sonra, Additional Domain Controller olarak hayata geçtiğini varsayarak Windows Server 2012 R2'den Windows Server 2016'ya Migration işlemlerime devam ediyorum.

Windows Server 2012 R2 - SRV001A Hostname'li Domain Controller



Windows Server 2016 - SRV001B Hostname'li Domain Controller

Domain Controller'ların Active Directory'deki Durumları

Windows Server 2012 R2 işletim sistemi versiyonlu Donamain Controller üzerindeki SRV001A Hostname'li sunucum bilgileri aşağıdaki gibidir.



Windows Server 2016 işletim sistemi versiyonlu Donamain Controller üzerindeki SRV001B Hostname'li sunucum bilgileri aşağıdaki gibidir.



Active Directory Migration işlemlerime, SRV001A ve SRV001B Server'larımdaki replikasyon durumunu kontrol ederek başlıyorum. replikasyon durumunu kontrol etmek için Repadmin /replsum komutunu kullanarak replikasyonların düzgün bir şekilde yapıldığını görüyorum.

Replikasyon Durumlarını İzleme

Görüldüğü gibi, repadmin /replsum komutu ile Active Directory Partition'ları başarılı bir şekilde replike olmuş durumda.





Son olarak, dcdiag komutu ile Migration Yapılacak Windows Server 2016 işletim sistemli hedef Additional Domain Controller'ımızın sağlık kontrolünü  yapıyoruz. Komut ekranında Domain Controller'ımızın tüm testleri geçtiğini görüntülüyoruz.

Artık Windows Server 2012 R2'den, Windows Server 2016'ya Migration için her şey hazır durumda. Migration için FSMO (Flexible Single Master Operations) rollerinin transfer işlemlerini gerçekleştireceğiz. Bunun için netdom query fsmo komutu ile FSMO Rollerinin Server'da olduğunu kontrol ediyorum.



FRMO rollerinin, Migration Yapılacak Windows Server 2012 R2 işletim sistemli SRV001A Hostname'li kaynak Server'ın üzerinde olduğunu görüyorum. Yapacağımız işlem; rollerimizi Migration yapılacak Windows Server 2016 işletim sistemli hedef Server'a taşımak olacak.

FSMO (Flexible Single Master Operation) Rollerinin İncelenmesi

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.

NOT 3: PDC Emulator, RID Master ve Infrastructure Master rolleri, yapınızdaki diğer Domain Controller'lara taşınarak yük dengelemesi sağlanabilir. ??

RID Master, PDC Emulator ve Infrastructure Master rollerin Transferi

Öncelikle RID Master, PDC Emulator ve Infrastructure Master rollerini taşıyacağız. Rollerin taşınması işlemine başlamadan önce, rolleri aktaracağımız Windows Server 2016 işletim sistemli, SRV001B Hostname'li hedef Server'a bağlantı kurmamız gerekmektedir. Bunun için Active Directory Migration Yapılacak Windows Server 2012 R2 işletim sistemli, SRV001A Hostname'li kaynak Server (Primary Domain Controller) üzerinde sağ tıklayarak Change Domain Controller... seçiyorum.



Açılan ekranda This Domain Controller or AD LDS instance altında rolleri taşımak istediğimiz Server seçilerek OK butonu tıklanır. Bu işlem gerçekleştirilmezse, rollerin aktarımı sırasında Change... butonuna tıkladığımızda hata verecektir.



RID Master, PDC Emulator ve Infrastructure Master rolleri, Active Directory Users and Computers üzerinden taşınmaktadır. Bu işlemler için rolleri taşıyacağımız Server'da Active Directory Users and Computers'ı açıp Domain üzerinde sağ tıklayarak Operations Masters seçilir ve tekrar her bir rol için ayrı ayrı Change Domain Controller... seçeneği ile, seçim yapmanıza da gerek yoktur.

RID Master FSMO Rolünün Transferi

Açılan ekranda RID Master rolünü taşınmak için Change... butonu göreceksiniz. Burada yukarıda bulunan DC adı mevcut rolün sahibi, altta bulunan kısım ise transfer edilecek yeri göstermektedir. Burada gördüğünüz bilgiler doğru ise Change... butonuna basınız.



Rolü taşımak isteyip istemediğinizi soran soruya YES butonuna basarak onaylıyoruz.



Eğer sunucular arasında iletişimde bir sorun yoksa aşağıdaki gibi başarılı bir şekilde rolün taşınması gerçekleşecektir.

PDC Emulator FSMO Rolünün Transferi

Bu işlemi de RID Master FSMO rolünün taşınması işlemindeki gibi gerçekleştirdim.

Infrastructure Master FSMO Rolünün Taşınması

Bu işlemi de RID Master FSMO rolünün taşınması işlemindeki gibi gerçekleştirdim.



RID Master, PDC Emulator ve Infrastructure Master rollerinin taşınması işlemini tamamladıktan sonra rollerin Migration yapacağımız Windows Server 2016 işletim sistemli, SRV001B Hostname'li hedef Server'a taşındığını görmek için netdom query fsmo komutunu çalıştıyorum.

Domain Naming Master ve Schema Master Rollerinin Transferi

Şimdi sıra, Domain Naming Master ve Schema Master Rollerinin aktarımına geldi.

Domain Naming Master rol transfer işlemi, Active Directory Domains and Trusts üzerinden gerçekleşmektedir. En yukarıdaki Active Directory Domains and Trusts üzerinde sağ tıklıyor, Operations Masters seçeneği seçilir.



Açılan ekranda aynı taşığımız diğer 3 rol gibi, yukarıda bulunan ana rolü taşıyan DC, aşağısındaki ise, taşınacak DC yer almaktadır. "Change..." Butonuna basıyorum.



Rolü taşımak isteyip istemediğinizi soran soruya YES butonuna basarak onaylıyoruz.





C) Şimdi sıra geldi Schma Master Rolünün taşınması işlemine.

Schema Master, default olarak görülmeyen tek roldür. Örn. MMC Snap-in'de görülmez. Schema'ya erişimi aktif etmek için, Windows+R ile çalıştırdığımız RUN(Çalıştır) penceresinde regsvr32 schmmgmt.dll komutu yazılıp, dll register edilmiş olunuyor.



schmmgmt.dll başarılı bir şekilde yüklendi.



Şimdi yine Windows + R tuşuna basarak RUN (Çalıştır) ekranını açıyoruz. Açılan ekranda MMC yazıp enter tuşuna basıyoruz.



Console ekranı açılacaktır. Bu ekranda File menüsü altında Add/remove Snap-in... seçilir.



Açılan ekranda sol tarafta Active Directory Schema kısmını tıklayınız ve Add > butonuna basarak sağ tarafa alınır ve OK butonuna tıklanarak Add/remove Snap-in ekranı kapatılır.





En yukarıdaki Active Directory Schema üzerinde sağ tıklanarak Change Active Directory Domain Controller... seçeneği seçilerek, Migration yapacağımız Windows Server 2016 işletim sistemli, SRV001B Hostname'li hedef Server seçilir ve bağlantı kurulur.





Tekrar en yukarıdaki Active Directory Schema üzerinde sağ tıklanarak Operations Master... seçeneği seçilerek, Change Schema Master penceresinde Migration yapacağımız Windows Server 2016 işletim sistemli, SRV001B Hostname'li hedef Server olduğundan emin olduktan sonra Change butonuna basılarak transfer işlemi gerçekleştirilmiş olur.





Açılan ekranda Change butonuna basılır ve rolü taşımak istiyor musunuz sorusuna YES butonuna tıklayarak devam edilir.



Rol başarılı bir şekilde taşınmıştır.



Rolleri aktardığımız Server olan SRV001A ve SRV001B üzerinde CMD ekranından netdom query fsmo komutu ile rolleri kontrol ettiğimizde, rollerinin tamamı, istediğimiz Server üzerine başarılı bir şekilde transfer edilmiştir.

Migration yaptığımız Windows Server 2012R2 işletim sistemli, SRV001A Hostname'li KAYNAK Server'nın durumu.



Migration yaptığımız Windows Server 2016 işletim sistemli, SRV001B Hostname'li HEDEF Server'nın durumu.

Migration sonrası Domain Functional Level (DFL) ve Forest Functional Level (FFL) Durumu

Tüm işlemlerimizi tamamladıktan sonra Windows Server 2016 işletim sistemli Server'ımızı Primary Domain Controller olarak tanımladık. Forest'ımızdaki en güncel Windows Server işletim sistemi, Windows Server 2016'dır, ancak fonksiyonlellik seviyesi olarak değil. Domain Controller Migration işlemi gerçekleştirmeden önce Windows Server 2012 R2 işletim sistemi üzerinde çalışan  Primary Domain Controller'ımızın Forest Functional Level'ı, kendisinin alabileceği en yünsek FFL değeri olarak  Windows Server 2012 R2, Domain Functional Level'ı ise, yine kendisinin alabileği en yüksek değer olan Windows Server 2012 R2 seviyesindeydi.

Bu Functional Level'lar; Migration öncesi eklediğimiz, Windows Server 2016 işletim sistemi üzerinde çalışan, Additional Domain Controller'a da aynı şekilde tamınlandı ve Migration sonrasında Primary Domain Controller'a Promote edilen Windows Server 2016 işletim sistemli yeni Primary Domain Controller'ımız da aynı Functional Level'lar ile Primay Domain Controller olarak çalışmaya devam etmektedir.

Buna göre, şimdi de Functional Level seviyesinin ne olacağını belirlememiz gerekiyor. Windows Server versiyonu olarak ortamımızdaki en yeni işletim sistemi Windows Server 2016 olsa da, Windows Server 2016'nın getirdiği fonksiyonelliklerden yararlanamamaktayız.



Migration işlemini tamamladıktan sonra yeni Primary Domain Controller Server'ım artık Windows Server 2016 işletim sistemli Server'ım olduğu ve ortamımda da hala Windows Server 2012 R2 Additional Domain Controller (Eki Primary Domain Controller) olduğu için, Forest Functional Level seviyem Windows Server 2012 R2 olarak kalmak zorunda ki zaten değiştirmenize de izin vermez.

Eğer Forest Functional Level'ı, şuan ortamımdaki en yüksek işletim sistemi versiyonu olan, Windows Server 2016'ya yükseltmek istersem, Forest ortamımda Windows Server 2012 R2 işletim sistemli DC'ler ile artık çalışma imakanım kalmayacaktır ve bu işletim sistemli Server'larımı ortamımdan kaldırmam gerekecektir.

Bu noktada iki seçeneğim var;

1- Windows Server 2016 ile gelen Windows Server gelişmiş özelliklerini Forest bazında kullanmak istiyorsak, Forest içindeki Windows Server 2012 R2 işletim sistemli tüm Server'larımı ortamımdan Demote ederek kaldırmamız ve Forest Functional Level'ı Windows Server 2016'ya Raise etmemiz gerekir.

Bu işlemi ancak ve ancak ortamınızda Windows Server 2012 R2 işletim sistemli Server barındırmak istemiyorsanız yapın.

2- Windows Server 2012 R2 işletim sistemli DC'lerimizi de Windows Server 2016 İşletim sistemli DC'lerimiz ile kullanmak istiyorsak ve Windows Server 2016 ile gelen Windows Server gelişmiş özelliklerinden faydalanmayacaksak Forest Functional Level, ortamımızdaki en düşük seviyeli Forest Functional Level'da bırakılır. Bu durumda benim senaryoma göre; Forest Functional Level'ı Windows Server 2012 R2 olarak bırakır, Forest ortamımda Windows Server 2012 R2 işletim sistemli DC'ler ile de çalışmaya devam edebiliriz.

Son olarak; 1. seçeneği hayata geçirmek ve Domain Functional Level ve Forest Functional Level'larınızı Windows Server 2016'ya yükseltmek istiyorsanız, ortamınızdaki Windows Server 2012 R2 işletim sistemli Domain Controller'larınızı ortamdan kaldırmak için, DC'lerdeki Active Directory'lerinizi kaldırma, yani Active Directory Demote etme işlemi uygulamanız gerekmektedir. Demote etme işlemi tamamlandıktan sonra da Functional Leval Yükseltme işlemini gerçekleştirebilirsiniz.

Domain Functional Level (DFL) ve Forest Functional Level (FFL) Seviyelerini Kontrol Etme

DFL ve FFL seviyelerini yükseltme işlemini, Active Directory Domains and Trusts bölümünden yapacağım;

1- Active Directory Domains and Trusts'ı açıyorum. Burada öncelikle Domain'imin firaboyan.com olduğunu görüyorum. Aynı anda da CMD ekranında nltest /dsgetdiag:firatboyan.com komutu ile Domain ortamımla ilgili özet bir bilgi çekiyorum. CMD ekranındaki bilgilere göre; DC: SRV001B.firaboyan.com Domain Controller, Migration işlemi yaptığım Windows Server 2016 işletim sistemli Domain Controller'dır.

Migration yapmadan önce DFL ve FFL seviyeleri Windows Server 2012 R2 idi. Domain Controller Migration işlemi tamamlandıktan sonra Active Directory Demote etme işlemi uygulayarak, ortamımdaki Windows Server 2012 R2 işletim sistemli tüm DC'leri kaldırdım.

Sonuç olarak; Forest ortamımda ve dolayısı ile de Domain ortamımda Windows Server 2012 R2 işletim sistemli DC olmadığı için, DFL ve FFL seviyelerini yükseltme işlemini gerçekleştirebilirim.



2- Active Directory Domains and Trusts üzerinde, firatboyan.com Domain üzerinde sağ tıklayarak, Properties seçeneğini seçiyorum.



3- Domain (firatboyan.com) Properties penceresi açıldığında, karşımıza çıkan pencerede DFL ve FFL seviyelerinin migration öncesi durumda yani Windows Server 2012 R2 olduğunu görüyorum.



4- DFL ve FFL seviyelerinin kontrolü, Active Directory Domains and Trusts haricinde, Powershell komutları ile de yapılabilmektedir. Bu komutlar;
4.1- Get-ADDomain –identit firatboyan.com
Domain Functional Level sonucunu döndürür.

4.2- Get-ADForest –identit firatboyan.com
Forest Functional Level sonucunu döndürür.



5- DFL ve FFL seviyelerinin diğer Powershell komutları ile kontrolü

5.1- Get-ADDomain | fl Name, DomainMode
Domain Functional Level bilgisi dahil olmak üzere Domain ile ilgili detaylı bilgi içeren sonuç döndürür. 



5.2-Get-ADForest | fl Name, ForestMode
Forest Functional Level bilgisi dahil olmak üzere Domain ile ilgili detaylı bilgi içeren sonuç döndürür.

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

DFL ve FFL Seviyelerini sontrol etme işlemini tamamladıktan sonra, sıra geldi DFL ve FFL seviyelerini Raise etme yani yükseltme işlemini yapmaya.

1- Öncelikle Domain Functional Level-DFL seviyesini yükselteceğim.

Bunun için, Active Directory Domains and Trusts'ı açıyorum. firatboyan.com Domain'i üzerinde sağ tıklayarak Raise Domain Functional Level... seçeneğini seçiyorum. 



2- Karşıma gelen Raise Domain Functional Level penceresinde Current Domain Functional Level seviyesinin Windows Server 2012 R2 olduğunu görüyorum. Alt kısımdaki select an available Domain Functional Level seçeneğinde, Windows Server 2016'yı seçip, Raise butonuna basıyorum.



2.1- Karşıma gelen pencerece "Yapılacak değişikliğin tüm Domain'i etkileyeceğini, yükseltme işlemi yaptıktan sonra işlemin geri alınamayabileceği" uyarısında bulunuyor. OK butonuna tıklayıp, yükseltme (Raise etme) işlemini onaylıyorum.



2.2- Yükseltme (Raise etme) işlemininin başarılı bir şekilde tamamlandığı bilgisini alıyorum. Karşıma çıkan pencerede ise, "Yeni Functional Level seviyesinin tüm Domain ortamında replike olacağı, replikasyon süresinin, toplojimizin yapısına bağlı olarak değişeciği" bilgisi iletilmektedir.



3- Domain (firatboyan.com) Properties penceresini tekrar açıyor, Domain Functional Level seviyesinin Windows Server 2016 olarak değiştiğini görüyorum.



4- İkinci aşamada da Forest Functional Level-FFL seviyesini yükselteceğim.

Bunun için yine Active Directory Domains and Trusts'ı açıyorum. firatboyan.com Domain'i üzerindeki Active Directory Domains and Trusts üzerinde sağ tıklayarak Raise Forest Functional Level... seçeneğini seçiyorum.



5- Karşıma gelen Raise Forest Functional Level penceresinde Current Forest Functional Level seviyesinin Windows Server 2012 R2 olduğunu görüyorum. Alt kısımdaki select an available Domain Functional Level seçeneğinde, Windows Server 2016'yı seçip, Raise butonuna basıyorum.



6.1- Karşıma gelen pencerece "Yapılacak değişikliğin tüm Forest'ı etkileyeceğini, yükseltme işlemini yaptıktan sonra işlemin geri alınamayabileceği" uyarısında bulunuyor. OK butonuna tıklayıp, yükseltme (Raise etme) işlemini onaylıyorum.



6.2- Yükseltme (Raise etme) işlemininin başarılı bir şekilde tamamlandığı bilgisini alıyorum. Karşıma çıkan pencerede ise, "Functinal level yükseltme işleminin başarılı bir şekilde gerçekleştiği, yeni Functional Level seviyesinin, Forest içindeki Active Directory Domain Controller'da replike olacağının ve bu replikasyon işlem süresinin de toplojimizin yapısına göre değişiklik göstereceği" bilgisi iletilmektedir.



7- Domain (firatboyan.com) Properties penceresini tekrar açıyor, Forest Functional Level seviyesinin Windows Server 2016 olarak değiştiğini görüyorum.

Yükseltme (Raise etme) sonrası DFL ve FFL Seviyelerini Kontrol Etme

7.1- Get-ADDomain –identit firatboyan.com
komutu ile Domain Functional Level seviyesini kontrol ediyor, DFL seviyesinin Windows Server 2016 olduğunu görüyorum.

7.2- Get-ADForest –identit firatboyan.com
komutu ile Domain Functional Level seviyesini kontrol ediyor, DFL seviyesinin Windows Server 2016 olduğunu görüyorum.



8- Get-ADDomain | fl Name, DomainMode
komutu ile yeni Domain Functional Level bilgisi dahil olmak üzere Domain ile ilgili detaylı bilgi içeren sonucunu görüntülüyorum.



9- Get-ADForest | fl Name, ForestMode
komutu ile yeni Domain Functional Level bilgisi dahil olmak üzere Domain ile ilgili detaylı bilgi içeren sonucunu görüntülüyorum.



Bu makalenin sonunda, Windows Server 2012 R2'den Windows Server 2016'ya yapılan migration sürecinin değerlendirmesini yapmış bulunmaktayız. Bu geçiş, yeni özellikler, gelişmiş güvenlik protokolleri ve artırılmış sistem performansı sunarak, IT altyapılarının modernleştirilmesi ve optimize edilmesi açısından büyük önem taşır.

Windows Server 2016, bir dizi yenilikçi özellikle birlikte geliyor. Özellikle, gelişmiş güvenlik mekanizmaları, sanallaştırma kapasiteleri ve bulut tabanlı entegrasyon seçenekleri, bu platformu, özellikle büyük ölçekli ve güvenlik odaklı işletmeler için cazip kılar. Bu özellikler, Windows Server 2012 R2'den gelen kullanıcılara, daha esnek, güvenli ve yönetilebilir bir IT ortamı sağlamaktadır.

Migration süreci boyunca, uygun planlama ve dikkatli uygulama, veri bütünlüğünü korumak ve sistem kesintilerini en aza indirgemek için kritik öneme sahiptir. Ayrıca, yeni sistemdeki güncellemeleri ve yapılandırmaları anlamak için gerekli eğitim ve adaptasyon süreçlerinin, bu süreçte büyük bir yer tuttuğunu gözlemledik.

Sonuç olarak, Windows Server 2012 R2'den Windows Server 2016'ya migration, sadece mevcut teknolojiyi güncellemekle kalmaz, aynı zamanda kuruluşların daha verimli ve güvenli bir şekilde çalışmasını sağlar. Bu migration, teknolojik ilerlemeleri benimseyerek, kuruluşların gelecekteki zorluklara daha hazırlıklı olmasına yardımcı olur. Kuruluşlar, bu teknolojik geçişle birlikte, yeni ve gelişmiş özelliklerden yararlanarak, IT altyapılarını daha rekabetçi hale getirebilirler. Okuyuculara tavsiyem, bu tür bir geçiş sürecini kapsamlı bir şekilde planlamaları ve sistematik bir şekilde uygulamalarıdır; böylece, yeni platformun sunmuş olduğu avantajlardan tam anlamıyla yararlanabilirler. Bu süreç, sadece bir güncelleme değil, aynı zamanda kuruluşunuz için stratejik bir yatırımdır.

Faydalı olması dileğiyle....