Exchange Server SE DAG Ortamında Tespit Edilen Bulguları Kapatma

bakicubuk

1 saat önce

Merhaba

Bir önceki yazı olan Exchange Server SE DAG Ortamında Sağlık Kontrolü: HealthChecker.ps1 ile Uçtan Uca yazısında, iki node ve bir File Share Witness’tan oluşan EXCDAG ortamında HealthChecker.ps1 ile uçtan uca sağlık kontrolü yapmış, çıkan raporu satır satır yorumlamıştık. Sonuç 4 Kırmızı ve 7 Sarı bulgu bulgu olmuştu.

Bu yazıda o bulguları sırayla kapatıyoruz. Tek sunuculu bir ortamda bu işlem, komutları çalıştırıp sunucuyu yeniden başlatmaktan ibarettir. DAG yapısında ise üç soruyu önceden cevaplamanız gerekir:

Hangi düzeltme nerede uygulanır? Bazı ayarlar organizasyon genelindedir ve bir kez uygulanır; bazıları sunucu bazlıdır ve her iki node’da ayrı ayrı yapılmalıdır.
Hangi düzeltme restart gerektirir? Restart gerektiren maddeleri tek bir yeniden başlatmada toplamak, kesinti sayısını ikiye indirir.
Node’lar hangi sırayla bakıma alınır? Aktif veritabanı kopyalarını barındıran node her zaman en sona bırakılır.

Bu üç soruya göre çalışmayı fazlara böldük. Aşağıdaki adımları uyguladığınızda kullanıcı tarafında hissedilen kesinti, yalnızca switchover anıyla sınırlı kalacak.

Raporun Künyesi

Alan	Değer
Rapor	Exchange Health Checker v26.09.08.1649
Tarih	11.09.2026
Kapsam	W25EXCNOD1.bakicubuk.com, W25EXCNOD2.bakicubuk.com
DAG	EXCDAG (2 node + File Share Witness)
Build	15.02.2562.017 (Exchange SE RTM), her iki node aynı

İki node’un yapılandırması neredeyse birebir aynı. Bu iyi haber: DAG’da yapılandırma kayması (configuration drift) yok. Tek fark, Visual C++ 2013 x64 paketinin durumu: W25EXCNOD1‘de paket hiç bulunamıyor, W25EXCNOD2‘de ise sadece eski bir sürümde kurulu.

Alan	Durum
Kırmızı bulgu	4 kalem (her iki node’da aynı)
Sarı bulgu	7 kalem (her iki node’da aynı)
Node’lar arası fark	Sadece Visual C++ 2013 x64 durumu
Yeşil (sorun yok)	.NET 4.8.1, High Performance güç planı, TLS 1.2/1.3, RSS, Extended Protection, SerializedDataSigning, EEMS, SMB1 kapalı, Server Pending Reboot (her iki node’da False)

Bulgu Envanteri

#	Bulgu	Seviye	NOD1	NOD2	Restart
1	PageFile otomatik yönetiliyor (0 MB)	Kırmızı	Var	Var	Evet
2	TCPKeepAlive ayarlanmamış	Kırmızı	Var	Var	Evet
3	IPv6 tam olarak devre dışı değil	Kırmızı	Var	Var	Evet
4	Security Vulnerabilities (38 CVE)	Kırmızı	Var	Var	Evet
5	Son SU kurulu değil	Sarı	Var	Var	Evet
6	Known Issue: hybrid online archiving	Sarı	Var	Var	–
7	Visual C++ 2012 x64 eski (11.0.50727)	Sarı	Var	Var	Olası
8	Sleepy NIC (2 adapter)	Sarı	Var	Var	Hayır
9	Common Services Not Running (MSComplianceAudit)	Sarı	Var	Var	Hayır
10	AMSI Request Body Scanning kapalı	Sarı	Var	Var	Hayır
11	Edition: StandardEvaluation (~172 gün)	Sarı	Var	Var	Hayır
12	Visual C++ 2013 x64 node farkı	Sarı	Kurulu değil	Eski sürüm	Olası
13	Enable Download Domains = False	Bilgi	Var	Var	Hayır

