Exchange Management Shell ile Posta Kutusunu Farklı Veritabanına Taşımak

Kurumsal Exchange ortamlarında posta kutularını doğru veritabanlarına yerleştirmek performans, kapasite planlama, bakım kolaylığı ve iş sürekliliği açısından kritik öneme sahiptir.

Bölümler arasında taşınan çalışanlar, hızla büyüyen veritabanları, emekliye ayrılacak depolama kümeleri ya da yeni donanım geçişleri gibi çok sayıda senaryo, posta kutularının farklı veritabanlarına güvenli ve kontrollü şekilde taşınmasını gerektirir. İyi haber şu ki Exchange Server’da online move mimarisi sayesinde kullanıcı oturumlarını minimum etkiyle yeni veritabanına aktarabilir.

Bu makalemde Exchange Management Shell kullanarak tekil ve toplu taşıma işlemlerini uçtan uca anlatır.

Önce sağlık kontrolleri ve ön koşullarla başlar, ardından basit bir taşıma örneği (ör. kadir.kozan → DB01) üzerinden temel akışı gösterir.

Sonrasında düşük kesinti için SuspendWhenReadyToComplete yaklaşımı, büyük/bozuk öğelere tolerans tanımlama, arşiv posta kutusu (archive) senaryoları, CSV ile toplu taşıma, süreç boyunca izleme–log inceleme ve tamamlandıktan sonra yapılacak doğrulama adımlarını ele alır.

Ayrıca yoğun ortamlarda performansı etkileyen MRS eşzamanlılık ayarlarına değinir en iyi pratikler, sık hatalar ve hızlı geri dönüş yöntemlerini de pratik komutlarla özetler.

Hedefimiz ister tek bir posta kutusunu taşıyor olun ister yüzlercesini yeniden dengeleyin her adımı tekrarlanabilir, denetlenebilir ve riski düşük bir çalışma kalıbına dönüştürmektir.

Makaledeki örnekler Exchange 2016/2019/SE sürümleri için uyumludur ve RBAC izinleri veritabanı durumu (Mounted/Content Index Healthy) gibi temel gereksinimlerin sağlandığı bir üretim ortamını esas alır.

Neden Taşıma Yapılır?

• Depolama dengesi: Bazı DB’ler hızla şişer; yük dağıtmak gerekir.
• Performans/IO planlaması: Sıcak veriyi farklı disk/volume’a almak.
• Bakım/yaşam döngüsü: Eski DB’nin boşaltılıp emekli edilmesi.
• Kurumsal düzen: Bölüm/şehir/sunumcu bazlı ayrıştırma.

Exchange’te posta kutusu taşıma online gerçekleşir; kullanıcı genellikle kısa bir “yeniden bağlanma” dışında kesinti yaşamaz.

Ön Koşullar: Hızlı Sağlık Kontrolü

Taşıma öncesi aşağıdakileri doğrulayın:

# DB’ler mounted mı?
Get-MailboxDatabase | ft Name,Mounted

# İçerik dizini (Content Index) sağlıklı mı?
Get-MailboxDatabaseCopyStatus * | ft Name,Status,ContentIndexState -Auto

# MRS çalışıyor mu?
Get-Service MSExchangeMailboxReplication

• Hedef DB’de yeterli boş alan/kota.
• Ağ ve RBAC yetkileri (Mailbox move yapabilen hesap).
• Antivirüs/backup ajanlarının yoğun IO’su varsa planlı pencere.

En Basit Senaryo: Tek Kullanıcıyı Taşıma

Örnek: kadir.kozan posta kutusunu DB01 veritabanına taşı:

New-MoveRequest -Identity "kadir.kozan" -TargetDatabase "DB01"

İlerlemeyi izleyin:

Get-MoveRequest -Identity "kadir.kozan" | 
  Get-MoveRequestStatistics | 
  ft DisplayName,Status,StatusDetail,PercentComplete,TotalMailboxSize,BadItemsEncountered,LargeItemsEncountered -Auto

Tamamlanınca temizlik:

Remove-MoveRequest -Identity "kadir.kozan" -Confirm:$false

Not: “Completed” olan istekler listede durur; yenisine engel olmaması için silin.

Düşük Kesinti Stratejisi: “Hazır Olunca Durdur”

Gündüz veri kopyalansın, akşam kısa bir kesinti ile “cutover” olsun:

# Gündüz kopyala, bitmeye yakın otomatik dur
New-MoveRequest -Identity "kadir.kozan" -TargetDatabase "DB01" -SuspendWhenReadyToComplete

# Pencere açılınca tamamla
Resume-MoveRequest -Identity "kadir.kozan"

Alternatif: Zamanlama isterseniz -CompleteAfter parametresiyle kesit anını geleceğe tarihleyebilirsiniz.

Büyük/Bozuk Öğeler: Tolerans Verme

Bazen dev ekler/bozuk mesajlar taşıma sürecini durdurur. Tolerans tanımlayabilirsiniz:

