Merhaba

13 Ekim 2026 Patch Tuesday ile yayımlanan Windows Server kümülatif güncellemeleri, bazı şirket içi (on-premises) Exchange sunucularında genellikle kurulumdan yaklaşık bir gün sonra ortaya çıkan kesintilere yol açıyor. Microsoft sorunu doğruladı ve bunun Ekim 2026 Exchange Security Update (SU, Güvenlik Güncellemesi) paketlerinden değil, Windows Server güncellemelerinden kaynaklandığını açıkça belirtti. Etkilenebilen sürümler Exchange Server 2016, Exchange Server 2019 ve Exchange Server SE (Subscription Edition, Abonelik Sürümü). Bu yazıda sorunun nedenini, Microsoft’un önerdiği geçici çözümü ve bu çözümün sunucuda gerçekten etkin olup olmadığını gösteren, codekunst systems GmbH tarafından ücretsiz yayımlanan ExRpcWatch izleme betiğini ele alıyoruz. Bilgileri Microsoft Exchange Team Blog yazısı ve birden fazla bağımsız kaynakla karşılaştırdım; neyin Microsoft’tan, neyin üçüncü taraf analizlerinden geldiğini metin içinde ayırdım.

Ne oldu?

Microsoft, Exchange Team Blog yazısında Ekim 2026 Windows Server güncellemelerinin Exchange’i belirli bir süre sonra kararsızlaştırabildiğini doğruladı. Sorunla ilişkilendirilen dört güncelleme aşağıdaki tabloda yer alıyor. Microsoft, bu güncellemelerin kaldırılmamasını açıkça öneriyor ve Ekim güncellemelerinin önemli bir güvenlik yükü taşıdığını, yalnızca Exchange uyumluluğu sorunu nedeniyle ertelenmemesi gerektiğini belirtiyor. Etkinin her sunucuda aynı olmadığını, şiddetin ve ortaya çıkma hızının Exchange sunucusunun yüküne göre değiştiğini, hatta bazı sunucularda hiç sorun görülmeyebileceğini de ekliyor.

KB numaraları Microsoft’un Exchange Team Blog yazısından, derleme numaraları ise it-connect’in aktardığı değerlerden alınmıştır. Kendi sunucunuzda hangi güncellemenin kurulu olduğunu Get-HotFix komutuyla kontrol edebilirsiniz.

Kök neden: Endpoint Mapper’da 512 sınırı

Microsoft’un Windows release health notuna göre Ekim 2026 güncellemesi, Endpoint Mapper bileşeninin Endpoint Lookup çağrılarını işlerken kullandığı bellek için varsayılan bir sınır getirdi. Bu sınır 512 eş zamanlı Endpoint Lookup çağrısına karşılık geliyor ve Exchange gibi iş yüklerinde yoğun yük altında yetersiz kalabiliyor. Endpoint Mapper, Windows hizmetlerinin RPC (Remote Procedure Call, Uzak Yordam Çağrısı) bağlantılarını kurmasına yardımcı olan bileşendir. Basında yer alan aktarımlara göre Exchange bu bağlamları yük altında biriktirmeye devam ediyor.

Microsoft’un Exchange ekibi yazısı, kayıt defteri değerinin altta tam olarak ne yaptığına dair teknik bir açıklama içermiyor. Bu boşluğu topluluk analizleri dolduruyor. Born’un IT ve Windows Blogu’na yorum bırakan okur Denis Grebner’ın analizine göre güncellenen RpcEpMap.dll (DLL: Dynamic Link Library, Dinamik Bağlantı Kitaplığı) dosyasına, saklanan Endpoint Mapper arama bağlamları için 512 değerinde sert bir sınır eklenmiş. Sayaç bu değeri aşınca yeni hata bloğu devreye giriyor ve Exchange’te gözlenen hatalar ortaya çıkıyor. codekunst systems ise Exchange’in bu bağlamları ilgili süreç sonlanana kadar serbest bırakmadığını ve sınır aşıldığında yeni RPC bağlantılarının reddedildiğini aktarıyor. Bunlar üçüncü taraf gözlemleridir, Microsoft tarafından doğrulanmış teknik ayrıntı olarak okunmamalıdır.

Ölçümler sınırın ne kadar çabuk dolduğunu gösteriyor. Grebner saatte yaklaşık 23,7 yeni bağlam ölçmüş, Born’a bildirim gönderen Uwe Deeg’in izlediği sunucuda ise saatte yaklaşık 18 bağlam oluşmuş. codekunst’un kendi izlediği bir Exchange SE sunucusunda bu değer saatte 24 olmuş. Bu hızlarla 512’lik sınır kabaca bir günde doluyor ve kullanıcıların güncellemeden bir gün sonra yaşadığı kesintinin nedeni bu. Hız sunucuya ve iş yüküne göre değişebilir, dolayısıyla bu rakamlar her ortam için kesin bir kesinti süresi anlamına gelmez.

Aynı Patch Tuesday’de RPC Endpoint Mapper Service içindeki bir hizmet engelleme (Denial of Service, DoS) açığı için CVE (Common Vulnerabilities and Exposures) kaydı CVE-2026-96300 yayımlandı. Açık kontrolsüz kaynak tüketimi türünde ve CVSS (Common Vulnerability Scoring System) puanı 5.9 (orta). Yeni sınırın bu açığın kapatılmasıyla ilgili olması makul görünüyor, ancak Microsoft bu bağı açıkça kurmuş değil; it-connect bunu yalnızca olası bir ipucu olarak anıyor. Bu nedenle kayıt defteri değerini gereğinden fazla yükseltmek bu korumayı zayıflatabilir. Topluluk kaynaklarından biri çok yüksek değerlerin (16777215 gibi) korumayı etkisizleştirdiğini belirtiyor. Microsoft’un önerdiği değer 65536’dır ve Microsoft bu değerin yetmediği bir vakayı şimdiye kadar görmediğini söylüyor.

Belirtiler ve nereye bakmalı

Microsoft’un listelediği belirtiler aşağıdaki tabloda özetlenmiştir. Olay kaydı arıyorsak Application log (Uygulama günlüğü) içinde Event ID (Olay Kimliği) 1006 kaydına bakıyoruz.

Sorun anlık değil. Birçok yönetici kesintiyi güncellemeden yaklaşık 24 saat sonra yaşadı ve Microsoft’un da belirttiği gibi sunucunun yeniden başlatılması sorunu geçici olarak çözüyor. Bu yüzden güncellemeden sonraki ilk günün sorunsuz geçmesi, sunucunun etkilenmediği anlamına gelmez. Olay kaydını ve bağlantıyı elle kontrol etmek için aşağıdaki komutları Exchange Management Shell içinde kullanabiliriz.

Get-WinEvent -FilterHashtable @{ LogName='Application'; Id=1006; StartTime=(Get-Date).AddDays(-1); ProviderName='MSExchange Mailbox Replication' }
Test-MAPIConnectivity -Server $env:COMPUTERNAME
Get-Queue -Server $env:COMPUTERNAME | Measure-Object MessageCount -Sum

Microsoft’un önerdiği geçici çözüm

Öncelikle Windows güncellemelerini kaldırmıyoruz. Etkilenen Exchange sunucusunda Command Prompt (Komut İstemi) uygulamasına sağ tıklayıp Run as administrator (Yönetici olarak çalıştır) seçeneğiyle açıyoruz ve aşağıdaki komutu çalıştırıyoruz.

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Komut, HKLM\SOFTWARE\Microsoft\Rpc anahtarı altında EpmapSavedContextCap adlı REG_DWORD (DWORD: Double Word, 32 bit tamsayı) değerini 65536 olarak oluşturuyor ya da üzerine yazıyor. /f parametresi onay istemeden üzerine yazılmasını sağlıyor. Ardından sunucuyu yeniden başlatıyoruz. DAG üyesi bir sunucuysa her zamanki bakım prosedürümüzü izleyerek sunucuyu önce bakım moduna alıyoruz ve sunucuları sırayla, birer birer yeniden başlatıyoruz. Yeniden başlattıktan sonra ortamı izliyoruz ve sorunun tekrar edip etmediğini kontrol ediyoruz. Değerin yazıldığını da şu komutla doğrulayabiliriz.

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc' -Name EpmapSavedContextCap | Select-Object EpmapSavedContextCap

Microsoft’un 20 Ekim 2026’da yazıya eklediği SSS bölümü üç önemli noktayı netleştiriyor. Birincisi, Windows güncellemelerini kaldırmak ya da bir sonraki ayı beklemek yerine mevcut güncellemeleri en kısa sürede kurmamız ve bu öneriyi uygulamamız isteniyor. İkincisi, kayıt defteri değeri güncellemeden önce de oluşturulabiliyor, çünkü anahtar yalnızca Ekim 2026 Windows Server güncellemeleri kurulduktan sonra okunuyor ve güncelleme sırasında korunuyor. Üçüncüsü, Windows ya da Exchange tarafından yakın zamanda yeni bir sürüm beklenmiyor; iki ekip de konuyu uzun vadeli inceliyor ve beklememiz önerilmiyor.

Değer yazıldı ama etkin değil: yeniden başlatma şart

İzleme betiğinin çıkış nedeni tam olarak bu. Kayıt defteri değerinin yazılmış olması, sunucunun korunduğu anlamına gelmiyor, çünkü Endpoint Mapper değeri yalnızca sistem açılışında okuyor. codekunst’un izlediği bir müşteri sunucusunda değer doğru biçimde 65536 olarak girilmişti, ancak sunucu yeniden başlatılmadığı için bellekteki sınır hala 512’ydi ve sayaç 47’ydi. Born’un okurlarından da değeri yazıp yeniden başlatmayı unuttuğunu bildirenler var. Yalnızca Exchange hizmetlerini yeniden başlatmak da yetmiyor: bu işlem sayacı düşürebilir, ancak sınır 512 olarak kalır. Yöneticilerin bu yöntemle ilgili deneyimleri de karışık.

ExRpcWatch izleme betiği

Betik codekunst systems GmbH tarafından ücretsiz yayımlanıyor ve Born’un blogunda okur Uwe Deeg aracılığıyla duyuruldu. ÇözümPark da konuyu 22 Ekim 2026’da haber olarak aktardı. Windows Server 2025’te Denis Grebner’ın belirttiği bellek konumlarına dayanarak Endpoint Mapper’ın sınır ve sayaç değerlerini salt okunur biçimde okuyor. Windows Server 2022 için bellek adresleri okurların katkısıyla 21 Ekim 2026’da eklendi. ÇözümPark haberinde yalnızca Windows Server 2025 geçtiği için bu güncelleme önemli: betik artık iki sürümü destekliyor. Betik her çalışmasında şunları yapıyor:

• MAPI (Messaging Application Programming Interface) bağlantısını Test-MAPIConnectivity ile, ileti kuyruklarının toplamını ve Event ID 1006 (MdbOffline) kayıtlarını son 15 dakika için denetliyor.
• Windows Server 2025 ve 2022’de Endpoint Mapper sınırını ve sayacını okuyor.
• Değer kayıt defterinde var ama bellekte hala 512 geçerliyse, yani yeniden başlatma bekleniyorsa, Application log’a 9002 numaralı uyarıyı yazıyor.
• Sayaç sınırın yüzde 90’ına ulaşınca uyarı e-postası gönderiyor. Bu e-posta kesintiden önce geliyor. E-posta Exchange’in Pickup dizinine bırakılıyor, bu yüzden relay connector ya da parola gerekmiyor. Her uyarı türü için en fazla 12 saatte bir e-posta gidiyor.
• Her çalışmayı CSV (Comma-Separated Values) dosyasına yazıyor. Sayaç eşiğe ulaştığında, MAPI testi başarısız olduğunda ya da MdbOffline görüldüğünde 9001 numaralı hata olayını Application log’a ekliyor.

Betiğin hangi sunucuda ne yapabildiği, Windows’taki RpcEpMap.dll dosyasının tam sürümüne bağlı. Bellek adresleri yalnızca bilinen sürümler için tanımlı.

Dosya özelliklerinde Windows, RpcEpMap.dll için çoğu zaman 10.0.20348.1 gibi eski bir sürüm gösterebiliyor. Geçerli olan, betiğin başlangıçta gösterdiği gerçek revizyondur.

codekunst, kendi izlediği bir Exchange SE sunucusunda betiğin iki gün boyunca tuttuğu kaydı paylaşıyor. Ölçümde kayıt defteri değeri girilmişti ama henüz etkin değildi. Sayaç her 30 dakikalık aralıkta tam 12 arttı, yani saatte 24. Bu artış akşam saatlerinde de gece 03:00’te de aynıydı. codekunst bundan, bağlamların kullanıcı yükünden değil düzenli bir iç işlemden doğduğu sonucunu çıkarıyor. Bu tek bir sunucunun gözlemidir.

Kurulum adımları

Önce codekunst systems sayfasının sonundaki kodun tamamını kopyalayıp Exchange sunucusunda C:\Temp gibi bir klasöre Install-ExRpcWatch.ps1 adıyla kaydediyoruz. Betik, karakter kodlamasından bağımsız çalışsın diye yalnızca ASCII (American Standard Code for Information Interchange) karakterler içeriyor. Kodu çalıştırmadan önce satır satır inceliyoruz, çünkü bu betik SYSTEM hesabıyla her 15 dakikada bir çalışan bir görev oluşturuyor. Ardından Windows PowerShell 5.1’i (powershell.exe, PowerShell 7 olan pwsh.exe değil, çünkü Exchange yönetim komutları yalnızca 5.1’de bulunuyor) Run as administrator seçeneğiyle açıyoruz ve şu komutları çalıştırıyoruz.

cd C:\Temp
Unblock-File .\Install-ExRpcWatch.ps1
powershell -ExecutionPolicy Bypass -File .\Install-ExRpcWatch.ps1

Yükleyici yönetici yetkisini, PowerShell sürümünü ve Exchange yönetim ortamını denetliyor, sunucu adını okuyor ve uyarı e-postası için hedef adresi soruyor. İsteğe bağlı olarak kayıt defteri değerini Microsoft’un önerdiği 65536 ile kendisi yazmayı da öneriyor, ancak bunu yalnızca açık onayımızla yapıyor. Son olarak güncel durumu gösteriyor ve istersek test e-postası gönderiyor.

Kurulum şunları oluşturuyor: C:\Scripts\ExRpcWatch klasörü (içinde ExRpcWatch.ps1, config.json, ExRpcWatch.csv ve ExRpcWatch.log; son ikisi 5 MB’ı aşınca ayrılıyor), Task Scheduler (Görev Zamanlayıcı) içinde SYSTEM hesabıyla 15 dakikada bir çalışan, 5 dakikalık zaman sınırı olan ve aynı anda ikinci kez çalışmayan ExRpcWatch adlı zamanlanmış görev (scheduled task) ve Application log içinde ExRpcWatch olay kaynağı. Hedef adres, yol, aralık ve uyarı eşiği parametreyle de verilebiliyor: -MailTo, -InstallPath, -IntervalMinutes ve -ThresholdPercent. Eşik varsayılan olarak yüzde 90.

Durumu görmek, test e-postası göndermek ve betiği kaldırmak için şu komutları kullanıyoruz.

& 'C:\Scripts\ExRpcWatch\ExRpcWatch.ps1' -Status
& 'C:\Scripts\ExRpcWatch\ExRpcWatch.ps1' -TestMail
powershell -ExecutionPolicy Bypass -File .\Install-ExRpcWatch.ps1 -Uninstall

Kaldırma işlemi kayıt defteri değerine dokunmuyor. Değerin ne zaman geri alınacağını Microsoft’un açıklamalarına göre belirliyoruz. Mevcut bir kurulumu güncellemek için yükleyicinin yeni sürümünü yeniden çalıştırmamız yeterli: yapılandırma, betik ve görev değişiyor, günlükler korunuyor.

Çıktıyı yorumlama

Betiğin CSV dosyasındaki sütun adları Almanca kaynaklı. Aşağıdaki tablo bulguları ve yapılacak işlemi özetliyor.

Sonuç ve öneriler

Özetle Microsoft’un önerisi basit ve değişmedi: Windows güncellemelerini kaldırmıyoruz, kayıt defteri değerini yazıyoruz ve sunucuyu yeniden başlatıyoruz. İzleme betiği bu çözümün gerçekten etkin olup olmadığını görmemizi sağlıyor. Pratik öneriler şöyle.

• Ekim 2026 Windows Server güncellemelerini kaldırmıyoruz ve ertelemiyoruz, Microsoft’un önerisini uyguluyoruz.
• Değeri yazdıktan sonra sunucuyu mutlaka yeniden başlatıyoruz. Yalnızca kayıt defterini kontrol etmek yetmiyor, bellekteki sınırı da doğrulamamız gerekiyor.
• Henüz güncellemeyi kurmadığımız sunucularda değeri önceden oluşturabiliyoruz. Microsoft’a göre anahtar, güncelleme kurulana kadar kullanılmıyor.
• İzlemeyi hizmet durumuna değil işleve bağlıyoruz. Exchange hizmetleri çalışırken ve veritabanları EAC (Exchange Admin Center) içinde bağlı görünürken bile kullanıcılar bağlanamayabiliyor. Gerçek bir MAPI testi, kuyruk uzunluğu ve Event ID 1006 kontrolü izlemeye eklenmeli.
• Windows Server 2019 ve 2016 gibi sayacın okunamadığı sürümlerde, kesinti öncesi uyarı olmadığını bilerek planlı yeniden başlatma takvimi oluşturuyoruz.
• Microsoft’un Exchange Team Blog yazısını ve Windows release health sayfasını düzenli takip ediyoruz.