Not: 6 numaralı madde lab ortamı için aksiyon gerektirmiyor; sadece hibrit (online archiving) yapılandırmasında geçerli. Sertifika tarafında ise önceki raporda görülen PendingRequest kaydı bu raporda yok; A1’de bunu ayrıca doğruluyoruz.

Bu Planda Kapsam Dışı

4 numaralı madde (CVE listesi) ve 5 numaralı madde (son SU) bir sonraki çalışmanın konusu. Rapordaki 38 CVE‘den 37‘si SU10 (KB5121608) kurulumuyla birlikte kapanacak. Kalan tek CVE olan CVE-2021-1730 ise SU’yu beklemiyor; bu planın A4 maddesinde ele alınan Download Domains yapılandırmasıyla kapanıyor, o yüzden aşağıdaki listede yer almıyor. Bu plandaki düzeltmeler SU kurulumundan önce yapılır, çünkü HealthChecker‘ın işaret ettiği yapılandırma hataları güncelleme sırasında da sorun çıkarabilir.

Raporda listelenen ve SU10‘u bekleyen 37 CVE, build 15.02.2562.017 üzerinde açık durumda:

#	CVE	Kapanma Yöntemi
1	CVE-2021-1730	Download Domains yapılandırması
2	CVE-2025-25005	Security Update – Network Tampering Vulnerability
3	CVE-2025-25006	Security Update – Spoofing Vulnerability
4	CVE-2025-25007	Security Update – Spoofing Vulnerability
5	CVE-2025-33051	Security Update – Information Disclosure Vulnerability
6	CVE-2025-53782	Security Update – Elevation of Privilege Vulnerability
7	CVE-2025-59248	Security Update – Spoofing Vulnerability
8	CVE-2025-59249	Security Update – Elevation of Privilege Vulnerability
9	CVE-2025-64666	Security Update – Elevation of Privilege Vulnerability
10	CVE-2025-64667	Security Update – Spoofing Vulnerability
11	CVE-2026-21527	Security Update – Spoofing Vulnerability
12	CVE-2026-42897	Security Update – Spoofing Vulnerability (OWA)
13	CVE-2026-45500	Security Update – Cross-Site Scripting Vulnerability
14	CVE-2026-45501	Security Update – Cross-Site Scripting Vulnerability
15	CVE-2026-45502	Security Update – Server-Side Request Forgery Vulnerability
16	CVE-2026-45503	Security Update – Server-Side Request Forgery Vulnerability
17	CVE-2026-45504	Security Update – Elevation of Privilege Vulnerability
18	CVE-2026-47631	Security Update – Cross-Site Scripting Vulnerability
19	CVE-2026-55005	Security Update – Remote Code Execution Vulnerability
20	CVE-2026-55006	Security Update – Elevation of Privilege Vulnerability
21	CVE-2026-55007	Security Update – Remote Code Execution Vulnerability
22	CVE-2026-55008	Security Update – Spoofing Vulnerability
23	CVE-2026-55009	Security Update – Elevation of Privilege Vulnerability
24	CVE-2026-62910	Security Update – Elevation of Privilege Vulnerability
25	CVE-2026-62911	Security Update – Elevation of Privilege Vulnerability
26	CVE-2026-62912	Security Update – Denial of Service Vulnerability
27	CVE-2026-62913	Security Update – Remote Code Execution Vulnerability
28	CVE-2026-62914	Security Update – Spoofing Vulnerability
29	CVE-2026-62915	Security Update – Security Feature Bypass Vulnerability
30	CVE-2026-65813	Security Update – Server-Side Request Forgery Vulnerability
31	CVE-2026-69355	Security Update – Remote Code Execution Vulnerability
32	CVE-2026-69356	Security Update – Spoofing Vulnerability
33	CVE-2026-69361	Security Update – Spoofing Vulnerability
34	CVE-2026-69375	Security Update – Tampering Vulnerability
35	CVE-2026-69378	Security Update – Denial of Service Vulnerability
36	CVE-2026-69380	Security Update – Elevation of Privilege Vulnerability
37	CVE-2026-69382	Security Update – Information Disclosure Vulnerability
38	CVE-2026-69641	Security Update – Elevation of Privilege Vulnerability

