Exchange Server’dan Microsoft 365’e Geçiş Rehberi

Yazar:komut.io ekibi Exchange Server Kurulum ve Yönetimi
0 Yorum

Birkaç yıl önce 800 kullanıcılı bir şirkette Exchange 2013’ten Microsoft 365’e geçiş projesi yürüttüm. O süreçte yaşadıklarım, öğrendiklerim ve bir daha yapmayacaklarım bu yazının temelini oluşturuyor. Geçiş dediğinizde kulağa basit geliyor: “Mailboxları taşı, DNS’i güncelle, bitti.” Gerçek hayatta öyle değil. Üretim ortamında bir şeyler ters gittiğinde, paniği bastırıp sistematik düşünebilmek için bu süreci çok iyi anlamış olmak gerekiyor.

Geçiş Öncesi Ortam Değerlendirmesi

Herhangi bir şey yapmadan önce mevcut Exchange ortamınızı iyi tanımanız gerekiyor. Hangi Exchange sürümünü çalıştırdığınız, kaç mailbox’ınız olduğu, toplam veri boyutu, public folder kullanımı, üçüncü parti entegrasyonlar… Bunların hepsini bilmeden geçişe başlamak, karanlıkta yürümek gibi.

Exchange ortamını analiz etmek için şu PowerShell komutlarını kullanıyorum:

# Exchange sunucu bilgilerini al
Get-ExchangeServer | Select-Object Name, ServerRole, AdminDisplayVersion

# Tüm mailbox istatistiklerini al
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | 
Select-Object DisplayName, TotalItemSize, ItemCount | 
Sort-Object TotalItemSize -Descending | 
Export-Csv -Path "C:Gecismailbox_rapor.csv" -NoTypeInformation

# Toplam veri boyutunu hesapla
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | 
Measure-Object -Property TotalItemSize -Sum

Public folder kullanımı varsa bunları ayrıca raporlamanız kritik. Şirketlerin büyük çoğunluğu public folder kullandığını bile bilmiyor, geçiş sırasında fark ediyor.

# Public folder yapısını ve boyutunu raporla
Get-PublicFolder -Recurse | Get-PublicFolderStatistics | 
Select-Object Name, TotalItemSize, ItemCount | 
Export-Csv -Path "C:Gecispublic_folder_rapor.csv" -NoTypeInformation

Bunların yanında connector yapılandırmalarını, retention policy’leri, transport rule’ları ve mail flow ayarlarını da belgelemeniz gerekiyor. Çünkü bunların hepsini Microsoft 365 tarafında yeniden yapılandıracaksınız.

Geçiş Türlerini Anlamak

Microsoft 365 geçişinde dört temel yöntem var ve hangisini seçeceğiniz büyük ölçüde mevcut ortamınıza ve kullanıcı sayısına bağlı.

Cutover Migration (Kesintili Geçiş): 150 kullanıcının altındaki ortamlar için uygun. Tüm mailbox’ları tek seferde taşırsınız. Basit ama geçiş süresi boyunca kullanıcılar biraz zorlanabilir.

Staged Migration (Aşamalı Geçiş): Exchange 2003 veya 2007 ortamlarından yapılan geçişlerde kullanılır. Gruplar halinde taşıma yapılır.

Hybrid Migration (Hibrit Geçiş): 150 kullanıcının üzerindeki kurumsal ortamlar için ideal. Exchange on-premises ile Exchange Online aynı anda çalışır, kullanıcılar kademeli olarak buluta taşınır. Ben neredeyse her zaman bu yöntemi tercih ederim.

IMAP Migration: Exchange dışı sistemlerden geçiş için. Sadece mail içeriğini taşır, takvim ve kişileri taşımaz.

Hibrit Yapılandırma Adımları

Kurumsal geçişlerde hibrit yapı kurmak en sağlıklı yol. Bunun için önce Azure AD Connect‘i kurmanız gerekiyor. Active Directory’deki kullanıcıları Azure AD’ye senkronize eden bu araç olmadan hibrit yapı çalışmıyor.

Azure AD Connect kurulumundan önce şu kontrolleri yapın:

# Domain hazırlık kontrolü
$domain = "sirketiniz.com"
$result = Resolve-DnsName -Name $domain -Type MX
Write-Host "MX Kayitlari:" -ForegroundColor Green
$result | ForEach-Object { Write-Host $_.NameExchange }

# UPN suffix kontrolü - kullanıcıların UPN'lerinin doğru olduğunu doğrula
Get-ADUser -Filter * -Properties UserPrincipalName | 
Where-Object {$_.UserPrincipalName -notlike "*@sirketiniz.com"} | 
Select-Object Name, UserPrincipalName | 
Export-Csv "C:Gecisupn_sorunlu_kullanicilar.csv" -NoTypeInformation

