Category: AZURE

Office365 – Forest Migration – Part1

No Comments

 

Merhaba ,

Bu makalede office365 ile entegre olan onpremise de bulunan active directory yapısının yeni forest’a taşınma işlemleri ve dikkat edilmesi noktalar anlatılacaktır.  Microsoft platformu ile çalışan, active directory, exchange ve benzeri ürünlerin kurulumunu ve yönetimini yapan herkes mutlaka migration durumları ile karşılaştı. Şirket evlilikleri,kaynak paylaşımları,ölçeklendirmeler,iyileştirmeler bunlara birkaç örnek. Bildiğiniz gibi birden fazla migration türü var, Cross-forest, Interforest ve Intraforest migration şeklinde sıralayabiliriz. Bulut teknolojilerinin yaygınlaşması ile birlikte artık şirketler yavaş yavaş lokalde kullandığı birçok servisi cloud tarafında  SaaS,PaaS ve Iaas olarak kullanmaya başladı. Bu servislere gün geçtikçe yenisi eklenerek XaaS(anything as a service) , BaaS(Backup as a Service) ve DraaS(Disaster Recovery as a Service) şeklinde ilerlemeye ve bilişim dünyasında hızla yer almaya devam ediyor. Vendor lar ve özel şirketler dahil olmak üzere kendi bulut sistemlerini oluşturarak (private cloud  değil 🙂 ) tam otomatize bulut çözümleri üreterek yönetilen hizmetler ile birlikte servis sağlamaya başladı. Geleneksel mimarilerin değiştiğini ve bu değişimleri karşılamak gerektiğini software-defined teknolojilerle farketmeye başladık, Üreticilerin nerdeyse hepsi kendi ürünlerini piyasaya sürdü bile. Nsx,Viptela,Vsan,Proxmox ceph karşılaştığımız,projeleri içerisinde yer aldığımız ve ya projelendirdiğimiz ürünler olmuştur. Software-defined geleneksel yapıdan modern yapılara geçiş süreci fazlası ile göze çarpıyor. Şuan da yaygın olarak kullanılan office365 ile birlikte hybrid ve ya cutover geçişlerde karşılaşılan problemlere ve adımlarına olabildiğince değinmeye çalışacağım.  Bu makalede aslında ne kadar azure ad connect ve exchange online servislerinin yeni active directory ortamına entegrasyonundan bahsedecek olsakda etki alanı değişiklikleri lokalde çalışan tüm bağımlı servisleri ve platformları etkileyen riskli ve ciddi analizler gerektiren süreçlerdir. Bu geçişler yapıların büyüklüğüne göre günleri ve ayları bulabilir. Migration türlerinden bahsetmişken kısaca migration türlerini hatırlayalım.

arch

Interforest Migration

Bu migration türünde amaç forest içerisinde organizasyonları bir arada tutarak tüm organizasyonların birbirinin kaynaklarına erişmesini sağlamaktır. Bu demek oluyor ki kaynak domain ortamdan kaldırılmıyor.  Eski ortamınıza her daim geri dönebilme şansınız var.

Intraforest Migration

Bu migration türünde amaç forest yapısını ve yönetimi konsolide ederek tek etkialanı üzerinde ilerlemek, Bir nevi kaynak etkialanında bulunan objeler hedef etkialanına taşınacak ve kaynak domaine bir daha erişim sağlanmayacaktır.

Migration consideration Interforest restructure Intraforest restructure
Object preservation Objects are cloned rather than migrated. The original object remains in the source location to maintain access to resources for users. User and group objects are migrated and no longer exist in the source location. Computer and managed service account objects copied and the original accounts remain enabled in the source domain.
Security identifier (SID) history maintenance Maintaining SID history is optional. SID history is required for user, group, and computer accounts, but not managed service accounts.
Password retention Password retention is optional. Passwords are always retained.
Local profile migration You must use tools such as ADMT to migrate local profiles. Local profiles are migrated automatically because the user’s globally unique identifier (GUID) is preserved.
Closed sets You do not have to migrate accounts in closed sets. For more information, see Background Information for Restructuring Active Directory Domains Within a Forest (http://go.microsoft.com/fwlink/?LinkId=122123). You must migrate accounts in closed sets.

Cross-Forest Migration

Bu migration türü exchange ortamında bulunan mailbox’ların diğer forest ta bulunan exchange ortamına taşınmasını gerektiren durumlarda olur ve yukarıda bahsetmiş olduğumuz intraforest ve ya interforest yapısını gerektirir.

crossforest

Benim kurgulayacağım senaryoda olddomain.local( kaynak domain olarak bahsedilecek) den newdomain.local(hedef domain olarak bahsedilecek) e hesaplar taşınıp Office365 te bulunan hesaplara tekrar bağlanıp hedef domaindeki yerel hesapları kullanarak MFA(Multi-factor Authentication) ile office365 servislerini kullanmaları amaçlanmıştır.

 

Test Ortamında;

Office365 tenant – canbolat-tr.com

DC – dc01.olddomain.local

Azure ad Connect – azuread01.olddomain.local

Client- client01.oldomain.local

DC- dc02.newdomain.local

Azure Ad Connect – azuread02.newdomain.local

Client- client02.newdomain.local

Migration tool – Questtool.newdomain.local

Migration tool olarak Microsoft ADMT de kullanabilirsiniz. Ben migration geçişlerinde Quest’i tercih ediyorum. Quest te daha advanced bir ürün olması birlikte objelerin geçişleri ve sürecin yönetilmesi konusunda daha esnek çözümler sağlıyor, Makalenin ilerleyen serilerinde sid,objectguid,immutable id gibi kavramlardan sıkça bahsdeceğiz.