Exchange Server SE SU11 (KB5128895) Kurulumu ve HealthChecker Kontrolü

Merhaba

Microsoft, 13 Ekim 2026 tarihinde Exchange Server Subscription Edition (SE) için Ekim 2026 Security Update (SU, Güvenlik Güncellemesi) paketini yayımladı. Exchange SE tarafında SU11 olarak geçen bu paketin KB (Knowledge Base) numarası KB5128895. HealthChecker.ps1 ile Exchange Server SE sağlık kontrolünü ve HealthChecker ile tespit edilen açıkların kapatılmasını önceki yazılarda anlatmıştım. Bu yazıda aynı akışı SU11 için uyguluyoruz: kuruluma girmeden önce HealthChecker ile mevcut durumu çıkarıyor, ön hazırlık kontrollerini yapıyor, güncellemeyi kuruyor ve açıkların gerçekten kapandığını yine HealthChecker ile doğruluyoruz.

SU11 Neleri Kapatıyor

Önce paketin künyesine bakalım. SU11, yalnızca Exchange SE RTM (Release to Manufacturing) için herkese açık olarak yayımlandı. Exchange 2016 ve 2019 paketleri ise yalnızca Period 2 ESU (Extended Security Update) programına kayıtlı kurumlara sunuluyor. Bu yazı yalnızca Exchange SE tarafını kapsıyor. 2016 ve 2019 tarafının ayrıntıları için SU11 haber yazıma bakabilirsiniz.

SU11, aşağıdaki 6 güvenlik açığını (CVE, Common Vulnerabilities and Exposures) kapatır:

Pakette ayrıca iki işlevsel düzeltme var: yayımlanmış takvim (.ics) bağlantısına erişen takvim uygulamalarına HTTP (Hypertext Transfer Protocol) 500 hatası dönmesi ve eksik Korean WordBreaker rule files nedeniyle oluşan ContentEngine deadlock sorunu.

SU paketleri kümülatiftir. CU (Cumulative Update) seviyeniz paketi destekliyorsa SU10 gibi ara paketleri sırayla kurmanız gerekmez, doğrudan SU11’i kurmanız yeterlidir. Exchange Online ortamı bu açıklara karşı zaten korunuyor. Hybrid yapıda olsanız bile on-premises sunucularda, hatta yalnızca yönetim amacıyla kullanılan sunucularda da SU11’in kurulması gerekiyor.

Ön Hazırlık: HealthChecker.ps1 Scriptini İndirme

HealthChecker scriptini sunucuya daha önce indirdiyseniz bu bölümü atlayıp bir sonraki adımdaki güncelleme komutuyla devam edebilirsiniz. Script henüz sunucuda yoksa Microsoft’un resmi GitHub sürümünden indiriyoruz. Ayrıntılı anlatım için HealthChecker.ps1 ile Exchange Server SE sağlık kontrolü yazıma bakabilirsiniz.

Windows PowerShell‘i Run as administrator (Yönetici olarak çalıştır) açıyoruz ve scriptin duracağı klasörü oluşturuyoruz. Klasör zaten varsa komut mevcut klasöre dokunmaz:

New-Item -Path "C:\Scripts" -ItemType Directory -Force

Ardından scriptin her zaman en güncel sürümünü getiren GitHub bağlantısından dosyayı indiriyoruz:

Invoke-WebRequest -Uri "https://github.com/microsoft/CSS-Exchange/releases/latest/download/HealthChecker.ps1" -OutFile "C:\Scripts\HealthChecker.ps1"

İnternetten indirilen dosyalar Windows tarafından Mark of the Web (MOTW) ile etiketlenebilir. Bu işaret PowerShell’in dosyayı ek uyarıyla göstermesine ya da execution policy nedeniyle çalıştırmayı engellemesine yol açabilir. Dosya Microsoft’un resmi GitHub deposundan geldiği için bu işareti kaldırıyoruz:

Unblock-File -Path "C:\Scripts\HealthChecker.ps1"

İndirmenin (ya da başka makineden kopyalamanın) başarılı olduğunu dosyanın varlığına bakarak doğrulayabiliriz:

