Zimbra’dan Exchange veya Microsoft 365’e Geçiş Rehberi

Yazar:komut.io ekibi Zimbra Mail Sunucusu Kurulum ve Yönetimi
0 Yorum

Yıllarca Zimbra yönettiyseniz, bir gün mutlaka “bunu Exchange’e ya da Microsoft 365’e taşımamız gerekiyor” toplantısıyla karşılaşırsınız. Ben bu toplantıyı birden fazla kez yaşadım ve her seferinde “ne kadar sürer?” sorusunun cevabı “düşündüğünüzden uzun” oldu. Bu yazıda, bu geçiş sürecini gerçekten yapan biri olarak anlık notlarımı ve öğrendiğim dersleri paylaşacağım.

Neden Geçiş Yapılıyor?

Önce durumu netleştirelim. Zimbra kötü bir yazılım değil. Özellikle Open Source Edition, bütçesi kısıtlı kurumlar için hâlâ geçerli bir çözüm. Ama şu senaryolar geçişi kaçınılmaz hale getiriyor:

  • Zimbra Network Edition lisans maliyetleri artık Microsoft 365 ile rekabet edemez hale geliyor
  • Active Directory entegrasyonu sorunları birikiyor
  • Outlook istemci uyumsuzlukları son kullanıcıları yoruyor
  • Mobil cihaz yönetimi (MDM) entegrasyonu yetersiz kalıyor
  • Kurumsal uyumluluk gereksinimleri (KVKK, ISO 27001 gibi) Microsoft ekosistemini zorunlu kılıyor

Geçişi planlayan bir sistem yöneticisi olarak ilk yapmanız gereken şey, kaç kullanıcı, kaç GB mail, kaç domain olduğunu net olarak bilmek.

Ortamı Tanımak: Zimbra Envanter Çıkarma

Geçişe başlamadan önce Zimbra ortamınızın tam fotoğrafını çekmeniz gerekiyor. Bu adımı atlarsanız ilerleyen süreçte sürprizlerle karşılaşırsınız.

Toplam kullanıcı sayısını ve posta kutusu boyutlarını görmek için:

zmprov -l gaa | wc -l

Her kullanıcının posta kutusu boyutunu listelemek için:

zmprov -l gqu "" | grep used | awk '{print $1, $3}'

Domain listesini çıkarmak için:

zmprov gad

Dağıtım listelerini (distribution list) görmek için:

zmprov -l gadl

Bu çıktıları bir dosyaya yönlendirin ve Microsoft tarafındaki teknik ekiple paylaşın. Özellikle dağıtım listeleri ve shared mailbox’lar geçiş sırasında en çok unutulan şeyler oluyor.

Posta kutusu boyutlarını daha okunabilir formatta export etmek isterseniz:

#!/bin/bash
echo "Email,UsedMB" > mailbox_sizes.csv
zmprov -l gaa | while read user; do
    used=$(zmprov gqu "$user" | grep used | awk '{print $3}')
    used_mb=$((used / 1048576))
    echo "$user,$used_mb" >> mailbox_sizes.csv
done
echo "Export tamamlandi: mailbox_sizes.csv"

Bu script büyük ortamlarda uzun sürebilir. Gece çalıştırmanızı tavsiye ederim.

Geçiş Yöntemi Seçimi

İki ana yol var: Cutover (kesme) ve Staged (aşamalı) geçiş. Üçüncü bir yol olan hybrid yaklaşımı da var ama küçük-orta ölçekli kurumlarda pek tercih edilmiyor.

Cutover geçiş: Herkesi aynı anda taşırsınız. 150 kullanıcı altı ortamlar için mantıklı. Bir hafta sonu, bir gece ve ciddi bir hazırlık gerektirir.

Staged geçiş: Bölümler ya da gruplar halinde taşırsınız. Her aşamada bir departman geçiş yapar. Daha kontrollü ama mail akışını iki sunucu arasında yönetmek zorunda kalırsınız.

Ben genellikle 200 kullanıcı üstü ortamlarda staged geçişi tercih ediyorum çünkü bir şeyler ters gittiğinde yalnızca bir departmanı etkiliyor.

PST ile Dışa Aktarma: Zimbra Tarafı

Geçişin teknik kalbine geliyoruz. Zimbra’dan veriyi çıkarmanın birkaç yolu var. En yaygın ve güvenilir yöntem, imapsync veya Zimbra’nın kendi araçlarıyla IMAP üzerinden senkronizasyon.

Ama önce klasik yöntemden bahsedelim: zmmailbox ile TGZ export.