Her bir CVE’nin ayrıntısı EXCDAG-Report.html içindeki bağlantılardan (MSRC advisory) incelenebilir.

Uygulama Sırası

Düzeltmeleri üç fazda uygulayacağız. Restart gerektiren maddeler tek bir restart’ta toplanıyor, böylece her node bir kez yeniden başlatılıyor.

Faz	Kapsam	Nerede Çalıştırılır
Faz 0	Ön kontrol	Herhangi bir node
Faz A	Tek shell’den uygulanacak düzeltmeler	Bir node’dan, `-Server` / `-Identity` ile
Faz B	Sunucu bazlı düzeltmeler + restart	Önce pasif node, sonra aktif node
Faz C	Doğrulama ve raporu tazeleme	Herhangi bir node

Faz 0: Ön Kontrol

Hiçbir değişiklik yapmadan önce DAG’ın sağlıklı olduğunu doğrulayın.

Get-DatabaseAvailabilityGroup EXCDAG -Status | Format-List Name,Servers,WitnessServer,PrimaryActiveManager,OperationalServers
Test-ReplicationHealth -Identity W25EXCNOD1
Test-ReplicationHealth -Identity W25EXCNOD2
Get-MailboxDatabaseCopyStatus * | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize
Get-ClusterNode
Get-ClusterQuorum

Aktif kopyaların hangi node’da olduğunu not edin; Faz B’de pasif node’dan başlayacağız.

Not: Get-ClusterQuorum çıktısındaki QuorumType alanı güncel FailoverClusters modülünde sadeleştirilmiş Majority değerini döndürebilir, NodeAndFileShareMajority gibi detaylı bir isim değil. Bu bir yapılandırma sorunu değildir; witness’ın gerçek türü QuorumResource alanında görünür. Ayrıntısını bir önceki yazıda ele almıştım.

Yukarıdaki komut bloğunun tamamının çıktısı: Get-DatabaseAvailabilityGroup, her iki node için Test-ReplicationHealth, Get-MailboxDatabaseCopyStatus, Get-ClusterNode ve Get-ClusterQuorum. Beklenen: Test-ReplicationHealth her iki node’da da tüm kontrollerde Passed, kopyalar Mounted/Healthy ve kuyruklar (CopyQueueLength, ReplayQueueLength) 0, Get-ClusterNode her iki node için Up, Get-ClusterQuorum çıktısında QuorumResource alanı File Share Witness olarak görünmeli. Tek bir Failed satırı varken bile düzeltmelere başlamayın; node bakıma alındığında o veritabanı için tek sağlıklı kopya kalmaz.

Get-MailboxDatabaseCopyStatus * | Where-Object {$_.Status -eq "Mounted"} | Format-Table Name,MailboxServer -AutoSize

Faz A: Tek Shell’den Uygulanacak Düzeltmeler

Bu fazdaki maddeler için sunuculara tek tek bağlanmanıza gerek yok, hepsi tek bir Exchange Management Shell oturumundan yapılabilir.

Ancak kapsamları farklı:

Madde	Kapsam	Uygulama
A1. Sertifika	Sunucu bazlı (doğrulama)	Her node için ayrı komut (`-Server` ile)
A2. AMSI Body Scanning	Organizasyon geneli + sunucu bazlı devreye alma	Override tek komut, refresh ve IIS restart her node’da
A3. Lisans anahtarı	Sunucu bazlı	Her node için ayrı komut (`-Identity` ile)
A4. Download Domains	Karma: DNS tek kayıt, sertifika sunucu bazlı, ayar tek komut	Bkz. A4 tablosu

A1. Sertifika Durumu (Kontrol)

