Merhaba

HealthChecker.ps1 ile yaptığımız sağlık kontrolü ve ardından bulguları kapattığımız iki yazıyla EXCDAG ortamımızı (W25EXCNOD1 / W25EXCNOD2 + W25WITNESS) gözden geçirmiştik. O raporlarda karşımıza çıkan önerilerden biri de güncel Security Update (SU) seviyesine geçmekti. Bu yazıda, o zamandan beri yayımlanan SU10 (KB5121608) güncellemesini, bir DAG üyesi Exchange sunucusunda kesintisiz (rolling) olarak nasıl kurduğumuzu adım adım anlatıyorum.

Tek sunuculu bir Exchange kurulumunda Security Update (SU) yüklemek, setup.exe’yi çalıştırıp yeniden başlatmaktan ibarettir. Ancak bir DAG üyesinde aynı işlemi düşünmeden yaparsak, o an aktif veritabanı kopyalarını barındıran node kısa süreli de olsa kesintiye uğrar, transport kuyruklarındaki mesajlar yarıda kalabilir. Bu yüzden DAG üyelerinde güncelleme, önce node’u bakım moduna almayı, sonra kurulumu yapmayı, en son da node’u tekrar production’a döndürmeyi kapsayan bir sıra izler.

Bu Yazıda Ne Yapacağız

Ortamımızı kısaca hatırlayalım:

İki node’lu bir DAG’da güncelleme mantığı şöyle: önce bir node bakıma alınır, o node üzerindeki tüm aktif veritabanı kopyaları diğer node’a taşınır, güncelleme kurulur, node doğrulanır ve tekrar production’a alınır. Ardından aynı sıra ikinci node için tekrarlanır. Bu sayede kullanıcılar açısından e-posta erişimi kesintisiz devam eder, çünkü her an en az bir node aktif ve sağlıklı kalır.

SU10 (KB5121608) Hakkında

SU10, Exchange Server SE RTM için 8 Eylül 2026’da yayımlandı. Toplam 8 CVE‘yi kapatıyor:

Bunların dışında SU10, hibrit ortamlarda paylaşılan (shared) kutularda görülen wrapper mesaj sorununu ve Microsoft Graph API üzerinden çalışan free/busy zamanlama gecikmelerini de gideriyor. Bilinen iki sorun ise henüz açık: yayımlanmış takvimlerin (.ics) bazı takvim uygulamalarında HTTP 500 dönmesi ve yalnızca Graph API kullanan hibrit ortamlarda delege kutular için müsaitlik (availability) sorgularının başarısız olabilmesi. Bizim ortamımız hibrit yapıda olmadığı için bu iki senaryoyu da kapsamıyor, dolayısıyla SU10’u doğrudan kurabiliyoruz.

Ortamımızda Kurulum Öncesi Gerçek Durum

Kuruluma geçmeden hemen önce raporu tazeliyoruz:

cd C:\Scripts
.\HealthChecker.ps1 -Server "W25EXCNOD1"
.\HealthChecker.ps1 -Server "W25EXCNOD2"
.\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "EXCDAG-Report-After.html"
.\EXCDAG-Report-After.html

Her iki node’da da HealthChecker.ps1‘i (v26.09.08.1649) bu şekilde tekrar çalıştırıp güncel durumu teyit ettim:

Burada dikkat edilmesi gereken nokta şu: HealthChecker‘in listelediği 37 CVE, yalnızca SU10’un kendi yamasıyla kapanan 8 CVE değil, node’un son kurulumdan (4 Eylül) bu yana kümülatif olarak geride kaldığı tüm CVE’lerin toplamı.