zmmailbox -z -m [email protected] getRestURL "//?fmt=tgz&resolve=skip" > /tmp/kullanici_export.tgz

Bu komutu tüm kullanıcılar için döngüye almak isterseniz:

#!/bin/bash
EXPORT_DIR="/backup/zimbra_exports"
mkdir -p "$EXPORT_DIR"

zmprov -l gaa | while read user; do
    echo "Exporting: $user"
    zmmailbox -z -m "$user" getRestURL "//?fmt=tgz&resolve=skip" > "$EXPORT_DIR/${user}.tgz"
    if [ $? -eq 0 ]; then
        echo "OK: $user"
    else
        echo "HATA: $user" >> "$EXPORT_DIR/errors.log"
    fi
done

TGZ dosyalarını Exchange veya M365’e doğrudan aktaramazsınız. Bu aşamada üçüncü parti araçlara ihtiyaç duyuyorsunuz: Zextras Migration Tool, BitTitan MigrationWiz, veya imapsync.

imapsync ile IMAP Tabanlı Geçiş

imapsync, açık kaynaklı ve son derece güvenilir bir araç. Zimbra ile Microsoft 365 arasında IMAP üzerinden doğrudan senkronizasyon yapabilirsiniz. Ben bunu özellikle staged geçişlerde kullanıyorum çünkü geçiş sırasında kullanıcılar Zimbra’yı kullanmaya devam edebiliyor.

imapsync kurulumu (Ubuntu/Debian):

apt-get install -y imapsync

Tek kullanıcı için geçiş örneği:

imapsync 
  --host1 zimbra.domain.com 
  --user1 [email protected] 
  --password1 "ZimbraParola123" 
  --ssl1 
  --host2 outlook.office365.com 
  --user2 [email protected] 
  --password2 "M365Parola456" 
  --ssl2 
  --port2 993 
  --automap 
  --skipcrossduplicates 
  --useheader "Message-ID" 
  --exclude "Junk" 
  --exclude "Spam" 
  2>&1 | tee /var/log/imapsync_${user}.log

--skipcrossduplicates parametresi önemli. Birden fazla çalıştırmanız gerektiğinde aynı maili iki kez kopyalamanın önüne geçiyor.

Toplu geçiş için basit bir script:

#!/bin/bash
# users.txt: her satırda "zimbraemail:zimbrapassword:m365email:m365password" formatı

while IFS=: read -r z_user z_pass m_user m_pass; do
    echo "$(date) - Baslıyor: $z_user -> $m_user"
    imapsync 
        --host1 zimbra.domain.com 
        --user1 "$z_user" 
        --password1 "$z_pass" 
        --ssl1 
        --host2 outlook.office365.com 
        --user2 "$m_user" 
        --password2 "$m_pass" 
        --ssl2 --port2 993 
        --automap 
        --skipcrossduplicates 
        2>&1 >> /var/log/imapsync_bulk.log
done < users.txt

Şunu söylemeliyim: parola yönetimi bu scriptte ham metin olduğu için dikkatli olun. Üretim ortamında bu dosyayı şifreli tutun ve geçiş sonrası silin.

Microsoft 365 Tarafında Hazırlık

Geçişe başlamadan önce M365 tarafında yapılması gerekenler var. Azure Active Directory’de kullanıcıların oluşturulmuş ve lisanslarının atanmış olması gerekiyor. Bunu elle yapmak yerine PowerShell ile otomatize etmek çok daha akıllıca.

Toplu kullanıcı oluşturma (CSV’den):

# CSV formatı: DisplayName,UserPrincipalName,Password,Department
Import-Module MSOnline
Connect-MsolService

$users = Import-Csv -Path "C:migrationusers.csv"