Get-Item "C:\Scripts\HealthChecker.ps1" | Select-Object Name,Length,LastWriteTime

HealthChecker.ps1 İndirirken DNS Hatası Alırsanız

Bu yazıdaki sunucuda indirme komutu şu hatayla durdu:

Invoke-WebRequest : The remote name could not be resolved: 'github.com'

Bu hata scriptle değil, DNS (Domain Name System) ile ilgilidir. Sunucu github.com adını bir IP adresine çeviremediği için komut GitHub’a hiç ulaşamadan düşüyor. HealthChecker raporuna göre sunucunun tek DNS sunucusu iç ağdaki 192.168.1.200 ve sunucuda proxy tanımlı değil. Bu nedenle sorunun büyük olasılıkla iç DNS sunucusunun dış adresleri çözememesinden kaynaklandığını düşünüyoruz. Nedeni ayırt etmek için sunucuda şu üç komutu çalıştırıyoruz:

Resolve-DnsName github.com
Test-NetConnection github.com -Port 443
Get-DnsClientServerAddress -AddressFamily IPv4

Sonuçları şöyle yorumluyoruz: Resolve-DnsName hata veriyorsa sunucunun kullandığı DNS dış adresleri çözmüyordur. DNS çözülüyor ama Test-NetConnection başarısız oluyorsa güvenlik duvarı ya da proxy 443 portundaki çıkışı engelliyordur. Proxy kullanıyorsanız netsh winhttp show proxy komutuyla sistem proxy ayarına bakın ve indirme komutuna -Proxy parametresini ekleyin.

DNS sunucusu (bu ortamda domain controller) üzerinde dış adresler için forwarder tanımlı değilse Windows PowerShell‘i Run as administrator (Yönetici olarak çalıştır) açıp önce mevcut forwarder’lara bakıyoruz, ardından internet çıkışını sağlayan bir DNS adresini forwarder olarak ekliyoruz. Aşağıdaki IP adresi bu laboratuvardaki ağ geçidine aittir, kendi ortamınızda internet çıkışını sağlayan DNS adresiyle değiştirin:

Get-DnsServerForwarder
Add-DnsServerForwarder -IPAddress 192.168.1.1

Aynı işlemi DNS Manager (DNS Yöneticisi) konsolunda sunucu adına sağ tıklayıp Properties (Özellikler) > Forwarders (İleticiler) sekmesinden de yapabilirsiniz. Ardından Exchange sunucusunda Resolve-DnsName github.com komutunu tekrar çalıştırıp adın çözüldüğünü doğruluyor ve indirme komutunu yeniden deniyoruz.

DNS tarafını değiştirmek mümkün değilse en pratik yol, scripti internete çıkabilen başka bir makineden indirip sunucuya kopyalamak ve Unblock-File komutunu sunucuda çalıştırmaktır.

Ön Hazırlık: HealthChecker ile Mevcut Durumu Çıkarma

Kuruluma başlamadan önce sunucunun bugünkü fotoğrafını çekiyoruz. Böylece kurulum sonrasında önce ve sonra raporlarını yan yana koyup hangi satırların değiştiğini net görebiliriz. Önce HealthChecker.ps1 scriptinin güncel sürümde olduğundan emin oluyoruz. Scripti az önce indirdiyseniz zaten en güncel sürümdedir, daha önce indirdiyseniz aşağıdaki komut onu günceller. Sunucunun internet erişimi yoksa güncel scripti başka bir makineden indirip sunucuya kopyalayın.

Exchange Management Shell‘i Run as administrator (Yönetici olarak çalıştır) açıyoruz ve scriptin bulunduğu klasörde şu komutu çalıştırıyoruz:

cd C:\Scripts
.\HealthChecker.ps1 -ScriptUpdateOnly

Script güncel olduğundan emin olduktan sonra önce raporunu üretiyoruz. Önce veriyi topluyoruz, ardından HTML (HyperText Markup Language) dönüşümünü yapıyoruz. İki komutu ; ile tek satırda yazarsak veri toplama bittiği anda rapor kendiliğinden oluşur, ikinci komutu elle yazmanız gerekmez:

.\HealthChecker.ps1 -Server "W25EXCSE"; .\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "W25EXCSE-Report-Before.html"