Burada akla şu soru gelebilir: önce SU9’u, sonra SU10’u mu kurmalıyız? Microsoft’un resmi Exchange Server Update FAQ’sine göre SU’lar, ait oldukları CU (ya da RTM) için kümülatiftir: Because SUs are cumulative since the CU they’re applicable to, you only need to install the latest SU. This gives you all of the security fixes released since the CU was released. Yani SU9’u atlayıp doğrudan SU10’u kurmak yeterli; SU10, SU9’un içerdiği tüm güvenlik düzeltmelerini de kapsıyor. Bu yüzden ortamımızda ayrı bir SU9 adımına hiç gerek yok, tek adımda SU10’a geçiyoruz ve bu sayede 37 CVE‘nin tamamının kapanması bekleniyor. Kurulum sonrası doğrulamada HealthChecker‘i tekrar çalıştırıp bu sayının sıfıra indiğini teyit edeceğiz.

Raporda ayrıca önceki iki yazıda yaptığımız düzeltmelerin hâlâ geçerli olduğunu da görüyorum: AMSI ayarı (EnableAMSIBodyScanAllProtocols) Accepted durumda, TLS 1.0/1.1 devre dışı ve TLS 1.2/1.3 etkin, replikasyon arabirimi (Ethernet1) beklendiği gibi DNS’e kayıtlı değil. Yani SU10 kurulumuna, önceki bulguları bozmadan, temiz bir zeminden başlıyoruz.

Kurulum Öncesi Hazırlık

Kuruluma geçmeden önce şu hazırlıkları tamamlıyoruz:

• KB5121608 paketini (ExchangeSubscriptionEdition-KB5121608-x64-en.exe) Microsoft Download Center’dan indirip her iki node’a da kopyalıyoruz.
• Antivirus ve yedekleme yazılımlarını geçici olarak devre dışı bırakıyoruz; kurulum sırasında dosya taraması setup.exe’yi yavaşlatabiliyor hatta bazı dosyaların kilitlenmesine yol açabiliyor.
• Bakım penceresini önceden planlıyoruz; iki node’un sırayla güncellenmesi toplamda bir kaç saat sürebiliyor.
• Kurulumdan önce ve sonra HealthChecker.ps1 çalıştıracağımız için script’in güncel sürümünün elimizde olduğundan emin oluyoruz.

Şu anki Exchange build numarasını doğrulamak için:

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

Adım 1: W25EXCNOD1’i Bakım Moduna Alma

Bakıma almadan önce, hangi veritabanı kopyalarının şu an W25EXCNOD1 üzerinde aktif (Mounted) olduğunu görüyoruz:

Get-MailboxDatabaseCopyStatus -Server W25EXCNOD1 | Format-Table Name,Status,ActivationSuspended -AutoSize

İki node’u birlikte görmek için sırayla sorguluyoruz:

Get-MailboxDatabaseCopyStatus -Server W25EXCNOD1 | Format-Table Name,Status,MailboxServer -AutoSize
Get-MailboxDatabaseCopyStatus -Server W25EXCNOD2 | Format-Table Name,Status,MailboxServer -AutoSize

Status değeri Mounted olan ve MailboxServer sütununda W25EXCNOD1 görünen veritabanları, biraz sonra çalıştıracağımız StartDagServerMaintenance.ps1 ile otomatik olarak W25EXCNOD2‘ye taşınacak kopyalar. Bu çıktıyı aklımızda tutuyoruz, çünkü node’u bakımdan çıkardıktan sonra bu veritabanlarını tercih edilen node’a geri dağıtırken (RedistributeActiveDatabases.ps1 adımında) hangi veritabanlarının W25EXCNOD1‘e ait olduğunu buradan hatırlayacağız.

Transport kuyruklarının boşalmasını (draining) başlatıyoruz:

Set-ServerComponentState W25EXCNOD1 -Component HubTransport -State Draining -Requester Maintenance
Restart-Service MSExchangeTransport

Ardından $ExScripts klasörüne geçip Microsoft’un DAG bakım script’ini çalıştırıyoruz. Bu script, node üzerindeki tüm aktif veritabanı kopyalarını diğer node’a taşır, cluster node’u duraklatır ve varsa Primary Active Manager (PAM) rolünü diğer node’a devreder:

CD $ExScripts
.\StartDagServerMaintenance.ps1 -ServerName W25EXCNOD1 -MoveComment "SU10 kurulumu" -PauseClusterNode

Bu script ekranda bir süre hiçbir çıktı göstermeden çalışabilir, bu normal; veritabanı taşıma işlemleri arka planda sürer ve bitmesi birkaç dakika alabilir.

Script tamamlandıktan sonra, kuyrukta kalmış olabilecek mesajları diğer node’a yönlendiriyoruz:

Redirect-Message -Server W25EXCNOD1 -Target W25EXCNOD2.bakicubuk.com

Son olarak sunucuyu tamamen çevrimdışı hale getiriyoruz:

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

Bakıma Hazır Olduğunu Doğrulama

Kuruluma geçmeden önce node’un gerçekten bakım modunda olduğunu birkaç komutla teyit ediyoruz:

Get-ServerComponentState W25EXCNOD1 | Format-Table Component,State -AutoSize
Get-MailboxServer W25EXCNOD1 | Format-List DatabaseCopyAutoActivationPolicy
Get-ClusterNode W25EXCNOD1 | Format-List
Get-Queue

İlk komutta yalnızca Monitoring ve RecoveryActionsEnabled bileşenlerinin aktif, diğerlerinin ise inaktif görünmesini bekliyoruz. İkinci komutta DatabaseCopyAutoActivationPolicy değerinin Blocked olması, üçüncüde cluster node’un duraklatılmış (paused) görünmesi, dördüncüde ise kuyrukların boş olması gerekiyor. Bu dört kontrol de doğrulanmadan setup.exe’yi çalıştırmıyoruz.

Son olarak, az önce not ettiğimiz veritabanı kopyalarının gerçekten W25EXCNOD2‘ye taşındığını doğruluyoruz:

Get-MailboxDatabaseCopyStatus -Server W25EXCNOD1 | Format-Table Name,Status,MailboxServer -AutoSize
Get-MailboxDatabaseCopyStatus -Server W25EXCNOD2 | Format-Table Name,Status,MailboxServer -AutoSize

Bu çıktıda daha önce W25EXCNOD1‘de Mounted görünen tüm veritabanlarının MailboxServer sütununda artık W25EXCNOD2 görünmesi gerekiyor. W25EXCNOD1 satırlarında Mounted durumda hiçbir veritabanı kalmamış olmalı; kalan varsa, kurulum öncesi StartDagServerMaintenance.ps1‘i tekrar çalıştırıp taşımanın tamamlanmasını bekliyoruz.

Adım 2: SU10 Kurulumunun Çalıştırılması

W25EXCNOD1 tamamen bakım moduna alındıktan sonra, yönetici olarak açılmış bir komut isteminden (elevated command prompt) SU10 paketini çalıştırıyoruz:

cd C:\ExchangeServerUpdates
.\ExchangeSubscriptionEdition-KB5121608-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 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 (Computing space requirements).

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ıklayın.

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

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

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

Güncelleme doğrulama aşamasına geçer (Status: Validating install) ve ilerleme çubuğu dolmaya başlar.

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ıklayın.

Komut satırına dönüldüğünde COMPLETED: The Exchange Server Update installed successfully mesajı görünür. Bu satır, güncellemenin sorunsuz kurulduğunu doğrular.

Adım 3: Kurulum Sonrası Doğrulama

Node yeniden açıldıktan sonra önce build numarasının değiştiğini doğruluyoruz:

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

Ardından Windows Olay Görüntüleyici’de (Event Viewer) Uygulama ve Sistem günlüklerini kısaca göz atıp kurulumla ilgili bir hata ya da uyarı olup olmadığına bakıyoruz. Bu adımda bir sorun görmezsek node’u bakımdan çıkarmaya geçiyoruz.

Adım 4: W25EXCNOD1’i Bakımdan Çıkarma

Kurulum ve doğrulama tamamlandığında, node’u tersten aynı sırayla production’a döndürüyoruz.

Önce sunucuyu tekrar aktif hale getiriyoruz:

Set-ServerComponentState W25EXCNOD1 -Component ServerWideOffline -State Active -Requester Maintenance

Sonra StopDagServerMaintenance.ps1 script’ini çalıştırıyoruz. Bu script cluster node’u tekrar aktif eder, DatabaseCopyAutoActivationPolicy değerini Unrestricted yapar ve node üzerindeki her veritabanı kopyası için Resume-MailboxDatabaseCopy çalıştırır:

CD $ExScripts
.\StopDagServerMaintenance.ps1 -ServerName W25EXCNOD1

Son olarak transport kuyruklarını tekrar açıyoruz:

Set-ServerComponentState W25EXCNOD1 -Component HubTransport -State Active -Requester Maintenance
Restart-Service MSExchangeTransport

Node’un artık bakım modunda olmadığını tek komutla teyit ediyoruz:

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

Eğer bu aşamada bir bileşen beklenmedik şekilde inaktif kalırsa, aşağıdaki komutlarla elle aktif hale getirebiliyoruz:

Set-ServerComponentState W25EXCNOD1 -Component ServerWideOffline -State Active -Requester Functional
Set-ServerComponentState W25EXCNOD1 -Component Monitoring -State Active -Requester Functional
Set-ServerComponentState W25EXCNOD1 -Component RecoveryActionsEnabled -State Active -Requester Functional

Adım 5: W25EXCNOD2 İçin Aynı Adımların Tekrarlanması

W25EXCNOD1 sağlıklı şekilde production’a döndükten sonra, aynı yedi adımı (transport draining, StartDagServerMaintenance.ps1, Redirect-Message, ServerWideOffline Inactive, kurulum, doğrulama, StopDagServerMaintenance.ps1) bu kez W25EXCNOD2 için tekrarlıyoruz. İki node’u aynı anda bakıma almıyoruz; DAG’da her zaman en az bir node’un aktif ve veritabanı kopyalarını sunuyor olması gerekiyor.

Son Kontroller

Her iki node da güncellendikten sonra, aktif veritabanı kopyalarının tercih edilen (preferred) node’lara dağılıp dağılmadığını kontrol ediyoruz. Güncelleme sırasındaki taşımalar nedeniyle bazı kopyalar tercih edilenden farklı bir node’da aktif kalmış olabilir; bunu Microsoft’un dağıtım script’iyle düzeltiyoruz:

CD $ExScripts
.\RedistributeActiveDatabases.ps1 -DagName EXCDAG -BalanceDbsByActivationPreference -Confirm:$false

Son olarak HealthChecker.ps1‘i tekrar çalıştırıp SU10’un ve DAG genelinin sağlık durumunu bir kez daha teyit ediyoruz. Önceki yazılarımızda gördüğümüz “güncel olmayan SU” bulgusunun bu raporda artık çıkmaması bekleniyor.

Sonuç

İki node’lu EXCDAG ortamımızda SU10 (KB5121608) güncellemesini, kullanıcılar açısından fark edilir bir kesinti yaratmadan, node’ları sırayla bakıma alıp çıkararak tamamladık. Bu rolling update yaklaşımı, tek sunuculu ortamlardan farklı olarak DAG’in sağlayabildiği en önemli avantajlardan biri: bakım ve güncelleme işlemleri sırasında bile posta kutuları erişilebilir kalıyor. Serinin bir sonraki yazısında EXCDAG ortamında sertifika yönetimini (SAN planlaması, namespace, CSR oluşturma, iki node’a dağıtım, auth certificate ve yenileme) uçtan uca ele alacağız.