UPN sorunları geçişlerde en çok baş ağrıtan konulardan biri. Kullanıcının AD’deki UPN’i ile Microsoft 365’teki hesap eşleşmezse mailbox taşıma işlemi hata veriyor.

Exchange Hibrit Yapılandırma Sihirbazı

Microsoft’un sağladığı Hybrid Configuration Wizard (HCW) araçını indirip çalıştırıyorsunuz. Bu araç Exchange sunucunuz ile Microsoft 365 kiracınız arasındaki güven ilişkisini, Autodiscover yapılandırmasını ve mail flow ayarlarını otomatik olarak yapıyor.

HCW çalıştırmadan önce bazı ön koşullar var:

  • Exchange sunucusunda .NET Framework 4.8 veya üzeri yüklü olmalı
  • Exchange Certificate geçerli ve trusted olmalı
  • Port 443’ün hem gelen hem giden trafiğe açık olması gerekiyor
  • Firewall’da EWS (Exchange Web Services) endpoint’ine erişim sağlanmalı
# Exchange sertifika durumunu kontrol et
Get-ExchangeCertificate | Select-Object Subject, NotAfter, Services, Thumbprint | 
Format-List

# Autodiscover servisinin çalıştığını doğrula
Test-OutlookWebServices -Identity [email protected]

# Hibrit mail flow için Send Connector doğrulama
Get-SendConnector | Select-Object Name, AddressSpaces, SmartHosts | Format-List

DNS ve Mail Flow Yönetimi

Geçiş sürecinin en kritik anı DNS değişiklikleridir. Yanlış yapılırsa mail kaybı yaşanır, sonrası çok çirkin olur. Ben şöyle bir strateji izliyorum:

Önce Microsoft 365 tarafında tüm yapılandırmaları tamamlıyorum. Transport rule’ları, connector’ları, anti-spam politikalarını kuruyorum. Sonra MX kaydını değiştiriyorum. MX kaydının TTL’ini değişiklikten 24-48 saat önce düşürüyorum, bu sayede yayılma süresi kısalıyor.

# Mevcut MX kayıtlarını ve TTL değerlerini kontrol et
nslookup -type=MX sirketiniz.com 8.8.8.8

# TTL değerini düşürmeden önce mevcut değeri kaydet
Resolve-DnsName -Name "sirketiniz.com" -Type MX -Server 8.8.8.8 | 
Select-Object Name, TTL, NameExchange | Format-Table

MX kaydını değiştirdikten sonra her iki tarafın da mail aldığından emin olmak için test yapıyorum. Bu süreçte Exchange sunucusu hâlâ çalışıyor olduğu için taşınmamış kullanıcılara gelen mailler on-premises’e yönlendiriliyor. Taşınan kullanıcıların mailleri ise Microsoft 365 üzerinden akıyor.

Exchange Online Protection Yapılandırması

Microsoft 365’e geçtiğinizde mailleri artık Exchange Online Protection (EOP) filtreden geçiyor. Eski ortamda üçüncü parti anti-spam kullandıysanız, politikalarınızı EOP’a aktarmanız gerekiyor.

# Exchange Online PowerShell'e bağlan
Connect-ExchangeOnline -UserPrincipalName [email protected]

# Mevcut anti-spam politikalarını listele
Get-HostedContentFilterPolicy | Select-Object Name, SpamAction, HighConfidenceSpamAction

# Yeni anti-spam politikası oluştur
New-HostedContentFilterPolicy -Name "Sirket_AntiSpam" `
  -SpamAction MoveToJmf `
  -HighConfidenceSpamAction Quarantine `
  -BulkThreshold 6 `
  -MarkAsSpamBulkMail On

Mailbox Taşıma İşlemleri

Hibrit yapıyı kurduktan sonra mailbox’ları taşımaya başlayabilirsiniz. Ben her zaman bir pilot grupla başlıyorum. IT ekibinden birkaç kişi, sistemi iyi bilen kullanıcılar… Bunlarla başlayıp sorunları erken tespit ediyorsunuz.

# Exchange Online PowerShell'den migration batch oluştur
New-MigrationBatch -Name "Pilot_Grup_Tasinma" `
  -SourceEndpoint "HybridMigrationEndpoint" `
  -CSVData ([System.IO.File]::ReadAllBytes("C:Gecispilot_kullanicilar.csv")) `
  -AutoStart `
  -NotificationEmails "[email protected]"

# Migration batch durumunu izle
Get-MigrationBatch -Identity "Pilot_Grup_Tasinma" | 
Select-Object Status, TotalCount, SyncedCount, FailedCount

