Office365 Offboarding Migration projeleri niçin yapılır? Office 365 in ölçeklendirme ve iş sürekliliği başta olmak üzere rakipsiz, zengin, ulaşılmaz bir hizmet ağı varken Onpremise ortamın da çalışan Exchange Server mimarisine neden geçiş yapılır…
Evet, teknik mühendislerin Office365 Offboarding Migration projeleri yaparken sormuş olduğu en temel sorulardan bir tanesidir. Cevabı her kuruluşa göre farklılık göstermekte ve kimi kuruluş KVKK, GDPR ve bağlı bulundukları yasal düzenlemeler için Office365 Offboarding Migration projelerini yapmakta. Kimi kuruluşlar ise maliyet avantajı oluşturmak için Office365 Offboarding Migration projelerini yapmaktadır.
Çok sayıda Office365 Offboarding Migration projeleri yapmış biri olarak şunu söylemeliyim, Office365 Offboarding proleri kolay ve kısa sürede tamamlanan projeler değildir. Süreci uzun ve stresi üst seviyede olan ve iç-içe geçmiş birden fazla projeyi barındıran prolerdir.
Nedeni basit. Office365 Offboarding Migration projesinde posta kutularını indirecek olduğumuz kullanıcılar Office 365 üzerinde zengin özelliklere ve kaynaklara sahip durumda ve çoğu kuruluşta bu kaynaklar bulunmamakta. Kullanıcılar, Office 365 üzerinde ki özellikleri ve limitleri sonuna kadar kullandıysa eğer Office365 Offboarding projeleri de hiç de kolay olmamakta.
Office 365 Mailbox Storage Limit
Move Request Migration Permanent Exception Mailbox Size makalesinde bu senaryo için örnekleri paylaşmıştık. Yukarıda ekran görüntüsünde Office 365 ‘in sağlamış olduğu ulaşılmaz limitler bulunmakta ve zaten unlimited olarak bizlere bilgi verilmekte. Fakat, Onpremise Exchange Organizasyonlarında bu limitler çok da mümkün değil.
Exchange 2019 database size limit
Yukarıda bir başka ekran görüntüsünü paylaşıyorum. Office 365 üzerinde bir kullanıcı için unlimited seviyesinde posta kutusu oluştururken Exchange Server üzerinde önerilen database boyutu 200 GB ile sınırlı. Daha fazlasını verebiliyormuyuz? Cevap, evet. Fakat Microsoft tarafından önerilen bir çözüm değildir ve 200 GB ‘in üzerinde oluşturulan Exchange veri tabanları için sağlıklı olacağının garantisi verilmemektedir.
Bildiğiniz gibi Exchange Veri tabanı ne kadar büyük olursa yedek alma süresi, problem anında geri dönüş süresi, bakım işlemlerinde yapılan veri tabanı bakım işlemleri uzun süre alacak ve belkide kesintiler yaşanacak.
Buraya kadar paylaşmış olduğum bilgiler sadece posta kutusu boyut özelinde bilgiler ve kumsaldaki kum tanesi kadar…
Office 365 platformu Bulut bilgiişlem iş modelleri arasında PaaS (Platform as a Service ) bulut iş modelinde yer almakta ve OneDrive, Multi Factor Authentication, Business Continuity Plan (BCP) ve disaster recovery plan (DRP) özellikleri başta olmak üzere rakipsiz özelliklerle sahip durumda.
Özet ile Office365 Offboarding Migration projelerinde teknik süreçlere odaklandığımız gibi kullanıcı deneyim ve alışkanlıklarını da dinlememiz ve proje adımlarına eklememiz gerekmektedir.
Mailbox Move Request Statistics
Yukarıda paylaşmış olduğum bir başka ekran görüntüsünde yapmış olduğumuz Office365 Offboarding Migration projesinde ki Mailbox Move Request Statistics görüntüsünü paylaşmaktayım.
Office365 Offboarding Migration işlemi yapılan kullanıcının posta kutusu 190 GB değerine ulaşmış ve Onpremise Exchange ortamı ise 200 GB limit ile sınırlı durumda.
Bu kullanıcıya posta kutunu küçültmemiz gerekiyor denilmesi, kullanıcı deneyim ve alışkanlığının değişmesi anlamına gelecek ve kullanıcı çalışma şekline etki edecek. İdari yönetim iyi bir plana sahip olmazsa teknik olarak problemsiz giden Office365 Offboarding projeleri, proje toplamın da başarısız olacak.
Office365 Offboarding Migration Kronoloji
KVKK, GDPR yada bir başka regülasyon yada maliyet nedeniyle Office365 Offboarding Migration yapmaya karar verdiniz. Makalenin bu bölümünden sonraki bölümler Office365 Offboarding Migration Kronoloji sini sizlere aktaracağız.
Bu sıralama her kuruluşun büyüklüğü, Office 365 üzerinde kullanılan özellikler ve mevcut Onpremise Exchange Organizasyon yapısına göre değişkenlik göstermektedir. Paylaşacak olduğumuz Kronoloji genel bilgilendirme amaçlı verilmiş olup kuruluş özelinde değişkenliklere gebe projelerdir.
Öncelikle Office 365 Hybrid mimarisinin kurulması gerekmekte. Onpremise içinde çalışan Exchange Organizasyonu ile Office 365 platformunun bir arada çalışması için Office 365 Hybrid mimarisinin kurulması ve Microsoft 365 Identity Modelleri ‘nde paylaşmış olduğumuz gibi kullanıcı eşitleme işlemlerinin yapılması gerekmekte.
Prerequisites for Office 365 hybrid deployment
Onpremise veri merkezi içinde Exchange organizasyonu kurulması, varsa eğer mevcut Exchange organizasyon mimarisinin Office 365 Hybird mimarisi için desteklenen sürüme yükseltilmesi Office365 Offboarding projesinde ki ilk gereksinimdir.
Örnek, Exchange organizasyonu içinde Exchange Server 2010 varsa bu organizasyon yapısı Ofice 365 Hybird mimarisi desteklenmez. Mevcut Exchange Organizasyonu içinde bulunan Exchange Server ‘ların en son Exchange Server Cumulative Update Paketleri ‘ni almış olması gerekmektedir. Bu adım içinde Exchange Server kapasite planı, bakım işlemleri / planı, BCP ve DRP, arşivleme, yedekleme ve koruma yöntemleride planlanmalıdır…
Office 365 Hybrid migration yapısında karar verilmesi gerekli olan önemli konulardan bir tanesi de Client Access yöntemi ve SMTP Trafiği.
Bu iki trafik yönlendirme işlemi kullanıcıların posta kutularına erişmesi ve e-posta trafiği için önemli proje adımlarıdır. T anında yada Office365 Offboarding adımları tamamlandıktan sonra da değiştirebilirsiniz. Bu değişiklik, yapacak olduğunuz projeye bağlı olarak değişecektir.
Office 365 Hybird mimarisi kurulduktan sonra Office365 Offboarding adımlarını yapabilir ve Office 365 üzerinde bulunan kullanıcıları yerel exchange Server üzerine taşıyabilirsiniz. Office 365 Hybird mimari kuruldultan sonra Office365 Onboarding adımları da yapılabilir ve yerel exchange üzerinde bulunan kullanıcılar Office 365 platformuna taşına bilir. Office365 Onboarding işlemleri de bir başka makale konumuz olsun.
Exchange Online Mailbox Guid
Onpremise Exchange organizasyon gereksinimleri ve çevre birimleri tamamlandıktan sonra Onpremise Active Directory içinde bulunan kullanıcılar ile Exchange Online Directory (Office 365 Kimlik Dizini) arasında ki GUID eşitlemesinin yapılması gerekmekte.
Office365 Offboarding projelerinde yada Office365 Onboarding projelerinde yapmış olduğumuz Office 365 Hybrid işlemi aslında eski zaman da yapmış olduğumuz Active Directory Migration (Upgrade Değil) ve Exchange Migration (bu da upgrade değil) projelerinde ki Federasyon kurulum işlemleri ve kullanıcı delegasyon işlemlerinin Office 365 Hybrid mimarisinde yapılma işlemleridir.
Kullanıcı, gerçek hayatda tek bir kullanıcı olsa bile Office 365 Hybrid yapısında durum bu şekilde değildir.
Yukarıda ki ekran görüntüsün de paylaşmış olduğumuz John Smith kullanıcısı üzerinden örnekleyelim. John Smith kullanıcısı şirketimiz için tek bir kullanıcısı olsa bile Office 365 Hybrid projelerinde iki tane kullanıcıya sahiptir. Bu kullanıcılar, Onpremise Active Directory ve Exchange Online Directory üzerinde barınmaktadır. John Smith ise şirketimiz içinde tek bir kullanıcı olduğu için tek bir posta kutusu vardır ve Mailbox GUID eşitleme işlemlerinde bu iki kullanıcı için tek bir posta kutusuna erişim izni vermekteyiz.
Office 365 User Sync Status
Exchange Online üzerinde barınan John Smith kullanıcısı Directory Synced kullanıcısı olmak zorundadır. Office 365 Portal üzerinde kullanıcı özelliklerinde kullanıcı özelinde bu bilgiye sahip olabilirsiniz. Office 365 Hybrid Migration Target user already has a primary mailbox konu başlığı ile paylaşmış olduğumuz makalede ise bu bilgileri detaylı olarak sizlere aktarmıştık.
Exchange Online Mailbox GUID
Mailbox Guid Eşitleme işlemleri problemlere gebe işlemdir. Mailbox Guid Eşitleme işlemlerinin sağlıklı olması için yerel veri merkezi içinde çalışmakta ve Office 365 Hybird mimarisine kullanıcı eşitleme işlemini yapan AD Connected sunucularının ve bunları besleyen etki alanı sunucularının sağlıklı olması gerekmektedir. O365 Hybrid Deployment Delegated Mailbox Permissions ve Cannot find a recipient that has mailbox GUID konu başlığı ile paylaşmış olduğumuz makalelerimizde bu problemlere örnekler verdik.
Örnek verdiğimiz John Smith kullanıcısı üzerinden adımlarımıza devam edelim. John Smith kullanıcısı Office 365 üzerinde posta kutusu var ve yerel veri merkezi içinde bulunan etki alanı içinde kullanıcısı var. Kullanıcımız Office 365 Hybrid mimarisinde Directory Synced kullanıcısı. Kullanıcımızın Office 365 üzerinde bulunan posta kutusunun Exchange Guid bilgisini öğrendik ve eğer kullanıcımızın Archive posta kutusu varsa ArchiveGuid paremetresi ile bu bilgileri de öğrendik.
Yukarıda paylaşmış olduğum komut ile bu bilgileri öğrenebilirsiniz.
Office 365 Remote Mailbox
Öğrenmiş olduğumuz ExchangeGUID ve ArchiveGuid bilgilerini yerel veri merkezi içinde çalışan Exchange Server üzerine öğretmemiz gerekmekte. bu işlemi ise Remote Mailbox işlemi ile yapmaktayız. Bu işlemi neden yaptığımız Office 365 Hybrid Migration Target user already has a primary mailbox makalesinde paylaşmıştık ve önemli bir adım olduğu için dikkatli bir şekilde incelemenizi önereceğim.
Yukarıda paylaşmış olduğum komut ile Remote Mailbox oluşturabilirsiniz.
Migrate from exchange online
Makalenin bu aşamasına geldiyseniz eğer ön gereksinimleri tamamlamış, güçlü ve rakipsiz Office 365 mimarisinden Exchange Server organizasyonuna Office365 Offboarding işlemine kesin olarak karar verdiğinizi düşünebiliriz.
Migrate from exchange online
Office 365 Exchange admin center üzerinde Recipients bölümüne ulaşıyoruz ve bu alanda yer alan Migration bölümüne geçiş yapıyoruz.. Bu panel üzerinde mevcut Office365 Offboarding ve Office365 Onboarding işlemi yapılan kullanıcıların taşıma durumlarını görebilir ve yeni taşımalar için new migration batch yazabilirsiniz.
new migration batch
Yeni açılan panel New migration batch alanı ve bu alanda ön hazırlık işlemlerini yapmış olduğunuz kullanıcıyı Office365 Offboarding Migration işlemi için seçiyoruz.
Confirm the migration endpoint
Office 365 Hybird kurulum aşamasında belirlemiş olduğumuz Remote MRS Proxy Server erişim adresinin public internet üzerinden erişilebilir olduğundan emin olmalıyız. Office365 Offboarding Migration işlemi Remote MRS Proxy Server adresi üzerinden gerçekleştirilecek.
Office365 Offboarding Migration Move Configuration
new migration batch içinde Office365 Offboarding Migration işlemi yapılacak olan kullanıcının Exchange Server organizasyonu içinde hangi Exchange Database üzerine taşınacağına Eğer kullanıcının varsa Archive Database ‘i bu verilerinde hangi Exchange Database üzerine taşınacağına yada taşınmayacağına karar vermekteyiz.
Bu işlemler her organizasyon yapısı ve beklentisine bağlı olarak değişmektedir ve tek düzey kuralı bulunmamaktadır. Decide on a migration path makalesini incelemenizi önermekteyim.
Migrate from Office365 Offboarding
Artık son adımdayız ve hazırlamış olduğumuz Office365 Offboarding Migration işleminin görevini başlatabiliriz yada belirlediğimiz zaman içinde başlama emrini verebiliriz. Aynı şekilde ne zaman ve nasıl biteceğini de belirleyebiliriz.
Bu adımın da yazılmış tek düzey bir kuralı bulunmamakta ve her kuruluş ve organizasyon yapısı ve hatta gerçekleştirilen Office365 Offboarding Migration işlemi kullanıcı özelinde yapıldığı için kullanıcı özelinde de değişkenlik göstermektedir.
Bu bölüm ile birlikte Office365 Offboarding Migration işlemi bu kullanıcı özelinde tamamlanmakta fakat görevi tamamlamadan önce paylaşmış olduğumuz Exchange Mailbox Move Request Preferred Option to Complete the Batch makalesini incelemenizi önermekteyiz.
