Exchange Hybrid Posta Kutusu Taşıma Hataları ve Çözümü (2026)

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-100 / MS-102 / AZ-104 sertifikalı danışmanlar · Son güncelleme: 5 Ekim 2026

Özet (TL;DR): Exchange hybrid (şirket içi Exchange ile Exchange Online'ın birlikte çalıştığı yapı) ortamında posta kutusu taşıma işlemi başlamıyor ya da yarıda kalıyorsa sebep çoğunlukla dört yerden biridir: taşıma servisi olan MRS Proxy kapalıdır (403 Forbidden hatası), güvenlik duvarı veya saldırı tespit cihazı taşıma trafiğini keser, posta kutusunda bozuk öğe vardır (TooManyBadItemsPermanentException) ya da eski bir taşıma kaydı yolu tıkar. Microsoft'un resmi sorun giderme rehberi ve 403 Forbidden makalesi bu dört nedeni sırayla elemeyi önerir. Bu yazıda hata mesajlarını, her birinin kök nedenini ve en kolaydan en zora doğru çözüm adımlarını PowerShell komutlarıyla veriyoruz. Hazırlık için Microsoft'un 24 Ocak 2024 tarihli, 25 Haziran 2025'te güncellenmiş destek makalelerine dayandık.

Taşıma haftasında hata aldınız ve takvim sıkışık mı? Ücretsiz Exchange taşıma teşhisi isteyin: hata çıktısını inceleyip aynı gün ilk yönlendirmeyi yapalım.

Neden şimdi: Exchange 2016 ve 2019 için süre daralıyor

Exchange Server 2016 ve 2019 için destek 14 Ekim 2025'te bitti. Ücretli güvenlik güncelleştirmesi programının ikinci ve son dönemi Ekim 2026 sonunda kapanıyor; bu tarihleri ve kararı nasıl vereceğinizi Exchange 2016/2019 destek sonu rehberimizde anlattık. Sonuç şu: Hâlâ şirket içi Exchange kullanan kurumların posta kutularını buluta taşımak için çok az zamanı var ve taşıma sırasında çıkan hatalar bu takvimi doğrudan etkiliyor.

Önce terimleri sadeleştirelim. Hybrid, şirket içindeki Exchange sunucunuzla Exchange Online'ın aynı e-posta alanında birlikte çalışmasıdır. Posta kutusu taşıma (remote move) bu yapıda bir kullanıcının kutusunu sunucudan buluta (ya da geri) kopyalayıp son anda yönlendirmeyi değiştirmektir. MRS Proxy ise bu kopyalama için şirket içi sunucuda açık olması gereken küçük bir servistir; bulut, sunucunuza bu servis üzerinden bağlanır. Evinize taşınma firmasını düşünün: MRS Proxy, firmanın içeri girebilmesi için açık bırakılan kapıdır.

Belirtiler: Hangi hata mesajını görüyorsunuz?

Başlangıç noktanız ekranda gördüğünüz mesajdır. Microsoft Learn belgelerinde geçen tam ifadeler şunlardır:

• The connection to the server 'mail.<AlanAdi>.com' could not be completed (Exchange yönetim merkezinde, taşıma başlarken).
• The call to 'https://mail.<AlanAdi>.com/EWS/mrsproxy.svc' failed ... The remote server returned an error: (403) Forbidden (PowerShell'de, RemoteTransientException olarak).
• TooManyBadItemsPermanentException (taşıma yarıda kesildi, bozuk öğe sınırı aşıldı).
• MigrationPermanentException: You must specify the PrimaryOnly parameter (yalnızca ana posta kutusunu taşımaya çalışırken).
• StalledDueToTarget_Processor ve taşıma raporunda MapiFxProxyTransientException: The data export was cancelled due to a timeout (taşıma durup duruyor).
• Hata yok ama taşıma günlerce Queued ya da Syncing durumunda bekliyor.

Hata mesajı, anlamı ve ilk bakılacak yer

Hata	Ne anlama gelir	İlk bakılacak yer
403 Forbidden / mrsproxy.svc	Bulut sunucunuza ulaştı ama MRS Proxy kapalı ya da kimlik doğrulama reddedildi	MRSProxyEnabled değeri ve IIS
TooManyBadItemsPermanentException	Kaynak kutuda kopyalanamayan (bozuk) öğe sayısı sınırı aştı	Taşıma raporu ve BadItemLimit
TooManyLargeItemsPermanentException	Hedefin kabul ettiği ileti boyutunu aşan öğeler var	LargeItemLimit ve ileti boyutu sınırı
You must specify the PrimaryOnly parameter	Yönetim merkezi yalnızca ana kutuyu taşıma seçeneği sunmuyor	New-MoveRequest -PrimaryOnly
StalledDueToTarget_Processor	Hedef taraf zaman aşımına uğruyor (Exchange 2013 sunucularında bilinen durum)	DataImportTimeout ayarı
Kayıt başlatılamıyor	Eski taşıma kaydı, eksik alan adı ya da eşleşmeyen posta kutusu kimliği	Get-MoveRequest ve Get-AcceptedDomain

Hızlı tanı: Ne zaman, nerede koptu?

Tahmin yürütmeden önce taşıma isteğinin durumunu okuyun. Microsoft, taşıma istekleri için şu iki komutu önerir ve durumların bulut tarafında başka işlere göre düşük öncelikle çalıştığını belirtir:

Get-MigrationBatch | fl *status*,Identity
Get-MoveRequest | fl *status*,Identity

Kural basit: istek hiç başlamadıysa sorun bağlantı katmanındadır (MRS Proxy, güvenlik duvarı, kimlik bilgisi). Başladı ama Failed oldu ise sorun veridedir (bozuk ya da büyük öğe). Sürekli beklemedeyse önce sabredin: Microsoft, yük altında taşımaların gecikebileceğini ve 8 saat gibi uzun bir süre ilerleme olmadan sorun gidermeye başlamamayı önerir.

Hatanın ayrıntısı için taşıma raporunu okuyun:

Get-MoveRequest -Identity <kullanici> | Get-MoveRequestStatistics -IncludeReport | FL

Çözüm 1: MRS Proxy açık mı? (403 Forbidden)

En sık rastlanan neden budur. Microsoft'a göre 403 hatası, hybrid sunucudaki EWS sanal dizininde MRS Proxy servisinin kapalı olmasından doğar. İki farklı durum olabilir: servis gerçekten kapalıdır, ya da komut çıktısı "açık" gösterirken servis fiilen kapalıdır.

Adım adım kontrol

1. Şirket içi sunucuda Exchange Yönetim Kabuğu'nu (Exchange Management Shell) açın.
2. Şu komutla durumu okuyun: Get-WebServicesVirtualDirectory "SunucuAdi\EWS (Default Web Site)" | FL Server,MRSProxyEnabled
3. Çıktı MRSProxyEnabled : False ise neden budur; aşağıdaki açma komutunu çalıştırın.
4. Çıktı True olduğu halde hata sürüyorsa Olay Görüntüleyicisi'nde Uygulama günlüğünde 1309 numaralı ASP.NET olayını arayın. İçinde MRS proxy service is disabled yazıyorsa servis fiilen kapalıdır; aç-kapa yöntemini uygulayın.

# MRS Proxy'yi aç
Set-WebServicesVirtualDirectory "<SunucuAdi>\EWS (Default Web Site)" -MRSProxyEnabled $true
iisreset

# Aç-kapa (olay 1309 varsa): önce kapat, birkaç dakika bekle, sonra aç
Set-WebServicesVirtualDirectory "<SunucuAdi>\EWS (Default Web Site)" -MRSProxyEnabled $false
Set-WebServicesVirtualDirectory "<SunucuAdi>\EWS (Default Web Site)" -MRSProxyEnabled $true
iisreset

Birden fazla dışarıya açık Exchange sunucunuz varsa ayarı hepsinde yapın; Microsoft aynı yapılandırmanın tüm dışa açık sunucularda bulunmasını ister. Kimlik doğrulama tarafı için WSSecurityAuthentication değerinin de True olması gerekir:

Get-WebServicesVirtualDirectory -Identity "Sunucu\EWS (default Web site)" | fl Server,MRSProxyEnabled,WSSecurityAuthentication

Çözüm 2: Güvenlik duvarı ve saldırı tespit sistemi

MRS Proxy açık ama bağlantı hâlâ kuruluyorsa sıradaki şüpheli, ağ cihazlarınızdır. Microsoft'un rehberi iki ayrı ihtimali sayar. Birincisi, güvenlik duvarının taşıma yollarını kimlik doğrulamadan geçirmemesi. Bu dört yolun, ön kimlik doğrulaması istenmeden sunucuya ulaşması gerekir:

• /ews/mrsproxy.svc
• /ews/exchange.asmx/wssecurity
• /autodiscover/autodiscover.svc/wssecurity
• /autodiscover/autodiscover.svc

İkincisi, saldırı tespit sisteminin yoğun taşıma trafiğini hizmet engelleme saldırısı sanması. Çözüm, Microsoft 365'in IP aralıklarını izin listesine almak ve dakikadaki HTTP istek sınırını artırmaktır. Çok sayıda posta kutusu taşıyorsanız varsayılan sınırlar kolayca aşılır. IP aralıkları için Microsoft'un yayımladığı Microsoft 365 URL ve IP adresi aralıkları sayfasına bakın.

Türkiye'de sık görülen durum: Birçok kurumda e-posta sunucusunun önünde bir web uygulama güvenlik duvarı (WAF) ya da ters vekil sunucu bulunur ve dışarıdan gelen her isteği oturum açtırarak geçirir. Bu tür bir cihaz yukarıdaki dört yolu karşılayamaz. Taşıma planınızın ilk günü yerine hazırlık haftasında bu kuralı ayrı bir yayınlama kuralı olarak tanımlayın.

Çözüm 3: Bozuk ve büyük öğeler (TooManyBadItems)

Taşıma başladı, yüzde 90'a geldi ve sonra TooManyBadItemsPermanentException ile durduysa kutuda kopyalanamayan öğeler var demektir. Bozuk öğe, kaynak kutuda bozulmuş olduğu için hedef kutuya kopyalanamayan öğedir. Microsoft'a göre taşıma, bu sayı belirlenen sınırı aşarsa devam edemez; varsayılan sınır 0'dır, yani tek bir bozuk öğe bile isteği durdurabilir. Aynı makale, eksik öğelerin de bozuk öğe sınırına sayıldığını, dolayısıyla TooManyMissingItemsPermanentException için de aynı çözümün geçerli olabileceğini söyler.

Önce ölçün, sonra sınırı yükseltin

$stats = Get-MailboxStatistics <SMTP adresi> -IncludeMoveReport
$report = $stats.MoveHistory[0].Report
$report.BadItems

Rapor kaç bozuk öğe bulunduğunu gösterir. Sonra sınırı bu sayıya göre yükseltip isteği sürdürün:

Get-MoveRequest <kimlik> | Set-MoveRequest -BadItemLimit <deger>
Resume-MoveRequest <kimlik>

New-MoveRequest belgesi (BadItemLimit) 10 veya daha düşük bir değeri önerir. Bozuk öğe fazlaysa önce kaynak kutuda New-MailboxRepairRequest ile onarımı denemeyi, ardından taşımayı yeniden denemeyi tavsiye eder. Belgede bu parametrenin yalnızca şirket içi Exchange'de bulunduğu da belirtilir; yani komutu şirket içi Exchange Yönetim Kabuğu'ndan ya da ilgili isteği oluşturduğunuz tarafta çalıştırın.

Veri kaybı uyarısı: Sınırı yükseltmek, bozuk öğelerin hedefe kopyalanmadan atlanması demektir. Microsoft bunun küçük bir veri kaybına yol açabileceğini açıkça yazar. Hukuk, finans ya da yönetim kutularında önce onarımı deneyin, kullanıcıya yazılı bilgi verin, mümkünse kaynak kutunun PST yedeğini alın.

Büyük öğeler

Büyük öğe, hedef kutunun izin verdiği azami ileti boyutunu aşan iletidir. Belgeye göre LargeItemLimit varsayılan olarak 0'dır ve 10 veya altı önerilir. Kullanıcıya sorun yaşatmamak için büyük ekli iletileri taşıma öncesi arşivlemek ya da ileti boyutu sınırını gözden geçirmek daha temizdir.

Çözüm 4: Eski taşıma kaydı, alan adı ve kimlik eşleşmesi

Microsoft rehberi, taşımanın başlamaması için üç tuzak daha sayar:

1. Eski taşıma kaydı. Başarılı bile olsa önceki bir kayıt yeni taşımayı engelleyebilir. Exchange Online PowerShell'de Get-MoveRequest -Identity 'kullanici@sirket.com' ile bakın; tamamlanmış ya da başarısız kayıt varsa Remove-MoveRequest -Identity 'kullanici@sirket.com' ile silin.
2. Eksik alan adı. Kullanıcının tüm e-posta adreslerinin alan adları Exchange Online'da tanımlı ve doğrulanmış olmalıdır. Karşılaştırmak için şirket içinde (Get-Mailbox Ali).EmailAddresses, bulutta Get-AcceptedDomain çalıştırın. Eksik alan adı varsa ekleyip doğrulayın; ya da Microsoft'un önerdiği gibi kullanıcıyı taşımadan önce lisanslayın.
3. Eşleşmeyen posta kutusu kimliği. Şirket içi ve bulut hesaplarında ExchangeGuid değeri aynı olmalıdır. Get-RemoteMailbox -Identity "Takma ad" | fl ExchangeGuid ve bulutta Get-Mailbox -Identity "Takma ad" | fl ExchangeGuid çıktılarını karşılaştırın.

Türkiye'ye özgü tuzak: Eski Active Directory kurulumlarında kullanıcıların e-posta adreslerinden biri .local gibi internette yönlendirilemeyen bir alan adı taşıyabilir. Microsoft, bu tür adreslerin buluta eklenemeyeceğini ve bu yüzden kullanıcı lisanslanarak taşımanın denenebileceğini belirtir. Sahada ayrıca kullanıcı adlarında ve takma adlarda Türkçe karakter bulunan hesaplara taşıma öncesi ayrıca bakmanızı öneririz; bu Microsoft belgesinde geçen bir madde değil, saha deneyimimizdir.

Çözüm 5: Yönetim merkezi yerine PowerShell, ve yalnızca ana kutuyu taşıma

Microsoft, taşımayı önce Exchange yönetim merkezinden denemenizi ve olmazsa PowerShell'e geçmenizi önerir; PowerShell çoğu zaman daha anlaşılır bir hata mesajı verir. Yönetim merkezi yolu şöyledir: Migration bölümünden Migrate to Exchange Online seçilir, geçiş türü olarak Remote move migration işaretlenir, şirket içi yönetici kimlik bilgileri alan\kullanıcı biçiminde girilir (örneğin sirket\yonetici, e-posta biçiminde değil) ve gösterilen uç noktanın MRS Proxy açık sunucu olduğu doğrulanır. Takılırsanız önce eski "Exchange remote move" uç noktasını silip yeniden oluşturun.

Kullanıcının kişisel arşiv kutusu bulutta, ana kutusu şirket içindeyse yönetim merkezi You must specify the PrimaryOnly parameter hatası verir; çünkü yalnızca ana kutuyu taşıma seçeneği orada yoktur. Çözüm PowerShell'dir:

Connect-ExchangeOnline
$cred = Get-Credential   # sirket\yonetici biçiminde
New-MoveRequest -Identity <kutu> -Remote -RemoteHostName <MRS Proxy adresi> -RemoteCredential $cred -BatchName <parti adi> -PrimaryOnly -TargetDeliveryDomain <sirket>.mail.onmicrosoft.com

Taşımayı kendi ekibiniz yürütürken arada bir ikinci göz isterseniz Microsoft 365 ve Exchange ekibimizle 15 dakikalık ücretsiz teknik görüşme yapabilirsiniz.

Çözüm 6: Takılan ve sürekli bekleyen taşımalar

Taşıma parti halinde yapılıyorsa ve "Completing" aşamasında takılıyorsa Microsoft şu sırayı önerir: otomatik askıya alınmış istekleri sürdürün, tamamlanmış istekleri temizleyin, sonra eski partiyi silin.

Get-MoveRequest | ? {$_.Status -eq "AutoSuspended"} | Resume-MoveRequest
# Tamamlanmaları için süre tanıyın, sonra:
Get-MoveRequest | ? {$_.Status -eq "Completed"} | Remove-MoveRequest
Remove-MigrationBatch "Parti Adı" -Force

Taşıma raporunda StalledDueToTarget_Processor ile "The data export was cancelled due to a timeout" görüyorsanız ve sunucunuz Exchange 2013 ise Microsoft'un çözümü MSExchangeMailboxReplication.exe.config dosyasında DataImportTimeout değerini 20 yapmak, Microsoft Exchange Mailbox Replication servisini yeniden başlatmak ve bunu tüm istemci erişim sunucularında uygulamaktır. Microsoft, taşımaların normale dönmesi için dört saate kadar beklemeyi önerir. Exchange 2016 ve sonrasında bu belge uygulanmaz; önce sunucu sürümünüzü doğrulayın.

Ağ tarafında da bir ipucu: Microsoft, saldırı tespit işlevinin ağ gecikmesi yaratarak taşıma hızını ciddi biçimde düşürebileceğini belirtir. Çok büyük kutular için taşımayı akşam ve hafta sonu saatlerine yayın.

Yönetici için hazırlık listesi (taşımadan önce)

• MRS Proxy ve WSSecurityAuthentication tüm dışa açık sunucularda True.
• Güvenlik duvarında dört taşıma yolu ön kimlik doğrulamasız ve Microsoft 365 IP aralıkları izinli.
• Her kullanıcının tüm e-posta alan adları Exchange Online'da doğrulanmış (özellikle .local adresleri kontrol edildi).
• Şirket içi ve bulut ExchangeGuid değerleri eşleşiyor.
• Eski Get-MoveRequest kayıtları temizlendi.
• Hedef kutuya taşınacak büyük ekli iletiler için ileti boyutu sınırı gözden geçirildi.
• Önce 5 ila 10 kullanıcılık pilot grup taşındı; hatalar bu grupta toplandı.
• Toplu e-posta saklama gereksinimleri (VUK 253 ve 10 yıl saklama, KVKK kapsamında silme talepleri) taşıma sonrası da korunacak şekilde planlandı.

Türkiye'de e-posta, ticari defter ve belge saklama yükümlülüğü kapsamında değerlendirilebilir. Taşıma sırasında bozuk öğe sınırını yükseltmek bu verinin sessizce atlanması demektir. Bu yüzden atlanan öğelerin listesini mutlaka kayda alın ve saklama sorumlusuna bildirin.

Microsoft desteğine gitmeden önce hazırlanacaklar

Destek talebi açarken şu dosyalar süreci kısaltır: taşıma raporu (Get-MoveRequestStatistics -IncludeReport çıktısı), tam hata mesajı, hata saati, şirket içi sunucunun sürümü ve toplu güncelleme düzeyi, güvenlik duvarı cihazının modeli ve kural listesi. Microsoft, posta kutusu taşıma sorunları için ayrıca otomatik bir Microsoft 365 Posta Kutusu Taşıma sorun giderme aracı sunduğunu belirtir; belgede bu aracın yalnızca eski bir tarayıcıda desteklendiği yazıyor, bu yüzden yeni ortamlarda komut satırı çıktısına güvenmek daha pratiktir.

Benzer hatalar ve farkları

• Cutover, kademeli (staged) ya da IMAP taşıma hataları: Microsoft'un hybrid rehberi bu türleri kapsamaz. IMAP ile hosting e-postasından taşıyorsanız cPanel e-postasını Microsoft 365'e taşıma rehberimize, Google Workspace'ten geliyorsanız 21 günlük geçiş planına bakın.
• Taşıma sonrası gönderim hataları: Taşıdıktan sonra bir uygulamanız e-posta atamıyorsa SMTP kimlik doğrulama 535 5.7.139 hatası yazımızı okuyun.
• Kimlik ve koşullu erişim engelleri: Taşıma sonrası kullanıcılar oturum açamıyorsa sebep çoğunlukla kimlik ve erişim ilkeleridir, taşımanın kendisi değil.

Sıkça Sorulan Sorular (SSS)

Exchange hybrid posta kutusu taşıma neden "403 Forbidden" hatası veriyor?

Microsoft'a göre hybrid sunucudaki EWS sanal dizininde MRS Proxy servisi kapalıdır ya da arayüzde açık görünse bile fiilen kapalıdır. MRSProxyEnabled değerini kontrol edin, gerekirse kapatıp açın ve IIS'i yeniden başlatın.

TooManyBadItemsPermanentException hatasında ne yapmalıyım?

Önce taşıma raporundan bozuk öğe sayısını okuyun, sonra BadItemLimit değerini bu sayıya göre yükseltip isteği sürdürün. Microsoft 10 veya altını önerir. Sınırı yükseltmek bozuk öğelerin atlanması demektir, bu yüzden önce kutu onarımını deneyin.

Exchange yönetim merkezinde "You must specify the PrimaryOnly parameter" hatası neden çıkıyor?

Yönetim merkezi yalnızca ana posta kutusunu taşıma seçeneği sunmuyor. New-MoveRequest komutunu PrimaryOnly anahtarıyla PowerShell'den çalıştırmanız gerekir.

Posta kutusu taşıma ne kadar sürer, ne zaman müdahale etmeliyim?

Süre kutu boyutuna ve internet bağlantısına bağlıdır. Microsoft taşıma istekleri için düşük öncelik uygulandığını belirtir ve yaklaşık 8 saat boyunca hiç ilerleme yoksa sorun gidermeye başlamayı önerir.

Taşıma başlarken kullanıcıyı lisanslamak gerekir mi?

Kullanıcının bir adresi .local gibi internette yönlendirilemeyen alan adı taşıyorsa Microsoft taşımadan önce kullanıcıyı lisanslamayı önerir. Diğer durumlarda alan adlarının Exchange Online'da doğrulanmış olması gerekir.

Exchange 2016 ve 2019 için hangi tarihe kadar taşımayı bitirmeliyim?

Destek 14 Ekim 2025'te bitti. Ücretli güvenlik güncelleştirmesi programının son dönemi Ekim 2026 sonunda kapanıyor. Detayları destek sonu rehberimizde bulabilirsiniz.

Xen Bilişim taşıma hatalarında nasıl destek veriyor?

Hata çıktısını ve taşıma raporunu aldıktan sonra genellikle 1 iş günü içinde ilk tanıyı veriyor, gerekirse taşımayı sizin adınıza yürütüyoruz. İletişim sayfamızdan ücretsiz teşhis isteyebilirsiniz.

Sonuç: Önce bağlantıyı, sonra veriyi eleyin

Hybrid taşıma hatalarının çoğu iki katmanda çözülür. Taşıma hiç başlamıyorsa MRS Proxy, güvenlik duvarı, alan adı ve kimlik eşleşmesi gibi bağlantı katmanına bakın. Başlayıp yarıda kalıyorsa bozuk ya da büyük öğe, zaman aşımı ve eski kayıt gibi veri katmanına bakın. Microsoft'un resmi belgeleri bu sırayı önerir ve komutların çoğu tek satırdır.

Sınırı yükseltmek hızlı çözümdür ama atlanan öğe demektir. Türkiye'de e-posta saklama yükümlülükleri ve KVKK düşünüldüğünde, atlanan öğeleri kayıt altına almak ve hassas kutularda önce onarım denemek doğru yoldur. Exchange 2016 ve 2019 için süre Ekim sonunda bittiğinden, taşımayı pilot grupla bugün başlatmak en güvenli seçenektir. Hizmet ve çözüm sayfamızdan Exchange Online geçiş paketlerini görebilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Exchange Online geçiş yolculuğunda hata teşhisinden taşımanın tamamlanmasına kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın veya WhatsApp'tan yazın.