# Detaylı kullanıcı bazlı durum
Get-MigrationUser -BatchId "Pilot_Grup_Tasinma" | 
Select-Object Identity, Status, PercentComplete, Error | 
Format-Table -AutoSize

Pilot CSV dosyasının formatı şöyle olmalı:

# pilot_kullanicilar.csv formatı (PowerShell ile oluşturma)
$kullanicilar = @(
  [PSCustomObject]@{EmailAddress = "[email protected]"},
  [PSCustomObject]@{EmailAddress = "[email protected]"},
  [PSCustomObject]@{EmailAddress = "[email protected]"}
)
$kullanicilar | Export-Csv "C:Gecispilot_kullanicilar.csv" -NoTypeInformation

Büyük mailbox’larda taşıma bazen uzun sürüyor. 50 GB’lık bir mailbox için 12-15 saat normal. Kullanıcıları bu konuda önceden bilgilendirmek şart, yoksa “maillerim kayboldu” paniklerine hazır olun.

Hatalı Taşımaları Yönetmek

Her büyük geçişte bazı mailbox’lar sorun çıkarır. Bunları tespit edip ayrıca ele almak gerekiyor:

# Başarısız taşımaları raporla
Get-MigrationUser -Status Failed | 
Select-Object Identity, Error | 
Export-Csv "C:Gecisbasarisiz_tasimalar.csv" -NoTypeInformation

# Sorunlu mailbox'ı yeniden dene
Set-MigrationUser -Identity "[email protected]" -Resubmit $true

# Mailbox taşıma loglarını incele
Get-MigrationUserStatistics -Identity "[email protected]" -IncludeReport | 
Select-Object -ExpandProperty Report

En sık karşılaştığım sorunlar şunlar: Bozuk takvim öğeleri, çok büyük tek mailler (150 MB üzeri), özel karakter içeren klasör isimleri ve corrupted PST benzeri sorunlar. Bu tip mailbox’ları elle müdahaleyle taşımak gerekebilir.

Kullanıcı Geçişi ve Outlook Yapılandırması

Mailbox taşındıktan sonra kullanıcının Outlook’unun yeni profille açılması gerekiyor. Hibrit yapıda Autodiscover düzgün çalışıyorsa bu otomatik oluyor. Ama gerçek hayatta her zaman öyle olmuyor.

# Autodiscover testini kullanıcı bazlı yap
Test-MsolUser -UserPrincipalName "[email protected]"

# Exchange Online'dan Autodiscover servis URL'ini kontrol et
Get-ClientAccessService | Select-Object Name, AutoDiscoverServiceInternalUri

# Outlook profil sıfırlama scripti (kullanıcı bilgisayarında çalıştır)
# Mevcut Outlook profillerini listele
$profiller = Get-ChildItem "HKCU:SoftwareMicrosoftOffice16.0OutlookProfiles"
Write-Host "Mevcut Outlook Profilleri:" -ForegroundColor Yellow
$profiller | ForEach-Object { Write-Host $_.Name }

Büyük kurumlarda bu işlemi her kullanıcıya tek tek yapmak imkânsız. Login script veya GPO ile otomatize etmek şart. Ben genellikle şu yaklaşımı kullanıyorum: Taşınan kullanıcılara bir sonraki oturumda Outlook profilini otomatik yeniden oluşturan bir script deploy ediyorum.

Geçiş Sonrası Kontroller

Geçiş tamamlandıktan sonra “bitti” demek için acele etmeyin. Bir hafta boyunca yakın takip gerekiyor.

# Tüm mailbox'ların başarıyla taşındığını doğrula
Get-Mailbox -ResultSize Unlimited | 
Where-Object {$_.RecipientTypeDetails -eq "UserMailbox"} | 
Get-MailboxStatistics | 
Where-Object {$_.TotalItemSize -eq $null} | 
Select-Object DisplayName