New-MoveRequest -Identity "kadir.kozan" -TargetDatabase "DB01" `
  -BadItemLimit 25 -LargeItemLimit 10 -AcceptLargeDataLoss:$false

• BadItemLimit: Bozuk öğe sayısı eşiği.
• LargeItemLimit: Çok büyük öğe eşiği.
• AcceptLargeDataLoss: Zorunlu olmadıkça kullanmayın.

Arşiv Posta Kutusu (Archive) Taşıma

Varsayılan komut yalnızca birincil posta kutusunu taşır.

• Sadece arşiv:

New-MoveRequest -Identity "kadir.kozan" -ArchiveOnly -ArchiveTargetDatabase "DB01"

• Birincil + arşiv (ayrı komutlarla):

New-MoveRequest -Identity "kadir.kozan" -TargetDatabase "DB01"
New-MoveRequest -Identity "kadir.kozan" -ArchiveOnly -ArchiveTargetDatabase "DB01"

İhtiyaca göre arşivi farklı bir DB’ye yönlendirmek iyi bir kapasite yönetimi tekniğidir.

7) Toplu Taşıma: CSV ve Dinamik Dağıtım

CSV ile:

User,TargetDB
kadir.kozan,DB01
ayse.okuyucu,DB02
mehmet.eryilmaz,DB03
lena.kozan,DB01
ahmet.elibol,DB02

Import-Csv .\moves.csv | %{
  New-MoveRequest -Identity $_.User -TargetDatabase $_.TargetDB -BatchName "Rebalance-2025-08"
}

Bir DB’yi boşaltıp diğerlerine saç:

$targets = "DB01","DB02","DB03"
$i = 0
Get-Mailbox -Database "DB-Eski" -ResultSize Unlimited | %{
  $db = $targets[$i % $targets.Count]
  New-MoveRequest -Identity $_.PrimarySmtpAddress -TargetDatabase $db -BatchName "Drain-DB-Eski"
  $i++
}

Toplu izleme/temizlik:

Get-MoveRequest -BatchName "Rebalance-2025-08" | 
  Get-MoveRequestStatistics | 
  ft DisplayName,Status,PercentComplete,TotalMailboxSize -Auto

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest -Confirm:$false

Taşıma Durumları ve Loglar

Durum akışı: Queued → InProgress → AutoSuspended (opsiyonel) → Completed / CompletedWithWarning / Failed

Derin izleme:

Get-MoveRequestStatistics "kadir.kozan" | 
  fl DisplayName,Status,StatusDetail,PercentComplete,BytesTransferred,EstimatedTransferSize,EstimatedTransferTime,BadItemsEncountered,LargeItemsEncountered

MRS log dizini (sorun giderme):

C:\Program Files\Microsoft\Exchange Server\V15\Logging\MailboxReplicationService\

Olay günlükleri: Application Log (MRS/Exchange ilgili uyarı–hatalar).

9) Performans ve Eşzamanlılık

Büyük çaplı taşımada MRS eşzamanlılık ayarları işinize yarar (dikkatle, bakım penceresinde ayarlayın):

Get-MRSConfiguration | fl MaxActiveMovesPerSourceMDB,MaxActiveMovesPerTargetMDB,MaxActiveMovesPerSourceServer,MaxActiveMovesPerTargetServer,MaxActiveMovesPerForest
# Set-MRSConfiguration ile değiştirilebilir; artırmadan önce CPU/IO’yu izleyin.

Not: Cross-forest/hybrid senaryolarda MRSProxy (EWS) tarafı da açık ve politikaları uyumlu olmalıdır.

Taşıma Sonrası Doğrulama

# Kullanıcı artık hangi DB’de?
Get-Mailbox -Identity "kadir.kozan" | ft Name,Database

# Kutu istatistikleri
Get-MailboxStatistics -Identity "kadir.kozan" | 
  ft DisplayName,TotalItemSize,ItemCount,LastLogonTime -Auto

# Mail akışı (opsiyonel)
Test-Mailflow -TargetMailboxServer (Get-Mailbox "kadir.kozan").ServerName

İstemciler (Outlook/Mobile) genellikle kısa bir yeniden bağlanma ile yeni DB’ye sorunsuz geçer.

Sık Karşılaşılan Sorunlar ve Çözümler

• Önceden move request var → Get-MoveRequest ile bulun, Remove-MoveRequest ile silin.
• Bozuk/büyük öğe nedeniyle hata → -BadItemLimit/-LargeItemLimit verin, sonra Resume-MoveRequest.
• Hedef DB ContentIndex bozuk → ContentIndexState düzeltmeden taşıma planlamayın.
• Aşırı yavaşlık → Eşzamanlılık fazla olabilir; Set-MRSConfiguration değerlerini düşürün, bant–IO–AV etkisini izleyin.
• Litigation Hold/Retention → Taşıma olur; ancak veri hacmi büyük olduğundan daha uzun sürebilir.
• Public Folder/Arbitration/Discovery → Bazıları özel işlem gerektirir; dokümantasyona göre planlayın.