Sertifikalar Exchange’de sunucu bazlıdır; her node kendi yerel sertifika deposunu kullanır. HealthChecker raporlarında zaman zaman bir sertifika isteğinin PendingRequest durumunda takılı kaldığı görülür. Tipik sebebi, bir node üzerinde New-ExchangeCertificate -GenerateRequest çalıştırılıp üretilen CSR’ın hiç tamamlanmamasıdır. Ortak namespace kullanan bir DAG’da böyle bir isteğin genelde karşılığı yoktur, çünkü namespace zaten ortak bir SAN sertifikası üzerinden çalışır ve yarıda kalan istek yalnızca raporu kirletir.

Ortamınızda böyle bir kayıt olup olmadığını kontrol edin:

"W25EXCNOD1","W25EXCNOD2" | ForEach-Object {
    Write-Host "`n=== $_ ===" -ForegroundColor Cyan
    Get-ExchangeCertificate -Server $_ | Format-Table Thumbprint,Status,NotAfter,Services,Subject -AutoSize
}

Sadece bekleyen istekleri süzün:

"W25EXCNOD1","W25EXCNOD2" | ForEach-Object {
    $srv = $_
    Get-ExchangeCertificate -Server $srv |
      Where-Object {$_.Status -eq "PendingRequest"} |
      Select-Object @{n="Server";e={$srv}},Thumbprint,Services,Subject
}

İstek hala geçerliyse, yani CA’dan yanıt bekliyorsanız silmeyin. Yanıt dosyasını, isteği ürettiğiniz node’a Import-ExchangeCertificate ile aktarın. Private key ilk node’da durduğu için bir node’da üretilmiş isteğin yanıtı diğerine aktarılamaz.

Bekleyen bir yanıt yoksa ve Services alanı None ise isteği silin.

Remove-ExchangeCertificate -Server W25EXCNOD1 -Thumbprint  -Confirm:$false

Dikkat: Silmeden önce Services alanının None olduğunu mutlaka doğrulayın. Bir servise bağlı sertifikayı silmek o servisin durmasına yol açar.

Bu ortamda kontrol sonucu: İki node’da da PendingRequest durumunda bir kayıt yok, tüm sertifikalar Valid. Güncel envanter:

Thumbprint	Bulunduğu yer	Bağlı servisler	Ne olduğu
`7E4750C65B415B39DEB1B7673E4A3B5F770AA075`	Her iki node (aynı thumbprint)	IIS, SMTP	Ortak SAN sertifikası, namespace bunun üzerinden çalışıyor
`98311F42FBC86BB92482CE3DF6FC5CD33872E9B1`	Her iki node (aynı thumbprint)	SMTP	Auth certificate, organizasyon geneli
`9408289D2B4BDBF4C12A62DB18A352324F23A977`	Sadece W25EXCNOD1	IMAP, POP, IIS, SMTP	Kurulumda üretilen self-signed
`EB89B6944F0BA024DFC389354659A65576DE2F2E`	Sadece W25EXCNOD2	IMAP, POP, IIS, SMTP	Kurulumda üretilen self-signed

İlk iki satır ortamın doğru kurulduğunu gösteriyor: 7E4750C65B415B39DEB1B7673E4A3B5F770AA075 her iki node’da aynı thumbprint ile duruyor ve IIS’e bağlı, yani ortak namespace için üretilmiş tek bir SAN sertifikası iki node’a birden dağıtılmış. Auth certificate de organizasyon genelinde ortak. Üçüncü ve dördüncü satırdaki self-signed sertifikalar kurulumdan gelir, her node’da farklı olmaları normaldir. Bu dördüne dokunmayın.

Not: Ortak namespace sertifikasının nasıl üretilip iki node’a dağıtılacağı ayrı bir konu; DAG serisinin Bölüm 5: İstemci Erişimi, Namespace ve Load Balancing yazısında ele almıştım. Sertifika yönetimini uçtan uca anlatan ayrı bir yazı da hazırlıyorum

A2. AMSI Request Body Scanning (Bulgu 10)

Bu maddede önce bir parantez açmak gerekiyor: raporda görünen False büyük ihtimalle yanlış pozitif.