# Mail flow testini her iki yönde de yap
Send-MailMessage -To "[email protected]" `
  -From "[email protected]" `
  -Subject "Gecis Sonrasi Mail Flow Testi" `
  -Body "Bu bir test mailidir." `
  -SmtpServer "smtp.office365.com" -Port 587 `
  -Credential (Get-Credential) -UseSsl

# Microsoft 365 Message Trace ile mail akışını izle
Get-MessageTrace -RecipientAddress "[email protected]" `
  -StartDate (Get-Date).AddHours(-24) `
  -EndDate (Get-Date) | 
Select-Object Received, SenderAddress, Subject, Status | 
Format-Table -AutoSize

Kontrol listem şöyle:

  • Tüm kullanıcılar Outlook’tan bağlanabiliyor mu?
  • Mobil cihazlar (ActiveSync) senkronize oluyor mu?
  • Takvim paylaşımları çalışıyor mu?
  • Oda ve kaynak mailbox’ları düzgün görünüyor mu?
  • Distribution group’lar düzgün çalışıyor mu?
  • Out-of-office mesajları çalışıyor mu?
  • Shared mailbox erişimleri sorunsuz mu?

Exchange Sunucusunu Devre Dışı Bırakmak

Tüm kullanıcılar taşındıktan sonra on-premises Exchange sunucusunu kapatabilirsiniz. Ama bu adımı gereksiz yere aceleye getirmeyin. Benim standart yaklaşımım: Tüm taşıma tamamlandıktan sonra 30 gün daha Exchange’i çalışır durumda tutmak. Bu sürede beklenmedik bir sorun çıkarsa geri dönüş seçeneğiniz var.

Exchange’i kaldırmak için doğru sıra şu:

  • Önce tüm mailbox’ların taşındığını teyit et
  • MX kaydının Microsoft 365’e işaret ettiğini doğrula
  • Exchange sertifikasının süresi dolmadan önce gerekli işlemleri tamamla
  • Send ve Receive connector’ları kaldır
  • Exchange servislerini durdur
  • Uninstall işlemini Add/Remove Programs üzerinden değil, Exchange setup ile yap
# Exchange'i kaldırmadan önce son kontroller
# Kalan on-premises mailbox kontrolü
Get-Mailbox -ResultSize Unlimited | 
Where-Object {$_.RecipientTypeDetails -eq "UserMailbox"} | 
Select-Object DisplayName, PrimarySmtpAddress | 
Format-Table

# System mailbox'ları kontrol et (bunlar kalabilir)
Get-Mailbox -ResultSize Unlimited -Arbitration | 
Select-Object Name, RecipientTypeDetails

Sık Yapılan Hatalar

Kendi yaptıklarım ve başkalarının yaptıklarını gördüklerimi paylaşayım:

Listelenmiş olmayan service account’ları gözden kaçırmak: Yazıcılar, ERP sistemleri, monitoring araçları Exchange üzerinden mail gönderiyorsa bunların yapılandırmasını güncellemek gerekiyor. Geçiş sonrası “faks makinesi artık mail gönderemiyor” şikayetiyle karşılaşmak istemezsiniz.

DNS TTL’ini düşürmeyi unutmak: Geçiş gününden 48 saat önce TTL’i 300-600 saniyeye düşürün. Değiştirmeyi unutursanız MX değişikliğinizin yayılması 24-48 saat sürebilir, bu sürede mail kayıpları yaşanabilir.

Pilot test yapmadan tüm şirketi taşımak: Pilot grup olmadan 500 kişiyi aynı anda taşırsanız, sorun çıktığında 500 kullanıcı şikayet ediyor demektir. Pilot grup bu yükü önemli ölçüde azaltıyor.

Lisans atamayı unutmak: Kullanıcı Microsoft 365’e senkronize edildi diye hesabının hazır olduğu anlamına gelmiyor. Exchange Online lisansı atanmadan mailbox oluşturulmuyor.

Geri dönüş planı hazırlamamak: Her büyük değişiklikte olduğu gibi, geçişin ters gittiği senaryoyu düşünün ve geri dönüş adımlarını belgeleyin.

Sonuç

Exchange’den Microsoft 365’e geçiş, iyi planlandığında oldukça sorunsuz ilerleyen bir proje. Kötü planlandığında ise haftalarca süren bir kabus olabilir. Deneyimlerime göre başarılı geçişlerin ortak özellikleri şunlar: Öncesinde kapsamlı envanter çıkarılmış, pilot testler yapılmış, kullanıcılar önceden bilgilendirilmiş ve her adım için geri dönüş planı hazırlanmış.

Geçiş sonrasında Microsoft 365’in getirdiği avantajlar gerçekten somut. Sertifika yenileme derdinden kurtuluyorsunuz, donanım bakımı gitmiş oluyor, Exchange güncellemelerini takip etmek zorunda kalmıyorsunuz. Üstüne üstlük güvenlik özellikleri (MFA, Conditional Access, Defender for Office 365) on-premises ortamda yapmanın çok daha maliyetli olduğu şeyler.

Eğer bu geçişi planlıyorsanız, Microsoft’un resmi geçiş dokümantasyonunu ve Microsoft 365 FastTrack programını da mutlaka inceleyin. 150 kullanıcı üzerindeki kuruluşlar için FastTrack ücretsiz teknik destek sunuyor, boşa harcamamak lazım.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir