Exchange Hybrid Migration’da MRSProxy 401 Hatası: Tespit ve Geçici Çözüm Adımları

On-premises Exchange Server’dan Exchange Online’a gerçekleştirilen posta kutusu taşımalarında görülen MRSProxy 401 / CommunicationErrorTransientException hatası, migration işlemlerinin tamamlanmasını engelleyebiliyor.

Ekim 2026’da bildirilen sorunlar, Exchange Server üzerindeki yerel Administrator hesabını yeniden adlandırdıktan sonra migration işlemlerinin çalışmaya başladığını belirtiyor. Ancak bu yöntem, Microsoft’un yayımladığı genel bir çözüm değil; belirli belirtilerle eşleşen ortamlarda sonuç verdiği bildirilen bir workaround. İncelenen kaynaklarda bu olay için doğrulanmış bir kök neden veya resmî düzeltme bulunmuyor.

Önce hata senaryosunu doğrulayın

Her HTTP 401 hatası aynı nedenden kaynaklanmaz. Hesap adı değişikliğini değerlendirmeden önce, başarısız migration denemesinin zamanını Exchange Server üzerindeki Security ve IIS loglarıyla eşleştirin.

Haberdeki olayda aşağıdaki belirtiler birlikte görülüyor:

• Test-MigrationServerAvailability testi başarılı oluyor.
• Gerçek taşıma işlemi, “Connected to target mailbox” mesajının ardından duruyor.
• IIS loglarında /EWS/mrsproxy.svc isteği için 401 1 2148074252 görülüyor.
• Security loglarında Event ID 4625, Administrator hesap adı, boş Account Domain, NTLM ve 0xC000006A bilgileri yer alıyor.

Bu eşleşme, bildirilen sorunla benzerliği gösterir; tek başına kök nedeni kanıtlamaz.

Exchange Server üzerinde son iki saatteki başarısız oturum açma olaylarını görüntülemek için yönetici yetkili PowerShell’de şu sorgu kullanılabilir:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated, Message | Format-List

Çıktıda özellikle migration denemesiyle aynı zamana denk gelen olayları inceleyin. Sunucudaki bütün 4625 olaylarını bu migration problemine bağlamayın.

MRSProxy yapılandırmasını kontrol edin

Temel yapılandırmayı doğrulamak için on-premises Exchange Management Shell üzerinde aşağıdaki komutu çalıştırın:

Get-WebServicesVirtualDirectory |
    Format-List Identity, MRSProxyEnabled,
                WindowsAuthentication,
                InternalAuthenticationMethods,
                ExternalAuthenticationMethods

Microsoft, remote move işlemleri için ilgili EWS virtual directory üzerinde MRSProxy etkin olmalı. Exchange Online ayrıca MRSProxy endpoint için Windows Authentication gerektiriyor. Birden fazla Exchange sunucusu bulunan ortamlarda ilgili sunucuların yapılandırması birlikte kontrol edilmeli.

MRSProxy kapalıysa, aşağıdaki örnekteki sunucu adını ortamınıza göre değiştirerek etkinleştirebilirsiniz:

Set-WebServicesVirtualDirectory `
    -Identity "EXCH01\EWS (Default Web Site)" `
    -MRSProxyEnabled $true

MRSProxy zaten etkinse, bu komutu tekrar çalıştırmak kimlik doğrulama sorununu çözmüş sayılmaz. Aynı şekilde, 401 hatasına bakarak doğrudan Basic Authentication açmak veya IIS ayarlarını topluca değiştirmek yerine mevcut kimlik doğrulama yapılandırmasını incelemek gerekir. Microsoft’un hybrid migration troubleshooting rehberi, EWS üzerindeki Windows Authentication ve Negotiate/NTLM davranışının kontrolünü açıklıyor.

Belirtiler eşleşiyorsa yerel Administrator hesabını yeniden adlandırmayı değerlendirin

Microsoft Q&A üzerindeki kullanıcı bildirimlerinde, Exchange Server’ın yerel Administrator hesabını yeniden adlandırmanın başarısız migration işlemlerini düzelttiği belirtiliyor. Burada söz konusu hesap Exchange sunucusunun yerel hesabıdır; Active Directory’deki domain Administrator hesabı değildir.

Değişiklik öncesinde bu hesap adını kullanan scheduled task, servis, yedekleme yazılımı veya yönetim betiği olup olmadığını kontrol edin. LAPS ve hesap yeniden adlandırma politikalarının da değişiklikle uyumlu olması gerekir. İşlemi, erişimi doğrulanmış başka bir yönetici hesabıyla gerçekleştirin.

Yönetici yetkili 64-bit Windows PowerShell açın ve yerel built-in Administrator hesabını SID sonundaki -500 üzerinden belirleyin:

$LocalAdmin = Get-LocalUser |
    Where-Object { $_.SID.Value -match '-500$' }

$LocalAdmin | Select-Object Name, Enabled, SID

Get-LocalUser, yerel hesapları görüntüler; SID kullanılması hesabın mevcut adından bağımsız olarak belirlenmesini sağlar.

Çıktıyı doğruladıktan sonra mevcut adı geri dönüş için kaydedin. Aşağıdaki örnekte EXCH-LocalAdmin, kurumunuzun politikasına uygun ve sunucuda mevcut olmayan yeni hesap adıyla değiştirilmelidir:

$OldName = $LocalAdmin.Name
$NewName = "EXCH-LocalAdmin"

# Önizleme: değişiklik yapmaz
Rename-LocalUser -SID $LocalAdmin.SID -NewName $NewName -WhatIf

Önizlemede doğru hesabın seçildiğini doğruladıktan sonra değişikliği uygulayın:

Rename-LocalUser -SID $LocalAdmin.SID -NewName $NewName

# Yeni adı kontrol edin
Get-LocalUser -SID $LocalAdmin.SID |
    Select-Object Name, Enabled, SID

Rename-LocalUser, Microsoft’un yerel hesap yeniden adlandırma cmdlet’idir. Cmdlet’in resmi olması, bu migration workaround’unun Microsoft tarafından onaylandığı anlamına gelmez.

Tek bir posta kutusuyla sonucu doğrulayın

Hesap adını değiştirdikten sonra önce tek bir başarısız posta kutusu taşımasını mevcut migration yönetim ekranından yeniden deneyin.

Kontrol edilmesi gereken sonuçlar şunlardır:

• Taşıma işlemi önceki hata noktasını geçiyor mu?
• Veri aktarımı ilerliyor mu?
• Aynı zaman aralığında Administrator hesabıyla ilişkili 4625 olayları tekrarlanıyor mu?
• Migration raporunda aynı 401 ve CommunicationErrorTransientException hataları devam ediyor mu?

Başarı ölçütü yalnızca bağlantı testinin geçmesi değildir; gerçek posta kutusu taşımasının ilerlemesi ve tamamlanmasıdır.

Geri dönüş gerekirse aynı PowerShell oturumunda, eski adın başka bir hesap tarafından kullanılmadığını doğrulayarak şu komutu çalıştırabilirsiniz:

Rename-LocalUser -SID $LocalAdmin.SID -NewName $OldName

Oturum kapatılmışsa $OldName değişkeni korunmaz; bu nedenle eski hesap adını değişiklik öncesinde ayrıca kaydedin.

Sorun devam ederse Microsoft Support’a hangi bilgiler iletilmeli?

Belirtiler eşleşmesine rağmen workaround sonuç vermiyorsa, migration raporu ile aynı zaman aralığındaki IIS ve Security kayıtlarını birlikte toplayın. Support case içerisinde Exchange sürümü ve build bilgisi, Classic/Modern Hybrid topolojisi, Hybrid Agent kullanımı, endpoint hesap adı biçimi ve denemenin UTC zamanı bulunmalı.

Yerel Administrator hesabını yeniden adlandırmanın sonucu da kayda eklenmeli. Böylece destek incelemesi, genel bir “401 hatası” bildiriminden ziyade yeniden üretilebilir bir senaryoya dayanır.

Bu olay için uygulanabilir yaklaşım; önce log eşleşmesini doğrulamak, temel MRSProxy ayarlarını kontrol etmek ve yalnızca belirtiler örtüşüyorsa bildirilen hesap yeniden adlandırma workaround’unu kontrollü biçimde denemektir. Bütün MRSProxy 401 hataları için tek bir çözüm olduğu varsayılmamalıdır.