CSS-Exchange tarafında bilinen bir tespit hatası var. Ortamda AmsiRequestBodyScanning için bir SettingOverride tanımlı değilse, HealthChecker değeri False olarak raporluyor. Oysa Ağustos 2025 güvenlik güncellemesinden itibaren bu özellik tüm protokoller için varsayılan olarak açık. Yani override yok durumu, kapalı gibi görünüyor.

Durum	HealthChecker çıktısı	Gerçek durum
Override tanımlı değil	False	True (varsayılan açık)
Override = false	False	False
Override = true	True	True

Bu yüzden iki seçeneğiniz var:

Seçenek 1 – Dokunmamak: Ortamda özellik zaten açıksa yapacak bir şey yok, bulgu yanlış pozitiftir. HealthChecker’ın güncel sürümüyle raporu tekrar alıp maddenin düşüp düşmediğini kontrol edebilirsiniz.

Seçenek 2 – Açıkça tanımlamak: Ayarı override ile açıkça belirlemek, hem raporu temizler hem de yapılandırmayı belgelendirir. Varsayılana güvenmek yerine niyeti yazılı hale getirmiş olursunuz.

Bu ortamda kontrol sonucu: Get-SettingOverride | Where-Object {$_.SectionName -eq "AmsiRequestBodyScanning"} çıktısı boş döndü, yani hiç override tanımlı değil; gerçek AMSI durumu tamamen varsayılana dayanıyor ve bunu doğrudan gösteren bir cmdlet de yok (Get-AmsiConfiguration diye bir komut mevcut değil). Bu belirsizliği ortadan kaldırmak, ayarı denetlenebilir kılmak ve raporu kalıcı olarak temizlemek için Seçenek 2’yi uyguladık:

New-SettingOverride -Name "EnableAMSIBodyScanAllProtocols" -Component "Cafe" -Section "AmsiRequestBodyScanning" -Parameters ("EnabledAll=True") -Reason "Enabling AMSI body Scan for all protocols"

Sadece belirli protokoller için açmak isterseniz:

New-SettingOverride -Name "EnableAMSIBodyScanForEcpEwsOwa" -Component "Cafe" -Section "AmsiRequestBodyScanning" -Parameters @("EnabledEcp=True","EnabledEws=True","EnabledOwa=True") -Reason "Enabling AMSI body Scan for ECP, EWS and OWA"

Parametrelerin hangi protokole karşılık geldiği:

Parametre	Protokol / Servis	Ne için kullanılır
`EnabledAll`	Tüm protokoller	ActiveSync, Autodiscover, ECP, EWS, OWA ve diğer HTTP tabanlı Exchange protokollerinin tamamını kapsar
`EnabledEcp`	Exchange Control Panel (ECP)	Yönetim paneli (/ecp) üzerinden gelen istekler
`EnabledEws`	Exchange Web Services (EWS)	Outlook, mobil istemciler ve üçüncü parti entegrasyonların kullandığı API trafiği
`EnabledOwa`	Outlook on the Web (OWA)	Tarayıcı üzerinden webmail erişimi (/owa)

Yani EnabledAll=True ile tek satırda tüm protokolleri açarken, ikinci komuttaki gibi sadece EnabledEcp, EnabledEws,EnabledOwa parametrelerini True verirseniz tarama yalnızca bu üç protokol için etkinleşir; ActiveSync veya Autodiscover gibi diğer protokoller kapsam dışı kalır. Ortamınızda hangi protokollerin dışarıya açık olduğunu bilmiyorsanız EnabledAll=True daha güvenli bir başlangıçtır.

Override’ın oluştuğunu doğrulayın:

Get-SettingOverride | Where-Object {$_.SectionName -eq "AmsiRequestBodyScanning"} | Format-List Name,ComponentName,SectionName,Parameters,Status

Beklenen çıktı:

Name          : EnableAMSIBodyScanAllProtocols
ComponentName : Cafe
SectionName   : AmsiRequestBodyScanning
Parameters    : {EnabledAll=True}
Status        : Accepted

Dikkat: Status: Accepted ayarın Active Directory’ye yazıldığı anlamına gelir, sunucularda etkin olduğu anlamına gelmez. SettingOverride organizasyon genelindedir ama devreye alma işlemi sunucu bazlıdır.

Devreye almanın iki yolu var ve hangisini kullanacağınız planın neresinde olduğunuza bağlı:

Bu planı sırayla uyguluyorsanız ayrıca bir şey yapmanıza gerek yok. Faz B’nin B7 adımında her node zaten yeniden başlatılıyor. Sunucu açılışında topology servisi yapılandırmayı sıfırdan okur, IIS ve app pool’lar da yeniden başlar. Yani ayar, node bakım modundayken kendiliğinden devreye girer ve kullanıcı hiçbir kesinti hissetmez.

Bu maddeyi plandan bağımsız, tek başına uyguluyorsanız devreye almayı elle yapmanız gerekir.

Aşağıdaki komutları her node için ayrı ayrı çalıştırın:

Yapılandırmayı tazele (her node için ayrı)

Get-ExchangeDiagnosticInfo -Server W25EXCNOD1 -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Get-ExchangeDiagnosticInfo -Server W25EXCNOD2 -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

IIS servislerini yeniden başlat (ilgili node üzerinde çalıştırılır)

Restart-Service -Name W3SVC, WAS -Force

Uyarı: W3SVC ve WAS servislerinin yeniden başlatılması OWA, EWS ve ActiveSync bağlantılarını kısa süreliğine keser. İki node’da aynı anda yapmayın. Önce bir node’u bakım moduna alın (B0 adımı), servisleri orada yeniden başlatın, bakımdan çıkarın (B8 adımı), sonra diğerine geçin.

Varsayılan tarama boyutu 4096 bayttır, en fazla 1048576 bayta (1 MB) çıkarılabilir. Antivirüs çözümünüzün AMSI sağlayıcısı yüklü değilse bu ayarın pratik faydası olmaz.

A3. Edition: StandardEvaluation (Bulgu 11)

Her iki node StandardEvaluation sürümünde ve ~172 gün deneme süresi kalmış. Deneme süresi dolduğunda Exchange servisleri durur. Lisans anahtarını girin:

Set-ExchangeServer -Identity W25EXCNOD1 -ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Set-ExchangeServer -Identity W25EXCNOD2 -ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Anahtar girildikten sonra ilgili node’da Microsoft Exchange Information Store servisini yeniden başlatın (Faz B’deki restart bunu zaten kapsıyor).

Get-ExchangeServer | Format-Table Name,Edition,AdminDisplayVersion -AutoSize

A4. Download Domains (Bulgu 13, CVE-2021-1730 azaltması)

Raporda Enable Download Domains = False görünüyor. Bu ayar CVE-2021-1730 için azaltma sağlar: OWA’daki ek dosyalar ana namespace yerine ayrı bir host adı üzerinden servis edilir, böylece ek dosya içeriği oturum çerezlerine erişemez. Bu maddeyi tamamladığınızda “Bu Planda Kapsam Dışı” bölümündeki listeye giren 37 CVE’nin dışında kalan CVE-2021-1730 da kapanmış olur.

Bu maddede kapsam üç katmana ayrılıyor ve karıştırılması kolay:

Katman	Kapsam	Kaç kez yapılır
DNS kaydı	Namespace bazlı	DNS bölgesinde bir kayıt
Sertifika SAN	Sunucu bazlı	Her node’un sertifikasında bulunmalı
Exchange yapılandırması	Organizasyon + sanal dizin	Tek komut, pipeline iki node’u da kapsar
App pool restart	Sunucu bazlı	Her node üzerinde ayrı ayrı

DNS: tek kayıt

download.bakicubuk.com bir namespace, bir sunucu adı değil. Bu yüzden her node için ayrı kayıt oluşturulmaz. DNS bölgesinde tek bir CNAME kaydı açılır ve mevcut Exchange namespace’ine yönlendirilir:

download.bakicubuk.com    CNAME    mail.bakicubuk.com