Komut bittiğinde terminalde HealthChecker-W25EXCSE-... adıyla TXT ve XML dosyalarının yazıldığını ve en altta HTML Report Location satırının çıktığını görürüz.

-BuildHtmlServersReport parametresi yeni veri toplamaz, çalışma klasöründeki ...-HealthChecker-*.xml dosyalarını (XML, Extensible Markup Language) okuyup HTML çıktısına dönüştürür. Kurulum sonrasında sonra raporunu aynı klasörde üreteceğimiz için önce aşamasında oluşan XML ve TXT dosyalarını ayrı bir klasöre taşımanızı öneririm. Aksi halde yeni rapora eski veriler de karışabilir.

New-Item -ItemType Directory -Path "C:\Scripts\Before" -Force
Move-Item -Path "C:\Scripts\*HealthChecker*.xml","C:\Scripts\*HealthChecker*.txt" -Destination "C:\Scripts\Before"

Raporu açtığımızda şu satırlara özellikle bakıyoruz: Servers Overview tablosundaki Vulnerability Detected değeri, Server Details bölümündeki Exchange Version ve Build Number satırları, kırmızı Security Vulnerabilities satırı, Server Pending Reboot satırı ve Exchange Server Maintenance durumu. Bu aşamada kırmızı CVE listesini görmemiz normaldir, çünkü SU11 henüz kurulu değil.

Bu yazıda raporun gösterebileceği tüm açıkları görebilmek için sunucuyu bilerek Exchange SE RTM build’i olan 15.02.2562.017 üzerinde bıraktık, yani sunucuda hiçbir SU (Security Update) kurulu değil. Önce raporumuzda Exchange Version satırı Exchange SE RTM, Build Number satırı 15.02.2562.017 olarak görünüyor ve Not on the latest SU uyarısı sarı renkle işaretleniyor. Vulnerability Detected değeri True, Security Vulnerabilities satırı ise kırmızı ve 44 CVE listeliyor. SU11’in kapattığı 6 CVE‘nin tamamı da bu listenin içinde. Listenin sonunda ayrıca Download Domains yapılandırılmadığı için CVE-2021-1730 uyarısı yer alıyor.

SU (Security Update) paketleri kümülatif olduğu için rapordaki CVE sayısı sunucunuzun build’ine göre değişir. Sunucunuzda daha önce SU10 gibi bir güncelleme kurulduysa raporda bu kadar CVE görmezsiniz.

Aşağıdaki tablo, aynı rapor için hangi build’de kaç CVE satırı beklediğimizi gösteriyor:

Ön Hazırlık: Mevcut Sürümü Tespit Etme

HealthChecker raporuna ek olarak hızlı bir kontrol için Exchange Management Shell’de şu komutu kullanabiliriz.  Bu komut CU seviyesini gösterir ancak kurulu SU’yu göstermez:

Exchange Management Shell‘i Run as administrator (Yönetici olarak çalıştır) açıyoruz ve şu komutu çalıştırıyoruz:

Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion

Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}

Bu yazıdaki sunucuda komut 15.02.2562.017 değerini, yani Exchange SE RTM build’ini döndürüyor. Sunucunuzda daha önce SU (Security Update) kurulduysa daha yüksek bir değer görürsünüz (SU10 için 15.02.2562.049, SU10 V2 için 15.02.2562.053 gibi). Bu değeri not alıyoruz, çünkü kurulum sonunda 15.02.2562.056 değerini görmemiz gerekiyor.

Ön Hazırlık: Paketi İndirme ve Doğrulama

SU11 paketini Microsoft Download Center üzerinden ya da KB5128895 destek sayfasından indiriyoruz. İndirme sayfasında birden fazla dil seçeneği bulunuyor. Sunucunuzun Exchange dil paketine uygun olanı, İngilizce kurulumlar için ExchangeSubscriptionEdition-KB5128895-x64-en.exe dosyasını alıyoruz ve C:\ExchangeServerUpdates klasörüne kaydediyoruz.

İndirilen paketin bozulmadığından emin olmak için SHA256 (Secure Hash Algorithm 256) değerini hesaplıyor ve Microsoft’un KB sayfasında yayımladığı değerle karşılaştırıyoruz:

Get-FileHash -Path "C:\ExchangeServerUpdates\ExchangeSubscriptionEdition-KB5128895-x64-en.exe" -Algorithm SHA256

KB sayfasında İngilizce paket için yayımlanan hash değeri şudur:

5EB5A93016841B80F019B128F7354A4459FD48C3B53CF49AAC14CBEA32ABDF9B

Komutun çıktısındaki Hash değeri bununla birebir aynı olmalı. Farklıysa dosyayı yeniden indirin.

Ön Hazırlık: Sunucunun Durumunu Kontrol Etme

Microsoft, güncellemeden önce sunucunun yeniden başlatılmasını öneriyor. Bekleyen bir restart varsa kurulum sırasında beklenmedik hatalarla karşılaşabiliriz. Önce bekleyen restart olup olmadığına bakıyoruz:

Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name PendingFileRenameOperations -ErrorAction SilentlyContinue).PendingFileRenameOperations

İlk iki komut False döndürmeli, üçüncü komut ise boş çıktı vermeli. Herhangi biri bekleyen bir restart gösteriyorsa sunucuyu bakım penceresinde yeniden başlatıp kontrolü tekrarlıyoruz.

Ardından sistem sürücüsündeki boş alanı, Exchange servislerinin durumunu ve kuyruktaki mesajları kontrol ediyoruz:

Get-PSDrive -PSProvider FileSystem | Select-Object Name,@{n="FreeGB";e={[math]::Round($_.Free/1GB,1)}}
Get-Service MSExchange*,W3SVC,WAS | Select-Object Name,Status,StartType

Bu laboratuvarda C: sürücüsünde yaklaşık 89,9 GB boş alan var. D: sürücüsünde 0 GB görünmesi bu sunucuda kuruluma engel değildir, bakmamız gereken sistem sürücüsüdür. Servis listesinde MSExchangeImap4, MSExchangeIMAP4BE, MSExchangePop3 ve MSExchangePOP3BE servisleri Stopped / Manual görünür. Bu Exchange’in varsayılan durumudur, IMAP veya POP kullanmıyorsanız bu servislerin kapalı olması sorun değildir. WAS servisinin Manual olması da normaldir. Dikkat etmemiz gereken tek durum Disabled kalmış bir Exchange servisidir.

Son olarak kuyruktaki mesajlara bakıyoruz. Get-Queue bir Exchange cmdlet’idir, bu yüzden yalnızca Exchange Management Shell‘de çalışır:

Get-Queue

Paket yaklaşık 344,6 MB olsa da kurulum sırasında dosyaların açılması ve güncellenmesi için sistem sürücüsünde rahat bir boş alan bırakmanızı öneririm. Servis listesinde Disabled durumda kalmış bir Exchange servisi olmamalı. Kuyrukta takılı kalmış çok sayıda mesaj varsa bakıma girmeden önce nedenini inceleyin.

Son olarak aşağıdaki kontrol listesini gözden geçirelim:

Yedek konusunda bir hatırlatma yapmak isterim: sanal makine checkpoint’i, Exchange veritabanları için yedek yerine geçmez. Güncelleme öncesinde kurumunuzun yedekleme çözümüyle alınmış güncel bir yedeğin bulunduğundan emin olun.

Bakım Moduna Alma (Maintenance Mode)

Tek sunuculu bir kurulumda trafiği devralacak ikinci bir sunucu yoktur. Bu nedenle bakım penceresi boyunca kullanıcılar posta erişimini kaybeder ve bu durumu önceden duyurmamız gerekir. Sunucuyu bakım moduna almak için şu komutu çalıştırıyoruz:

Set-ServerComponentState W25EXCSE -Component ServerWideOffline -State Inactive -Requester Maintenance

Durumu doğruluyoruz. ServerWideOffline bileşeninin Inactive olarak göründüğünü görmeliyiz:

Get-ServerComponentState W25EXCSE | Format-Table Component,State -AutoSize

Güvenlik Güncellemesini Kurma

