Exchange 2010'dan Office 365'e geçiş
İnternette Exchange 2016'nın Office 365'e bağlandığı hibrit bir ortamın nasıl oluşturulacağıyla ilgili pek çok makale var. Bu sorun değil, ancak Exchange 2016'yı çalıştırırken en sevdiğiniz şey hiçbir zaman Office 365'e geçmeyeceksiniz yakında sanırım. Exchange 2010 kullanıyorsanız muhtemelen (yakında) Office 365'e geçeceksiniz, ancak Exchange 2010'dan Office 365'e geçişle ilgili çok fazla makale yok. Ayrıca mevcut makalelerin birçoğu doğru yaklaşıma sahip değil. Korkarım ki bu sizin (müşterinin) sistem entegratörünüze çok fazla para ödemek zorunda kalmanızla sonuçlanacaktır.
Bu makalede, karma bir senaryoda Exchange 2010'dan Office 365'e geçişte önerilen yaklaşımı özetlemeye çalışacağım. Senkronizasyon amacıyla Azure AD Connect ile. Cliffhanger: Exchange 2016'yı mevcut Exchange 2010 ortamına kurmayacağım ?
Mevcut Exchange ortamı
Kuruluşumuzun adı Inframan'dır ve 5 yıldır çok fazla sorun yaşamadan çalıştırdıkları kendi şirket içi Exchange 2010 ortamına sahiptirler. Outlook 2010 ve üstünü kullanan dahili Outlook istemcileri ve Outlook Anywhere'i kullanan harici istemciler vardır. Posta Kutularına bağlanmak için ActiveSync kullanan mobil istemciler de vardır. Elbette Outlook Web Access var ama POP3 ve IMAP4 kullanılmıyor.
Şekil 1. Inframan Exchange 2010 ortamına genel bakış.
Dahili ağda, SMTP mesajlarını Exchange 2010 sunucusu üzerinden aktaran uygulamalar ve çok işlevli cihazlar da vardır. Bu mesajlar Exchange 2010 sunucusundaki alıcılara ve aynı zamanda Exchange 2010 sunucusundaki özel bir Alma Bağlayıcısı aracılığıyla harici alıcılara da gönderilir.
Eğlenceli kısım burada başlıyor. NetBIOS etki alanı adı Inframan'dır, ancak Active Directory'nin (tek orman, tek etki alanı) FQDN'si Inframan.local'dır. Bu nedenle, kullanıcılar Inframan\J.Brown kullanarak oturum açar; Inframan kuruluşu hiçbir zaman UPN'yi kullanmamıştır ve bu, J.Brown@Inframan.local olan varsayılan değer olarak ayarlanmıştır.
Mesaj hijyeni için, SpamHaus'tan Gerçek Zamanlı Engelleme Listesi (RBL) kullanılarak bir Exchange 2010 Edge Transport sunucusu kullanılıyor, Alıcı Filtreleme yapılandırılıyor ve Edge Transport Server'ın İçerik Filtreleme modülünde bazı özel kelimeler kullanılıyor. Ve evet, bu yıllardır işe yarıyor.
Office 365 ve Hibrit Exchange'e hazırlanın
Inframan'ın yakl. 500 Posta Kutusu ve Office 365'e geçişin 6 aydan fazla süreceği tahmin ediliyor. Bu 6 ay boyunca bir arada bulunmaya ihtiyaç duyulacak ve kullanıcı hesapları şirket içi Active Directory'de tutulacak ve Exchange 2010 hibrit senaryosu uygulanacaktır.
Not. Kullanıcı adları ve şifreler Office 365 ile senkronize edilecek olup şimdilik bu kadarı yeterli. ADFS (Active Directory Federasyon Hizmetleri) aracılığıyla Tek Oturum Açma şu anda Inframan ortamında uygulanmamaktadır.
Dizin Senkronizasyonu
Azure AD Connect, kullanıcı hesaplarını ve parolalarını şirket içi Active Directory'den Office 365 ve Exchange Online'ın temel dizini olan Azure Active Directory'ye eşitlemek için kullanılacaktır.
IdFix'i çalıştırın
Şirket içi Active Directory'nizin Azure AD senkronizasyonuna hazır olduğundan emin olmak için Microsoft, Azure Active Directory ile soruna neden olabilecek tutarsızlıklar veya sorunlar açısından Active Directory'nizi analiz eden IdFix adında bir araca sahiptir. Bu açıdan iyi bilinenler, yönlendirilemeyen bir UPN son eki, yinelenen öğeler veya yönlendirilemeyen e-posta adresleridir. IdFix DirSync Hata Düzeltme Araçları resmi adıdır ve buradan indirilebilir: https://www.microsoft.com/en-us/download/details.aspx?id=36832
IdFix aracını çalıştırdığınızda, konsolda Active Directory'nizdeki sorunların bir listesi gösterilir, ancak bunu örneğin Microsoft Excel'de analiz için bir CSV dosyasına da aktarabilirsiniz.
Şekil 2. Active Directory'de IdFix aracı tarafından bulunan sorunlar
Şekil 3. CSV dosyasına aktarılan ve Microsoft Excel'e aktarılan aynı sorunlar.
Bu ortamda düzeltilmesi gereken bazı garip (aksanlı) karakterler vardır, ancak aynı zamanda UPN yanlış yapılandırılmıştır ve .local TLD'ye sahip bazı e-posta adresleri mevcuttur.
Azure AD senkronizasyonunun ön koşulu, Kullanıcı Asıl Adının veya UPN'nin, UPN son eki olarak yönlendirilebilir bir etki alanı adına sahip olması gerektiğidir. Bu nedenle Inframan.local kullanılamaz ve Inframan.nl alan adının kullanılması gerekir. Kullanıcının birincil SMTP adresi ve UPN'si için aynı adın kullanılması önemle tavsiye edilir. Bu senaryoda kullanıcının E-posta adresi J.Brown@inframan.nl gibi olacaktır ve karşılık gelen UPN de J.Brown@inframan.nl olacaktır.
Şekil 4. Active Directory Etki Alanları ve Güvenlerini kullanarak yönlendirilebilir bir UPN Son Eki ekleme
Eklendikten sonra, kullanıcılar için UPN sonekini hızlı bir şekilde değiştirmek için Active Directory Kullanıcıları ve Bilgisayarları'nı kullanabilirsiniz. Doğru Kuruluş Birimi'ne gidin, tüm kullanıcıları seçin ve mülkleri seçin.
Hesap sekmesinde UPN son eki onay kutusunu işaretleyin ve uygun UPN son ekini seçmek için açılır kutuyu kullanın.
Şekil 5. Kullanıcılar için doğru UPN Son Eki'ni seçin
Ortamımızdaki bir diğer sorun da tüm kullanıcıların @inframan.local SMTP adresine sahip olmasıydı. Bunun nedeni, hâlâ @inframan.local girişini tutan varsayılan E-posta Adresi Politikası'dır; dolayısıyla oluşturulan tüm kullanıcılar yine de @inframan.local e-posta adresini almıştır.
Bu ek E-posta adreslerini kaldırmanın en kolay yolu basit bir PowerShell betiği kullanmaktır:
$Mailboxes = Get-Mailbox -ResultSize Unlimited -OrganizationalUnit Accounts
ForEach($Mailbox in $Mailboxes) {
$Mailbox.EmailAddresses |
?{$_.AddressString -like '*@inframan.local'} |
%{Set-Mailbox $Mailbox -EmailAddresses @{remove=$_}
}
}Bu, OU=Hesaplar Organizasyon Birimi'ndeki tüm Posta Kutularını içeren bir dizi oluşturacak ve @inframan.local son ekini içeren tüm E-posta adreslerini kaldıracaktır.
IdFix aracını tekrar çalıştırdığınızda yalnızca iki sorun daha kalıyor; iki Dağıtım Grubu hâlâ bir @inframan.local e-posta adresi içeriyor ancak bu, Exchange Yönetim Konsolu kullanılarak manuel olarak çözülebilir.
Şekil 6. Inframan ortamımızda yalnızca iki sorun daha var
Bu son iki sorun çözüldükten sonra şirket içi Active Directory'mizin Azure Active Directory ile bağlantı kurması uygundur.
Azure AD Connect'i yükleyin ve yapılandırın
Microsoft Azure AD Connect, şirket içi Active Directory'nizi Office 365'in temel dizini olan Azure AD'ye bağlamak ve senkronize etmek için kullanılan araçtır.
Azure AD Connect, hem şirket içi Active Directory hem de Azure Active Directory'deki hizmet hesaplarını kullanır. Şirket içi Active Directory'de hizmet hesaplarının Enterprise Admins güvenlik grubunun üyesi olması gerekir; Azure Active Directory'de hizmet hesaplarının Genel Yönetici hesabı olması gerekir.
Not. Hizmet hesabına Office 365 lisansı atamanıza gerek yoktur.
Azure AD connect'i özel bir sunucuya (benim tercihim ve önerim) kurabilirsiniz ancak bir Etki Alanı Denetleyicisine de kurulabilir. Bunun dezavantajı (sanırım), farklı konfigürasyonlara sahip Etki Alanı Denetleyicileri ile sonuçlanmanızdır, bu da kaçınmak istediğim bir şeydir.
Yeni bir Windows 2012 R2 sunucusu yükleyin, .NET Framework 4.5'i yükleyin ve mevcut tüm yamaları yükleyin. Azure AD Connect yazılımını Microsoft web sitesinden (https://www.microsoft.com/en-us/download/details.aspx?id=47594) indirdikten sonra kuruluma başlayabilirsiniz.
Azure AD Connect'i yükleyip yapılandırmadan önce Office 365 kiracınızın Dizin Eşitlemesi için etkinleştirilmesi gerekir. Kiracı yöneticisi kimlik bilgilerini kullanarak kiracınızda oturum açın ve Yönetici kutucuğuna tıklayın.
Soldaki gezinme menüsünde kullanıcı simgesine tıklayın ve Diğer açılır menüsünden Dizin Senkronizasyonu'nu seçin.
Şekil 7. Açılır menüden Dizin senkronizasyonunu seçin
Dizin senkronizasyon sihirbazı başlatılır ve sihirbazı takip edebilirsiniz. Dağıtım Hazırlığı Denetimi sırasında Azure AD Connect kurulum uygulamasını başlatabilirsiniz; sihirbaz, Azure AD Connect kurulumunda size yol gösterecektir.
Şekil 8. Azure Active Directory'ye bağlanmak için bir hizmet hesabı kullanın.
İpucu: Azure Active Directory'deki hizmet hesabının parolasının süresi, yönetici olarak size bildirimde bulunulmaksızın her 90 günde bir dolacaktır. Parolayı hiçbir zaman sona ermeyecek şekilde ayarlamak için Azure Active Directory PowerShell'deki Set-MsolUser -UserPrincipalName
Şekil 9. inframan.nl alanı doğrulandı, inframan.local alanı kullanılmıyor (ve eklenemiyor).
Şekil 10. Exchange Karma Dağıtımı onay kutusunu işaretlediğinizden emin olun.
Azure AD Connect yüklendiğinde Dizin Eşitleme sihirbazına devam edebilirsiniz. Her şey ayarlandığında Son'u tıklayın.
Şekil 11. Dağıtım Hazırlığı Aracını kapatmak için Son'a tıklayın.
Azure AD Connect otomatik olarak başlayacak ve tam bir senkronizasyon gerçekleştirecektir. Office 365 Yönetim Merkezi'ni kontrol ettiğinizde şirket içi Active Directory'nizdeki kullanıcıların göründüğünü göreceksiniz. Lütfen bu noktada lisanssız olduklarını unutmayın.
Şekil 12. Şirket içi Active Directory'deki kullanıcılar Office 365 Yönetim Merkezi'nde görünecektir.
Şirket içi Active Directory'den senkronize edilen tüm kullanıcılara lisans atamak için Office 365 Yönetim Merkezi'ni kullanabilirsiniz. Tüm lisanssız kullanıcıları filtreleyin, lisansa ihtiyaç duyan tüm kullanıcıları seçin ve uygun lisansı atamak için eylemler bölmesinde Ürün Lisanslarını Düzenle'yi seçin.
Bu noktada kullanıcılarınız Office 365 portalında oturum açabilir ve mevcut tüm hizmetleri inceleyebilir. Office 365'te Posta Kutusu var mı? Hayır henüz değil. Şirket içi Exchange 2010 ortamındaki tüm Posta Kutularının, Office 365'te Posta Etkinleştirilmiş bir kullanıcısı vardır. Exchange Yönetim Merkezi'nde oturum açarken bunu kolayca kontrol edebilirsiniz:
Şekil 13. Şirket içi Posta Kutuları, Office 365'te Posta Etkinleştirilmiş kullanıcılar olarak görünür
Bir sonraki adım, Exchange 2010 ve Office 365 ile hibrit yapılandırmayı uygulamaktır. Bu konuyu bir sonraki blog yazımda tartışacağım.