CNAME’i doğrudan W25EXCNOD1.bakicubuk.com gibi bir node adına yönlendirmeyin. O node kapandığında download adresi de çalışmaz hale gelir. Kaydı namespace’e bağlarsanız, namespace hangi mekanizmayla çözülüyorsa (load balancer VIP, DNS round robin veya tek A kaydı) download adresi de aynı yolu izler.

İç ve dış DNS ayrıysa (split-brain), kayıt her iki bölgede de bulunmalıdır. OWA’yı dışarıya yayınlamıyorsanız iç bölge yeterlidir.

Add-DnsServerResourceRecordCName -ZoneName "bakicubuk.com" -Name "download" -HostNameAlias "mail.bakicubuk.com"

Resolve-DnsName download.bakicubuk.com

Sertifika: her iki node

Sertifikalar sunucu bazlı olduğu için download.bakicubuk.com adının her iki node’un IIS’e bağlı sertifikasında SAN olarak bulunması gerekir. Aksi halde istemci hangi node’a düşerse orada sertifika uyarısı alır.

"W25EXCNOD1","W25EXCNOD2" | ForEach-Object {
    Get-ExchangeCertificate -Server $_ |
      Where-Object {$_.Services -match "IIS"} |
      Select-Object @{n="Server";e={$_}},Thumbprint,@{n="SAN";e={$_.CertificateDomains -join ", "}}
}

Bu ortamda IIS’e bağlı ortak SAN sertifikası (7E4750C65B415B39DEB1B7673E4A3B5F770AA075) zaten iki node’da da mevcut, A1’deki envanterde görünüyor. Dolayısıyla yapılacak iş yeni sertifika üretmek değil, mevcut sertifikayı download.bakicubuk.com adını da kapsayacak şekilde yenilemek. Bu işlem bu yazının kapsamı dışında; yenileme yapmadan Download Domains maddesini atlayabilirsiniz, zorunlu bir adım değil (ancak CVE-2021-1730‘un tam kapanması için gereklidir).

Exchange yapılandırması: tek komut

Get-OwaVirtualDirectory parametresiz çalıştığında organizasyondaki tüm OWA sanal dizinlerini döndürür, yani her iki node’u da kapsar. Ayrı ayrı çalıştırmanıza gerek yok.

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

App pool restart: her iki node

Ayarın devreye girmesi için OWA app pool’unun yeniden başlaması gerekir.

Bu planı sırayla uyguluyorsanız ayrıca bir şey yapmayın; B7 adımındaki yeniden başlatma app pool’ları da kapsar.

Tek başına uyguluyorsanız Restart-WebAppPool yerel sunucuda çalışır, uzak node’u hedefleyemez. Komutu her node üzerinde ayrı ayrı, node bakım modundayken çalıştırın:

Restart-WebAppPool -Name "MSExchangeOWAAppPool"

Doğrulama:

Get-OrganizationConfig | Format-List EnableDownloadDomains
Get-OwaVirtualDirectory | Format-List Server,ExternalDownloadHostName,InternalDownloadHostName

Faz B: Sunucu Bazlı Düzeltmeler

Aşağıdaki adımlar her iki node üzerinde ayrı ayrı uygulanır. Önce pasif node ile başlayın. Hangi node’un pasif olduğunu Faz 0’daki çıktıya göre belirleyin; sıra, DAG’ınızın o anki durumuna göre değişebilir.

B0. Ön kontrol ve bakım moduna alma

Faz 0’daki kontrolleri çalışmanın başında bir kez yapmıştık. Burada kısa bir tekrar var ve bilinçli: aradan zaman geçmiş, bir restart olmuş veya önceki denemeden kalıntı kalmış olabilir. Bakım moduna almadan hemen önce dört soruya cevap verin. Aynı bloğu B9’da ikinci node’a geçerken tekrar çalıştıracaksınız.

1. Aktif kopyalar nerede?

Bakıma alacağınız node pasif olmalı.

burada

Node	Mevcut durum
W25EXCNOD1	Error / Unknown paket bulunamıyor, temiz kurulum gerekiyor
W25EXCNOD2	Kurulu ama eski sürüm (12.0.21005) üzerine güncelleme yeterli

Paket	Hedef
Visual C++ 2012 x64 Update 4	11.0.61030
Visual C++ 2013 x64	12.0.40664

burada

Madde	Neden restart gerekiyor
B1 PageFile	Yeni sayfa dosyası boyutu açılışta devreye girer
B2 TCPKeepAlive	Registry değeri açılışta okunur
B3 IPv6	NIC binding değişikliği açılışta kesinleşir
B4 Visual C++	Kurulum restart isteyebilir
A2 AMSI Body Scanning	Topology servisi yapılandırmayı açılışta yeniden okur, IIS de yeniden başlar
A4 Download Domains	OWA app pool açılışta yeniden başlar

burada

Hata / Belirti	Sebep	Çözüm
`The database copy does not have a replication instance running`	Hedef node hala bakım modunda, yeni restart olmuş veya `MSExchangeRepl` durmuş	Aşağıdaki teşhis sırasını izleyin
`Suspend-ClusterNode` hata veriyor	Aktif kopyalar hala o node üzerinde	Önce `Move-ActiveMailboxDatabase` çalıştırın
Kopyalar `Failed` durumda kalıyor	Node bakımdan tam çıkmamış	`StopDagServerMaintenance.ps1`, sonra `Resume-MailboxDatabaseCopy`
`ContentIndexState = NotApplicable`	Hata değil: Exchange SE’de BigFunnel, indeks veritabanının içinde	Aksiyon gerekmez
Bakımdan çıkışta kuyruk boşalmıyor	Transport hala Draining	`Set-ServerComponentState ... -Component HubTransport -State Active`
Bakım moduna alma sessizce başarısız, `HighAvailability` Inactive kalıyor	Script taşıma adımında hata alıp geri almıyor	Aşağıdaki alt başlığa bakın

burada

Kontrol	Beklenen
`ServerWideOffline`	Active
`DatabaseCopyAutoActivationPolicy`	Unrestricted
`DatabaseCopyActivationDisabledAndMoveNow`	False
Cluster node durumu	Up
`MSExchangeRepl` servisi	Running
Kopya durumu	Healthy

burada

#	Bulgu	Beklenen Sonuç
1	PageFile	8192 / 8192, otomatik yönetim kapalı
2	TCPKeepAlive	1800000
3	IPv6	Tüm adapterlerde Enabled = True
7	Visual C++ 2012 x64	11.0.61030
8	Sleepy NIC	Disabled
9	Common Services Not Running	`MSComplianceAudit` Running
10	AMSI Body Scanning	SettingOverride Accepted
11	Edition	Standard (Evaluation değil)
12	Visual C++ 2013 x64 (node farkı)	12.0.40664, her iki node’da aynı
13	Download Domains	True (opsiyonel)
–	Sertifika	PendingRequest kaydı yok
–	A2 ve A4 restart sonrası etkin	Ayarlar devrede
–	Replikasyon NIC DNS kaydı	False
–	DAG sağlığı	Tüm testler Passed

burada

burayabaksana

CVE-2025-25005, CVE-2025-25006, CVE-2025-25007, CVE-2025-33051, CVE-2025-53782,
CVE-2025-59248, CVE-2025-59249, CVE-2025-64666, CVE-2025-64667, CVE-2026-21527,
CVE-2026-42897, CVE-2026-45500, CVE-2026-45501, CVE-2026-45502, CVE-2026-45503,
CVE-2026-45504, CVE-2026-47631, CVE-2026-55005, CVE-2026-55006, CVE-2026-55007,
CVE-2026-55008, CVE-2026-55009, CVE-2026-62910, CVE-2026-62911, CVE-2026-62912,
CVE-2026-62913, CVE-2026-62914, CVE-2026-62915, CVE-2026-65813, CVE-2026-69355,
CVE-2026-69356, CVE-2026-69361, CVE-2026-69375, CVE-2026-69378, CVE-2026-69380,
CVE-2026-69382, CVE-2026-69641