Kritik nokta: SU paketini mutlaka Run as administrator (Yönetici olarak çalıştır) ile açılmış bir Command Prompt (Komut İstemi) üzerinden çalıştırın. Pakete çift tıklayarak ya da PowerShell üzerinden çalıştırmak, Exchange servislerinin durdurulamaması nedeniyle kurulumun yarıda kalmasına yol açabilir.

Run (Çalıştır) penceresine cmd yazıyor, Command Prompt (Komut İstemi) üzerine sağ tıklayıp Run as administrator seçeneğini seçiyoruz. Ardından paketin bulunduğu klasöre geçip kurulumu başlatıyoruz:

cd C:\ExchangeServerUpdates
ExchangeSubscriptionEdition-KB5128895-x64-en.exe

Kurulum başladığında komut satırında START: Installation process initiated ve SUCCESS: Extracted contents to… mesajları görünür. Paket içeriği geçici bir klasöre çıkarılır ve Welcome to the Setup Wizard karşılama ekranı açılır. Bu aşamada sihirbaz gerekli disk alanını hesaplar.

Karşılama ekranı hazır olduğunda To start the installation, click Next mesajı görünür. Kuruluma başlamak için Next butonuna tıklıyoruz.

License Terms (Lisans Şartları) ekranında lisans metnini okuyoruz, I accept the License Terms (Lisans şartlarını kabul ediyorum) seçeneğini işaretliyor ve Next ile devam ediyoruz.

Kurulum başlar. İlk aşamada sihirbaz disk alanı gereksinimlerini hesaplar (Status: Computing space requirements). Bu işlem birkaç dakika sürebilir.

Ardından sihirbaz çalışan Exchange servislerini durdurur (Status: Stopping services). Güncellemenin dosyalara müdahale edebilmesi için bu adım gereklidir.

Sonraki aşamada kurulum doğrulanır (Status: Validating install) ve ilerleme çubuğu dolmaya başlar. Dosyalar uygulanırken çubuk neredeyse tamamına ulaşır. Bu, kurulumun en uzun süren kısmıdır, bu nedenle sihirbazı kapatmadan sabırla bekliyoruz.

Kurulum tamamlanmak üzereyken sihirbaz durdurduğu servisleri yeniden başlatır (Status: Starting services).

Setup Wizard … Completed ekranı, güncellemenin başarıyla tamamlandığını gösterir. Sihirbazdan çıkmak için Finish butonuna tıklıyoruz.

Finish butonuna tıkladığımızda Installer Information penceresi açılır. Pencere, Exchange Server’daki yapılandırma değişikliklerinin etkinleşmesi için sistemin yeniden başlatılması gerektiğini söyler ve iki seçenek sunar: Yes ile hemen yeniden başlatabilir, No ile daha sonra elle yeniden başlatabiliriz. Bu laboratuvarda Yes seçeneğini seçiyoruz.

Sunucuyu Yeniden Başlatma ve Servis Kontrolü

Güvenlik güncellemesinin ardından sunucuyu her zaman yeniden başlatıyoruz. Sihirbaz restart istemediği ya da pencerede No seçtiğiniz durumlarda bu adımı atlamamak gerekir. Atlarsak Outlook on the web (OWA) ya da ECP (Exchange Control Panel) üzerinde HTTP 400 gibi oturum açma hatalarıyla karşılaşabiliriz.

Biz yukarıdaki pencerede Yes seçtiğimiz için sunucu kendiliğinden yeniden başladı. No seçtiyseniz ya da sihirbaz restart sormadıysa Windows PowerShell‘i Run as administrator (Yönetici olarak çalıştır) açıp şu komutu çalıştırın:

Restart-Computer

Sunucu yeniden başladıktan sonra Exchange servislerinin düzgün ayağa kalktığını kontrol ediyoruz. Microsoft’un da vurguladığı üzere servislerin Disabled durumda kalması, kurulum sürecinin bir noktada kesintiye uğradığını gösterir:

Get-Service MSExchange* | Where-Object { $_.StartType -eq 'Disabled' }

Bu komut hiçbir şey döndürmemeli. Disabled bir servis listelenirse yazının sonundaki Olası Sorunlar bölümüne bakın.

Bakım Modundan Çıkarma