foreach ($user in $users) {
    New-MsolUser `
        -DisplayName $user.DisplayName `
        -UserPrincipalName $user.UserPrincipalName `
        -Password $user.Password `
        -ForceChangePassword $false `
        -Department $user.Department
    
    # Exchange Online lisansı ata (SKU ID ortama göre değişir)
    Set-MsolUserLicense `
        -UserPrincipalName $user.UserPrincipalName `
        -AddLicenses "tenantname:ENTERPRISEPACK"
    
    Write-Host "Oluşturuldu: $($user.UserPrincipalName)"
}

Dağıtım listelerini M365’e aktarmak için de benzer bir yaklaşım gerekiyor. Zimbra’dan dağıtım listesi üyelerini çekip M365’te yeniden oluşturmanız gerekiyor. Bunu manuel yapmayın, zamanınıza yazık olur.

DNS Geçişi: En Kritik An

İşte burada çoğu geçiş ya başarıyla tamamlanıyor ya da saatler süren kaosla sonuçlanıyor. MX kaydı değişikliği geri dönüşü en zor adım.

Geçiş öncesi mevcut DNS TTL değerini düşürün. Geçişten 24-48 saat önce TTL’i 300 saniyeye (5 dakika) indirin:

# Mevcut MX kaydını kontrol et
dig MX domain.com +short

# TTL değerini kontrol et
dig MX domain.com | grep -i "MX"

MX kaydını değiştirmeden önce SPF, DKIM ve DMARC kayıtlarını güncellemeniz gerekiyor. Microsoft 365 için SPF kaydı şöyle olmalı:

v=spf1 include:spf.protection.outlook.com -all

DKIM için M365 Admin Center’dan “Email Authentication” bölümüne girip domain’iniz için DKIM’i etkinleştirmeniz ve size verilen CNAME kayıtlarını DNS’e eklemeniz gerekiyor.

MX kaydı değişikliğinin ardından, eski Zimbra sunucusunun yeni mailleri kabul etmemesi için bir süre relay ayarı yapmanız önerilir. Geçiş penceresi sırasında Zimbra’yı kapatmayın; bazı kuyrukta bekleyen mailler olabilir.

# Zimbra mail kuyruğunu kontrol et
zmprov ms `zmhostname` zimbraMtaRelayHost outlook.office365.com:587
postqueue -p | grep -c "^[A-F0-9]"

Takvim ve Kişiler

Pek çok geçiş projesinde maile odaklanılıp takvim ve kişiler ihmal ediliyor. Sonra “eski randevularım yok” şikayetleri geliyor. Zimbra’dan takvim ve kişi verilerini ical/vCard formatında export etmek mümkün.

# Takvim export
zmmailbox -z -m [email protected] getRestURL "/Calendar?fmt=ics" > /tmp/kullanici_calendar.ics

# Kişiler export
zmmailbox -z -m [email protected] getRestURL "/Contacts?fmt=csv" > /tmp/kullanici_contacts.csv

Toplu export için:

#!/bin/bash
EXPORT_DIR="/backup/zimbra_calendar_contacts"
mkdir -p "$EXPORT_DIR/calendars" "$EXPORT_DIR/contacts"

zmprov -l gaa | while read user; do
    zmmailbox -z -m "$user" getRestURL "/Calendar?fmt=ics" 
        > "$EXPORT_DIR/calendars/${user}.ics" 2>/dev/null
    
    zmmailbox -z -m "$user" getRestURL "/Contacts?fmt=csv" 
        > "$EXPORT_DIR/contacts/${user}.csv" 2>/dev/null
    
    echo "Tamamlandi: $user"
done

ICS dosyaları, Exchange/M365 tarafında PowerShell ile import edilebilir ya da Outlook üzerinden kullanıcılara yaptırılabilir. Büyük kurumlarda bu işlemi IT helpdesk üzerinden bireysel olarak yapmak daha güvenli oluyor.

Geçiş Sonrası Doğrulama

Geçiş tamamlandıktan sonra “tamam, bitti” deyip sunucudan çıkmayın. Doğrulama listesi olmadan geçiş bitmez.

Kontrol etmeniz gerekenler:

  • Mail akışı: Hem gelen hem giden maillerin çalıştığını test edin. Farklı harici domain’lerden test maili gönderin
  • Spam filtreleme: M365 ATP veya EOP’un devrede olduğunu doğrulayın
  • Shared mailbox’lar: Tüm paylaşımlı posta kutularının erişilebilir olduğunu test edin
  • Dağıtım listeleri: Birkaç distribution list’e test maili gönderin
  • Otomatik yanıtlar: Out-of-office kurallarının çalıştığını kontrol edin
  • Mobile ActiveSync: Telefon ve tablet bağlantılarını test edin
  • Outlook profili: Birkaç kullanıcının Outlook’unu sıfırdan yapılandırın ve test edin

M365 tarafında mail akışını loglardan takip etmek için Exchange Admin Center’ın “Message Trace” özelliğini kullanın. Zimbra’dan farklı olarak gerçek zamanlı log takibi burada daha kolay.

# PowerShell ile son 24 saatin mail trace'i
Connect-ExchangeOnline
Get-MessageTrace -StartDate (Get-Date).AddHours(-24) -EndDate (Get-Date) | 
    Where-Object {$_.Status -eq "Failed"} | 
    Select-Object SenderAddress, RecipientAddress, Subject, Status |
    Export-Csv -Path "C:migrationfailed_mails.csv" -NoTypeInformation

Zimbra Sunucusunu Kapatmak

En az 2 hafta boyunca Zimbra sunucusunu açık tutun. Geçişten sonra eski sunucuya sormak isteyenler, yanlış yönlendirilen mailler veya unutulan bir servis çıkabilir. Ben standart olarak 30 gün bekletiyorum.

Sunucuyu kapatmadan önce son bir tam yedek alın:

# Zimbra servislerini durdur
su - zimbra -c "zmcontrol stop"

# Tüm Zimbra dizinini arşivle
tar -czf /backup/zimbra_final_backup_$(date +%Y%m%d).tar.gz /opt/zimbra/

# Boyutu kontrol et
ls -lh /backup/zimbra_final_backup_*.tar.gz

Bu yedeği en az 1 yıl saklayın. Bir gün birileri “2 yıl önce gönderilen o mail var mıydı acaba” diye soracak.

Sık Karşılaşılan Sorunlar

Her geçiş projesi bir öncekinden farklı bir sürpriz üretiyor. Ama bazı sorunlar neredeyse her seferinde karşıma çıkıyor.

Karakter kodlama sorunları: Türkçe karakter içeren konu satırları ya da gövde metin bazen bozuluyor. Özellikle eski Zimbra sürümlerinden gelen ISO-8859-9 kodlamalı mailler. imapsync genellikle bunu hallediyor ama kontrol edin.

Klasör eşleştirme: Zimbra’da “Junk” olan klasör M365’te “Gereksiz E-posta” oluyor. --automap parametresi çoğu zaman yeterli ama el ile kontrol şart.

Büyük posta kutuları: 50 GB üzeri posta kutuları imapsync ile taşırken zaman aşımı sorunları çıkabiliyor. Bu durumda --maxsize parametresiyle önce büyük ekleri atlayıp, sonra ayrıca işleyebilirsiniz.

Uygulama entegrasyonları: CRM, ERP veya başka sistemler Zimbra’ya SMTP relay için bağlıysa bunları güncellemeyi unutmayın. Geçiş sonrası en çok gözden kaçan şey bu oluyor.

Arşiv posta kutuları: Zimra’da in-place arşivi kullanıyorsanız, bu verileri ayrıca export etmeniz gerekiyor. Exchange Online Archiving’e taşıma için farklı bir süreç gerekiyor.

Kullanıcı İletişimi

Teknik tarafı ne kadar iyi yönetirseniz yönetin, kullanıcıları hazırlamadan yaptığınız geçiş kaos üretir. En az 2 hafta önceden basit bir mail ile bilgilendirin. “Ne değişecek, ne yapmaları gerekiyor, nereden yardım alabilirler” soruları cevaplanmış olsun.

Geçiş günü için bir helpdesk ekibi hazır tutun. “Outlook açılmıyor”, “şifremi giriyorum kabul etmiyor”, “eski maillerim yok” şikayetleri ilk 48 saatte yoğunlaşıyor.

Mobil cihaz yapılandırması için basit bir ekran görüntülü kılavuz hazırlayın. Bu belgeyi geçişten önce dağıtın.

Sonuç

Zimbra’dan Exchange ya da Microsoft 365’e geçiş, doğru planlanırsa oldukça pürüzsüz ilerleyebiliyor. Ama “doğru planlamak” kısmı gerçekten kritik. Envanter çıkarmadan başlamayın, DNS değişikliğini aceleye getirmeyin, ve geçiş sonrası Zimbra sunucusunu hemen kapatmayın.

Bu süreçte en çok zaman kaybettiren şeyin genellikle teknik değil, organizasyonel konular olduğunu söylemek isterim. Hangi kullanıcı hangi lisansı alacak, shared mailbox’lara kim erişebilecek, arşiv politikası ne olacak gibi kararlar için IT departmanı tek başına karar veremez. Bu konuları yönetime erkenden taşıyın.

Geçiş başarıyla tamamlandığında, Microsoft 365’in özellikle Teams entegrasyonu, Conditional Access ve modern kimlik doğrulama gibi konularda Zimbra’ya kıyasla ciddi avantajlar sunduğunu göreceksiniz. Bu avantajları doğru yapılandırılmış bir ortamda kullanmak için biraz daha zaman ayırın. Geçiş bitmek değil, daha kapsamlı bir kurumsal dijital dönüşümün başlangıcı oluyor çoğunlukla.

Bir yanıt yazın

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