Sunucu yeniden başladıktan ve servisler doğrulandıktan sonra bakım modundan çıkıp bileşenleri tekrar aktif hale getiriyoruz:

Set-ServerComponentState W25EXCSE -Component ServerWideOffline -State Active -Requester Maintenance
Get-ServerComponentState W25EXCSE | Format-Table Component,State -AutoSize

Çıktıda ServerWideOffline dahil bileşenlerin Active olduğunu görmeliyiz. Sunucu bir DAG üyesiyse bu aşamada veritabanı kopyalarının tekrar Healthy duruma geldiğini de Get-MailboxDatabaseCopyStatus -Server W25EXCSE komutuyla doğrulamamız gerekir.

Güncellemeyi Doğrulama

Şimdi işin en tatmin edici kısmına geldik: açıkların gerçekten kapandığını doğrulamak. Önce build numarasının beklenen sürüme yükseldiğini kontrol ediyoruz:

Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}

Çıktıda 15.02.2562.056 değerini görmeliyiz. Bu değer SU11’in build numarasıdır.

Ardından HealthChecker‘ı yeniden çalıştırıp sonra raporunu üretiyoruz. Exchange Management Shell‘i Run as administrator (Yönetici olarak çalıştır) açıyoruz:

cd C:\Scripts
.\HealthChecker.ps1 -Server "W25EXCSE"; .\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "W25EXCSE-Report-After.html"

Raporu tarayıcıda açtığımızda Exchange Version satırının Exchange SE RTM Oct26SU, Build Number satırının 15.02.2562.056 olduğunu görüyoruz. Exchange IU or Security Hotfix Detected satırının altında Security Update for Exchange Server Subscription Edition (KB5128895) listeleniyor. Önce raporundaki Not on the latest SU ve Known Issue Detected uyarıları kayboldu, kırmızı Security Vulnerabilities satırındaki 44 CVE listesi de gitti. Bazı açıklar SU kurulumunun yanında ek bir manuel işlem gerektirir ve HealthChecker bu durumu aynı satırda ayrıca belirtir.

Get-Mitigations.ps1 scriptini Exchange Management Shell‘i Run as administrator (Yönetici olarak çalıştır) açarak çalıştırabilirsiniz:

cd "C:\Program Files\Microsoft\Exchange Server\V15\Scripts"
.\Get-Mitigations.ps1

Bu laboratuvarda script No Mitigations are applied döndürdü. Raporda PING1 görünmesine rağmen bu sonucun çıkması, PING1 yalnızca heartbeat olduğu için uygulanmış bir mitigation sayılmamasından kaynaklanıyor olabilir. Bu yorumu Microsoft’un dokümanı doğrulamıyor, yalnızca bu ortamda gözlediğimiz sonucu aktarıyoruz.

Ortam genelinde açık kalan olup olmadığını tek komutla görmek için vulnerability raporunu da alabiliriz:

.\HealthChecker.ps1 -VulnerabilityReport

Bu ortamda Download Domains yapılandırılmadığı için sonra raporunda da CVE-2021-1730 uyarısı kalacak ve Vulnerability Detected değeri True olarak görünmeye devam edecek. Bu beklenen bir durumdur, çünkü bu açık SU ile değil, DNS, sertifika ve Set-OrganizationConfig -EnableDownloadDomains yapılandırmasıyla kapanıyor. Raporda artık yalnızca bu uyarının kalması, SU11’in diğer 44 CVE‘yi kapattığını gösterir. Vulnerability Detected değerinin None olmasını istiyorsanız Download Domains yapılandırmasını tamamlamanız gerekir. Bunu yazının ilerleyen bölümünde, SU11 sonrası adım olarak yapıyoruz. Yapılandırma bittikten sonra None değeri, sistemin bilinen hiçbir CVE’ye karşı savunmasız olmadığını gösterir.

Raporda Kalan Bulgular SU11 ile Kapanır mı

HealthChecker raporunda SU11 sonrasında bazı sarı satırlar ve Download Domains uyarısı kalır. Bunların tamamı güncelleme paketiyle ilgili değildir. Aşağıdaki tablo bu sunucunun önce raporundaki bulguları, sonra raporunda ne olduklarını ve hangisinin SU ile, hangisinin ayrı bir yapılandırmayla kapandığını özetliyor:

Önceki yazıdaki PageFile, TCP (Transmission Control Protocol) KeepAlive, Visual C++ 2012/2013, IPv6 ve Sleepy NIC bulguları bu sunucuda zaten giderilmiş durumda. Raporda PageFile 16384 MB, TCPKeepAlive 1800000, iki Visual C++ paketi de güncel, IPv6 etkin ve Sleepy NIC Disabled değeri True görünüyor.

Bir bulguyu düzelttikten sonra raporu mutlaka iki adımlı yöntemle (önce -Server, sonra -BuildHtmlServersReport) yeniden üretin. Aksi halde düzelttiğiniz satır raporda eski haliyle görünmeye devam eder.

Kalan Açık: Download Domains (CVE-2021-1730)

SU11 sonrası raporda tek kırmızı uyarı olarak Download Domains kalıyor. SU kurulumu bu açığı kapatmaz, çünkü ayrı bir yapılandırma gerektirir. Bu yazıda adımları kısa tutuyoruz. Ayrıntılı anlatım için Exchange Server SE Güncelleme: HealthChecker ile Tespit Edilen Açıkları Kapatma yazısındaki Download Domains bölümüne bakabilirsiniz.

Download Domains, OWA (Outlook on the web) içindeki satır içi görsellerin ve eklerin OWA’nın kendi adresinden değil, ayrı bir host adından sunulmasını sağlar. Bu ayrım tarayıcının SameSite çerez korumasını devreye sokar ve CSRF (Cross-Site Request Forgery) saldırılarına karşı koruma sağlar.

Kullanıcılar Exchange’e hem iç ağdan hem dış ağdan bağlandığı için iki ayrı download host adı tanımlıyoruz: iç bağlantı için iç ağda çözülen bir ad, dış bağlantı için internetten çözülen bir ad. Bu laboratuvarda iç bağlantı için download.bakicubuk.local, dış bağlantı için örnek olarak download.bakicubuk.com kullanıyoruz. Kendi ortamınızda bu adları OWA adreslerinizden farklı seçin.

1. DNS kaydı: İç bağlantı için iç DNS sunucusunda (bu ortamda domain controller) download.bakicubuk.local adı için Exchange sunucusunun iç OWA adresine işaret eden bir CNAME kaydı ekliyoruz. Dış bağlantı için download.bakicubuk.com adını dış DNS’te dış OWA adresine işaret eden bir CNAME kaydı olarak tanımlıyoruz. Split DNS kullanıyorsanız dış adın iç DNS’te de çözülmesi gerekir.

2. Sertifika: İki download host adını da Exchange’in kullandığı sertifikanın SAN (Subject Alternative Name) alanına ekleyip sertifikayı yeniden oluşturuyoruz. Bu adım atlanırsa kullanıcılar sertifika hatası alır. Bu sunucuda IIS’e bağlı sertifika varsayılan Microsoft Exchange sertifikası olduğu için yeni adları içeren bir sertifika üretilip IIS ve SMTP servislerine atanmalıdır. Üretimde bu adları kurumsal CA’dan alınan sertifikaya eklemeniz gerekir.

3. Exchange yapılandırması: Exchange Management Shell‘i Run as administrator (Yönetici olarak çalıştır) açıyoruz. Önce OWA virtual directory’lerine iç ve dış download host adlarını, ardından organizasyon genelinde özelliği etkinleştiriyoruz:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InternalDownloadHostName "download.bakicubuk.local" -ExternalDownloadHostName "download.bakicubuk.com"
Set-OrganizationConfig -EnableDownloadDomains $true

Ayarın devreye girmesi için IIS’i yeniden başlatıyoruz. Yalnızca OWA’yı etkilemesi için daha hafif seçenek olarak OWA uygulama havuzunu yeniden başlatabilirsiniz:

iisreset
Restart-WebAppPool -Name "MSExchangeOWAAppPool"

4. Doğrulama: Satır içi görseli olan bir e-postayı OWA’da açıp görselin adresinin download host adından geldiğini kontrol ediyoruz. İç ağdan bağlanan kullanıcıda iç ad, internetten bağlanan kullanıcıda dış ad görünmelidir. Ardından HealthChecker’ı bir kez daha çalıştırıyoruz. Sonra raporunun XML ve TXT dosyalarını ayrı klasöre taşıyıp raporu yeni bir adla üretiyoruz:

New-Item -ItemType Directory -Path "C:\Scripts\After" -Force
Move-Item -Path "C:\Scripts\*HealthChecker*.xml","C:\Scripts\*HealthChecker*.txt" -Destination "C:\Scripts\After"
cd C:\Scripts
.\HealthChecker.ps1 -Server "W25EXCSE"; .\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "W25EXCSE-Report-Final.html"

Raporda Enable Download Domains satırının True olduğunu, Security Vulnerabilities satırının kaybolduğunu ve Vulnerability Detected değerinin None olduğunu görmeliyiz.

Laboratuvardaki son raporda build 15.02.2562.056, Enable Download Domains: True, Vulnerability Detected: None olarak göründü. KB5128895 de Exchange IU or Security Hotfix Detected altında listeleniyor. Edition (StandardEvaluation), Physical Memory ve Dynamic Memory satırları sarı kalmaya devam ediyor, bunlar güvenlik açığı değil, laboratuvar kaynaklı uyarılardır.

Olası Sorunlar ve Çözümleri

Kurulum sırasında ya da sonrasında sorunla karşılaşırsanız şu başlıklara bakın:

• Servisler Disabled kaldı: Kurulum yarıda kesilmiş olabilir. Microsoft’un SU sonrası servislerin başlamaması makalesindeki Workaround 1 adımlarını uygulayın.
• Kurulum hata verdi: Microsoft’un SetupAssist scriptini çalıştırın, hata kaydını inceleyin. Başarısız bir kurulumu onarmak için Exchange FAQ sayfasındaki yönergeleri kullanın.
• Windows Server 2025 üzerinde güncellemeyi geri kaldırmak: Microsoft güvenlik güncellemelerinin kaldırılmasını önermiyor. Yine de Windows Server 2025’te güncellemeler Control Panel’de listelenmez, ilgili durum için Microsoft’un destek makalesine bakın.
• Hybrid ortamda Auth certificate değişikliği: SU kurulumundan sonra Auth certificate değiştirirseniz Hybrid Configuration Wizard’ı (HCW) yeniden çalıştırmanız gerekir.
• Management Tools: Yalnızca Exchange Management Tools kurulu sunucu ve iş istasyonlarını da SU11 ile güncellemenizi Microsoft öneriyor.

Hangi Komut Hangi Konsolda Çalışır

Yazı boyunca üç farklı konsol kullandık. En sık yapılan hata, Exchange cmdlet’lerini düz Windows PowerShell’de çalıştırmaktır. Get-Queue, Set-ServerComponentState ve Set-OwaVirtualDirectory gibi komutlar yalnızca Exchange Management Shell‘de tanınır, Windows PowerShell’de not recognized hatası verir. Kurulum paketini ise Command Prompt üzerinden yönetici olarak başlatıyoruz.

Aşağıdaki tablo hepsini tek yerde topluyor:

Sonuç

Bir güvenlik açığını raporda görmek yeterli değildir, asıl önemli olan onu kapatıp sonucu doğrulamaktır. Exchange SE’de SU11 kurulum süreci özetle şu adımlardan oluşur: HealthChecker ile önce raporunu al, mevcut sürümü tespit et, paketi indirip hash’ini doğrula, sunucunun durumunu kontrol et, bakım moduna al, güncellemeyi elevated Command Prompt üzerinden kur, sunucuyu yeniden başlat, servisleri doğrula, bakım modundan çık, HealthChecker ile SU11’in açıkları kapattığını teyit et ve SU ile kapanmayan Download Domains açığını ayrıca yapılandırarak raporu None durumuna getir. Exchange 2016 ve 2019 için de güvenlik güncellemeleri yayımlanıyor. Ortamınızda hala bu sürümler varsa, kurulumu yaparken destek durumunuzu ve Exchange SE’ye geçiş planınızı da netleştirmenizi öneririm.