Exchange Server SE DAG Ortamında SU11 (KB5128895) Kurulumu: Adım Adım DAG Güncelleme

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. Tek sunuculu laboratuvarda SU11 kurulumunu önceki yazıda anlatmıştım. Bu yazıda aynı güncellemeyi DAG (Database Availability Group, Veritabanı Kullanılabilirlik Grubu) ortamında, yani EXCDAG üyesi iki sunucuda uyguluyoruz.

DAG’da güncelleme tek sunucudan farklıdır. Sunucuları aynı anda değil, sırayla güncelliyoruz. Bir üye bakımdayken veritabanlarını diğer üye taşır, böylece kullanıcılar posta erişimini kaybetmez. Bu yöntemin adı rolling update (kademeli güncelleme).

Not: Bu yazı DAG ortamında SU10 kurulumu yazısındaki akışın SU11 için uyarlanmış halidir. SU10’u kurduysanız doğrudan bu yazıdaki adımlarla ilerleyebilirsiniz.

Bu Yazıda Ne Yapacağız

Laboratuvar ortamımız şu bileşenlerden oluşuyor:

Bileşen Ad Açıklama
DAG (Database Availability Group) EXCDAG İki üyeli DAG
Birinci üye W25EXCNOD1 Mailbox sunucusu
İkinci üye W25EXCNOD2 Mailbox sunucusu
File Share Witness (FSW) W25WITNESS Çekirdek (quorum) için tanık sunucu
Active Directory domain bakicubuk.com Sunucu FQDN’leri W25EXCNOD1.bakicubuk.com gibi

Akışımız şöyle:

  1. HealthChecker ile önce raporunu alıyor, mevcut build’i not ediyoruz.
  2. Paketi iki sunucuya indirip hash’ini doğruluyor, DAG sağlığını kontrol ediyoruz.
  3. W25EXCNOD1‘i bakım moduna alıyor, SU11’i kuruyor, sunucuyu yeniden başlatıp bakımdan çıkarıyoruz.
  4. Veritabanı kopyaları senkron olunca aynı adımları W25EXCNOD2 için tekrarlıyoruz.
  5. Aktif veritabanlarını tercih edilen sunuculara geri dağıtıyor ve HealthChecker ile sonucu doğruluyoruz.

SU11 (KB5128895) Hakkında

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.

Özellik Değer
Güncelleme Exchange Server SE RTM Oct 26 SU (SU11)
KB (Knowledge Base) numarası KB5128895
Build numarası 15.2.2562.56 (uzun format: 15.02.2562.056)
Yayın tarihi 13 Ekim 2026
Dosya adı ExchangeSubscriptionEdition-KB5128895-x64-en.exe
Dosya boyutu 344,6 MB
Desteklenen işletim sistemleri Windows Server 2019, Windows Server 2022, Windows Server 2025
Yerine geçtiği güncellemeler SU10 (KB5121608) ve SU10 V2 (KB5129955)

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

CVE (Common Vulnerabilities and Exposures) Tür Önem CVSS (Common Vulnerability Scoring System) Base / Temporal
CVE-2026-70571 Remote Code Execution (Uzaktan Kod Çalıştırma) Critical 8.1 / 7.1
CVE-2026-77910 Elevation of Privilege (Yetki Yükseltme) Important 8.8 / 7.7
CVE-2026-87692 Elevation of Privilege (Yetki Yükseltme) Important 7.8 / 6.8
CVE-2026-87695 Elevation of Privilege (Yetki Yükseltme) Important 7.8 / 6.8
CVE-2026-87696 Elevation of Privilege (Yetki Yükseltme) Important 7.5 / 6.5
CVE-2026-70279 Spoofing (Sahtecilik) Important 9.3 / 8.1

SU paketleri kümülatiftir. Sunucularınız SU10 build’indeyse (15.02.2562.049) ara paket kurmanıza gerek yoktur, doğrudan SU11’i kuruyoruz. SU11 kurulduktan sonra iki üyenin de aynı build’de (15.02.2562.056) olması gerekir. DAG üyeleri arasında kalıcı build farkı bırakmamak için ikinci sunucuyu aynı bakım penceresinde güncellemeniz önerilir.

Kurulum Öncesi Hazırlık

HealthChecker ile Mevcut Durumu Çıkarma

HealthChecker scriptini önceki yazılarda C:\Scripts klasörüne indirmiştik. Script güncel kalsın diye önce güncelleme kontrolü yapıyor, ardından iki sunucuda ayrı ayrı çalıştırıp tek bir HTML raporu üretiyoruz.

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

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

Raporda iki üyenin de Exchange SE RTM Sep26SU (build 15.02.2562.049) olarak göründüğünü, Exchange IU or Security Hotfix Detected altında KB5121608’in listelendiğini ve Not on the latest SU uyarısının çıktığını görüyoruz. Vulnerability Detected satırı ise True oluyor. Yeni HealthChecker sürümü SU10 build’ini artık son SU değil olarak işaretlediği için önceki yazıda sıfıra inen CVE sayısı bu rapor için yeniden yükseliyor.

Laboratuvarımızda iki sunucuda da aynı 7 CVE listeleniyor:

CVE (Common Vulnerabilities and Exposures) SU11 ile kapanır mı
CVE-2026-96940 Evet (SU10 V2 ile kapanan açık, SU11 onu da kapsıyor)
CVE-2026-70571 Evet
CVE-2026-77910 Evet
CVE-2026-87692 Evet
CVE-2026-87695 Evet
CVE-2026-87696 Evet
CVE-2026-70279 Evet

Yani SU11’in kendi 6 açığına ek olarak, SU10 build’inde kalan ve SU10 V2 ile kapanan CVE-2026-96940 da listede görünüyor. Kurulumdan sonra bu satırın None olmasını hedefliyoruz.

Not: Önceki raporları karıştırmamak için önce raporunun XML ve TXT çıktılarını C:\Scripts\Before gibi ayrı bir klasöre taşıyabilirsiniz: New-Item -ItemType Directory -Path "C:\Scripts\Before" -Force ve ardından Move-Item -Path "C:\Scripts\*HealthChecker*.xml","C:\Scripts\*HealthChecker*.txt" -Destination "C:\Scripts\Before".

Mevcut Sürümü Tespit Etme

Her iki sunucuda da kurulu build’i ExSetup.exe dosyasının sürüm bilgisinden okuyoruz. Bu komut Windows PowerShell ya da Exchange Management Shell’de çalışır:

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

Kurulumdan sonra bu değerin 15.02.2562.056 olmasını bekliyoruz.

Paketi İndirme ve Doğrulama

SU11 paketini Microsoft Download Center üzerinden ya da KB5128895 destek sayfasından indiriyoruz. İngilizce kurulumlar için ExchangeSubscriptionEdition-KB5128895-x64-en.exe dosyasını alıyor ve iki sunucuda da C:\ExchangeServerUpdates klasörüne kaydediyoruz. Paketi bir kez indirip diğer sunucuya kopyalayabilirsiniz.

İndirilen paketin bozulmadığından emin olmak için her iki sunucuda SHA256 (Secure Hash Algorithm 256) değerini hesaplı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.

Sunucuların Durumunu Kontrol Etme

Bekleyen bir restart varsa kurulum sırasında beklenmedik hatalarla karşılaşabiliriz. Bu yüzden her iki sunucuda önce bekleyen restart olup olmadığına bakıyoruz. Üç komutun da False döndürmesi gerekir:

Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending"
Not: Bu laboratuvarda iki sunucu da kurulumdan önce yeniden başlatıldı. HealthChecker raporunda Server Pending Reboot satırı bu yüzden iki sunucuda da False görünüyor. Bekleyen restart olan bir sunucuda bu satır sarı uyarı verir ve PendingFileRenameOperations ile RebootPending anahtarlarını listeler. Böyle bir durumda sunucuyu yeniden başlatıp kontrolü tekrarlayın.

Ardından disk alanını ve Exchange servislerini 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 komutları iki sunucuda da çalıştırıyoruz. C sürücüsünde kurulum için yeterli boş alan olmalı (laboratuvarda yaklaşık 93 GB). Çıktıdaki D sürücüsü laboratuvarda sanal DVD sürücüsüdür, bu yüzden 0 GB boş alan göstermesi normaldir. Servis listesinde Disabled servis olmamalı. MSExchangeImap4, MSExchangeIMAP4BE, MSExchangePop3 ve MSExchangePOP3BE servisleri varsayılan olarak Stopped ve Manual gelir, IMAP4 ve POP3 kullanmıyorsanız bu sorun değildir.

Kurulum süresince antivirüs ve yedekleme yazılımlarının dosya taramasını geçici olarak durdurmanızı öneririm. Tarama kurulum dosyalarını yavaşlatabilir ya da kilitleyebilir.

DAG Sağlığını Kontrol Etme

Bir üyeyi bakıma almadan önce DAG’ın sağlıklı olduğundan emin olmalıyız. Diğer üye sağlıklı değilse bakıma alınan sunucunun veritabanlarını devralacak kimse kalmaz. Exchange Management Shell‘de önce DAG üyelerine ve FSW’ye (File Share Witness) bakıyoruz:

Get-DatabaseAvailabilityGroup EXCDAG -Status | Format-List Name,Servers,WitnessServer,WitnessShareInUse

Çıktıda DAG üyelerinin W25EXCNOD1 ve W25EXCNOD2, tanık sunucunun w25witness.bakicubuk.com olduğunu, WitnessShareInUse değerinin ise Primary olduğunu görüyoruz. Bu değer, DAG’ın birincil tanık paylaşımını kullandığını gösterir.

Ardından her iki sunucuda veritabanı kopyalarının durumunu ve kuyruk uzunluklarını görüyoruz. Get-MailboxDatabaseCopyStatus komutunda DAG adı parametresi yoktur, bu yüzden her sunucuyu ayrı ayrı sorguluyoruz:

Get-MailboxDatabaseCopyStatus -Server W25EXCNOD1 | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize
Get-MailboxDatabaseCopyStatus -Server W25EXCNOD2 | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize

Laboratuvarımızda iki veritabanı ve iki sunucu var:

Sunucu Veritabanı Status CopyQueueLength ReplayQueueLength
W25EXCNOD1 DB01 Mounted 0 0
W25EXCNOD1 DB02 Healthy 0 0
W25EXCNOD2 DB02 Mounted 0 0
W25EXCNOD2 DB01 Healthy 0 0

Mounted kopya o anda aktif olan, Healthy kopya ise pasif ve senkron olan kopyadır. Burada DB01 W25EXCNOD1, DB02 W25EXCNOD2 üzerinde aktif. ContentIndexState sütunu bu laboratuvarda tüm kopyalarda NotApplicable görünüyor. Kuyruklar 0 ve replikasyon testi başarılı olduğu için bunu hata olarak değerlendirmiyoruz. Kendi ortamınızda bu sütunda Failed ya da FailedAndSuspended gibi bir hata durumu görürseniz önce onu araştırın. Son olarak her iki sunucu için replikasyon sağlığını test ediyoruz:

Test-ReplicationHealth -Server W25EXCNOD1
Test-ReplicationHealth -Server W25EXCNOD2

Her iki sunucuda da ClusterService, ReplayService, QuorumGroup, FileShareQuorum, DatabaseRedundancy ve DBCopyFailed dahil tüm kontroller Passed döndürüyor, Error sütunu boş. Kopya durumları, kuyruk uzunlukları (0’a yakın) ve Test-ReplicationHealth sonuçlarının hepsi sağlıklı olmadan kuruluma geçmeyin. Sağlıksız bir kopya varsa önce onu düzeltin.

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

Aynı anda yalnızca bir üyeyi bakıma alıyoruz. İki üyeli DAG’da biri bakımdayken diğeri ve FSW çoğunluğu (quorum) sağlar. İki sunucuyu birden bakıma almak veritabanlarının kapanmasına yol açar.

Aktif Kopyaların Yerini Not Alma

Bakıma almadan önce W25EXCNOD1 üzerinde hangi veritabanlarının Mounted olduğunu not alıyoruz, çünkü kurulumdan sonra bunları geri taşıyacağız:

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

Transport Kuyruğunu Boşaltma

Önce sunucunun yeni mesaj kabul etmesini durduruyor ve mevcut kuyruğu boşaltmaya başlıyoruz. Draining (boşaltma) işlemini başlatmak için transport servisini yeniden başlatıyoruz:

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

Restart-Service sırasında Waiting for service ‘Microsoft Exchange Transport (MSExchangeTransport)’ to start… uyarısının birkaç kez görünmesi normaldir. PowerShell servisin yeniden başlamasını beklerken bu mesajı yazar, bir hata anlamına gelmez.

Veritabanlarını Diğer Üyeye Taşıma

Exchange’in kendi bakım scriptini çalıştırıyoruz. Script, DatabaseCopyAutoActivationPolicy değerini Blocked yapar, cluster node’unu duraklatır (Paused) ve aktif veritabanlarını diğer üyeye taşır. Komut çıktı üretmeyebilir, bu normaldir:

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

Bu laboratuvarda komut herhangi bir çıktı vermeden tamamlandı. Başarılı olup olmadığını aşağıdaki bakım doğrulamalarıyla kontrol ediyoruz.

Ardından kuyrukta kalan mesajları diğer üyeye yönlendiriyoruz. Burada hedefin FQDN (tam alan adı) olarak yazılması gerekir. Bu ortamın domain adı bakicubuk.com:

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

Komut bir Confirm (onay) sorusu gösterir. Burada A (Yes to All) yazarak devam ediyoruz. Komut işlem sonunda çıktı vermez ve doğrudan prompt’a döner.

Son olarak sunucuyu bakım moduna alıyoruz:

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

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

Kuruluma başlamadan önce dört kontrolün de tamamlandığından emin oluyoruz. Önce bileşenlerin durumuna bakıyoruz:

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

Çıktı uzun olduğu için iki ekrana bölündü. Bakım modundaki bir sunucuda şu durumu görmeniz gerekir:

Durum Bileşenler Anlamı
Active Monitoring, RecoveryActionsEnabled Managed Availability (Yönetilen Kullanılabilirlik) izleme ve otomatik kurtarma işlemleridir. Bakım modunda da Active kalmaları normaldir, sorun değildir
Inactive ServerWideOffline, HubTransport, FrontendTransport Sunucu bakım modundadır ve bu sunucu mail akışına katılmaz
Inactive AutoDiscoverProxy, ActiveSyncProxy, EcpProxy, EwsProxy, OabProxy, OwaProxy, RpcProxy, MapiProxy, RpsProxy, RwsProxy, RestProxy ve diğer *Proxy bileşenleri Bu sunucu istemci bağlantılarını (Outlook, OWA, EWS, ActiveSync vb.) kabul etmez
Inactive ImapProxy, PopProxy IMAP ve POP istemci bağlantıları da kapalıdır
Inactive Listedeki diğer bütün bileşenler (HighAvailability, RoutingService, SharedCache, Lsass vb.) Bakım için kapatılmıştır

Monitoring ve RecoveryActionsEnabled dışında Active görünen bir bileşen varsa kuruluma geçmeyin. ServerWideOffline komutunu yeniden çalıştırıp çıktıyı tekrar kontrol edin.

Diğer üç kontrolü çalıştırıyoruz:

Get-MailboxServer W25EXCNOD1 | Format-List DatabaseCopyAutoActivationPolicy
Get-ClusterNode W25EXCNOD1 | Format-List
Get-Queue

Bu ekranda DatabaseCopyAutoActivationPolicy değeri Blocked, cluster node durumu Paused ve W25EXCNOD1\Submission kuyruğunda mesaj sayısı 0 görünüyor.

Beklenen sonuçlar şunlardır:

Kontrol Beklenen sonuç
Get-ServerComponentState Yalnızca Monitoring ve RecoveryActionsEnabled bileşenleri Active, diğerleri Inactive
DatabaseCopyAutoActivationPolicy Blocked
Get-ClusterNode State değeri Paused
Get-Queue Kuyruk boş ya da mesaj sayısı 0

Bu sunucuda aktif veritabanı kalmadığını da doğruluyoruz. Mounted görünen bir kopya kalmışsa StartDagServerMaintenance.ps1 komutunu yeniden çalıştırın:

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

Not: Bu dört kontrolün tamamı geçmeden kuruluma başlamayın. Get-Queue ve Get-ServerComponentState gibi Exchange cmdlet’leri yalnızca Exchange Management Shell’de çalışır.

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

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.

Karşılama ekranında 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. Sihirbaz önce çalışan Exchange servislerini durdurur (Stopping services):

Ardından kurulumu doğrular (Validating install). İlerleme çubuğu uzun süre aynı yerde kalabilir. Bu, kurulumun en uzun süren kısmıdır, bu nedenle sihirbazı kapatmadan bekliyoruz:

Son aşamada sihirbaz durdurduğu servisleri yeniden başlatır (Starting services). Bu aşamada Cancel butonu pasif hale gelir:

İşlem bitince sihirbaz durdurduğu servisleri yeniden başlatır ve Setup Wizard … Completed ekranı açılır. Finish butonuna tıklıyoruz.

Finish sonrasında Installer Information penceresi açılır. Pencere, değişikliklerin etkinleşmesi için sunucunun yeniden başlatılması gerektiğini söyler. Bu pencerede Yes dersek sunucu hemen yeniden başlar. DAG üyesi bakımda olduğu için bu güvenlidir, ancak komut satırındaki COMPLETED: The Exchange Server Update installed successfully mesajını görmek istiyorsanız No seçip mesajı kontrol ettikten sonra sunucuyu elle yeniden başlatabilirsiniz.

Sunucuyu Yeniden Başlatma ve Servis Kontrolü

Güvenlik güncellemesinin ardından sunucuyu her zaman yeniden başlatıyoruz. Atlarsak Outlook on the web (OWA) ya da ECP (Exchange Control Panel) üzerinde HTTP 400 gibi oturum açma hatalarıyla karşılaşabiliriz. Pencerede No seçtiyseniz Windows PowerShell‘i Run as administrator (Yönetici olarak çalıştır) açıp şu komutu çalıştırın:

Restart-Computer

Sunucu açıldıktan sonra Exchange servislerinin Disabled durumda kalmadığını kontrol ediyoruz. Disabled kalan servis, kurulumun bir noktada kesintiye uğradığını gösterir:

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

Bu komut hiçbir şey döndürmemeli. Sonrasında build numarasını doğruluyoruz:

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

Çıktıda 15.02.2562.056 değerini görmemiz gerekir. Kurulum sırasında oluşan hatalar için Event Viewer’da Application ve System kayıtlarına da bakmanızı öneririm.

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

Sunucu yeniden başladıktan ve servisler doğrulandıktan sonra bakımdan çıkıyoruz. Sıra önemlidir: önce ServerWideOffline bileşenini aktif yapıyor, ardından Exchange’in bakım bitirme scriptini çalıştırıyoruz. Script cluster node’unu devam ettirir (Resume), DatabaseCopyAutoActivationPolicy değerini Unrestricted yapar ve bu sunucudaki veritabanı kopyalarını sürdürür:

Set-ServerComponentState W25EXCNOD1 -Component ServerWideOffline -State Active -Requester Maintenance
CD $ExScripts
.\StopDagServerMaintenance.ps1 -ServerName W25EXCNOD1

Script, DatabaseCopyActivationDisabledAndMoveNow flag will be unset on the server W25EXCNOD1 mesajını verir. Bu mesaj, sunucunun üzerindeki veritabanı kopyalarının aktivasyon engelinin kaldırıldığını gösterir.

Ardından transport’u yeniden etkinleştiriyor ve servisi yeniden başlatıyoruz:

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

Draining adımında olduğu gibi burada da Restart-Service sırasında Waiting for service … to start… uyarısı görünür. Bu normaldir.

Bileşenlerin durumunu kontrol ediyoruz:

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

Çıktıda ServerWideOffline dahil bileşenlerin Active olmasını bekliyoruz. Bu laboratuvarda yalnızca ForwardSyncDaemon ve ProvisioningRps Inactive görünüyor, geri kalan bütün bileşenler Active.

Not: ForwardSyncDaemon ve ProvisioningRps bileşenlerinin Inactive görünmesi normaldir. Bu iki bileşen Office 365 ile hibrit senkronizasyonla ilgilidir. Microsoft’un ExchangeServerComponentStateChecker.ps1 betiği de hibrit olmayan sunucularda bu iki bileşeni kontrol dışında bırakır. Başka bir bileşen Inactive kaldıysa aşağıdaki Olası Sorunlar bölümündeki kurtarma komutlarına bakın. IMAP4 ve POP3 servisleri de ImapProxy ve PopProxy bileşenleri Inactive ise kapalı kalabilir.

Veritabanı Kopyalarının Senkron Olmasını Bekleme

İkinci sunucuya geçmeden önce W25EXCNOD1 üzerindeki kopyaların yeniden senkron olduğundan emin olmalıyız. Bu adımı atlarsak ikinci sunucuyu bakıma aldığımızda güncel olmayan bir kopyaya geçiş yapabiliriz:

Get-MailboxDatabaseCopyStatus -Server W25EXCNOD1 | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize
Test-ReplicationHealth -Server W25EXCNOD1

Tüm kopyaların Healthy (ya da Mounted) olduğunu, kuyruk uzunluklarının 0’a düştüğünü ve Test-ReplicationHealth satırlarının Passed döndüğünü doğruluyoruz. ContentIndexState bu laboratuvarda NotApplicable göründüğü için ölçüt olarak kuyruk uzunluklarına ve replikasyon testine bakıyoruz. Bu ekranda DB01 ve DB02 kopyaları Healthy, CopyQueueLength ve ReplayQueueLength değerleri 0, bütün Test-ReplicationHealth kontrolleri Passed ve Error sütunu boş. Kuyruklar sıfırlanana kadar birkaç dakika beklemeniz gerekebilir.

Adım 4: W25EXCNOD2 İçin Aynı Adımları Tekrarlama

W25EXCNOD1 sağlıklıysa aynı akışı W25EXCNOD2 için uyguluyoruz. Değişen tek şey sunucu adları ve yönlendirme hedefi: mesajları artık W25EXCNOD1‘e yönlendiriyoruz ve veritabanları W25EXCNOD1‘e taşınıyor. Adımlar şöyle:

Sıra Adım Konsol
1 Aktif kopyaların yerini not alma (Get-MailboxDatabaseCopyStatus -Server ...) Exchange Management Shell
2 Set-ServerComponentState W25EXCNOD2 -Component HubTransport -State Draining -Requester Maintenance ve Restart-Service MSExchangeTransport Exchange Management Shell
3 .\StartDagServerMaintenance.ps1 -ServerName W25EXCNOD2 -MoveComment "SU11 kurulumu" -PauseClusterNode Exchange Management Shell
4 Redirect-Message -Server W25EXCNOD2 -Target W25EXCNOD1.bakicubuk.com Exchange Management Shell
5 Set-ServerComponentState W25EXCNOD2 -Component ServerWideOffline -State Inactive -Requester Maintenance Exchange Management Shell
6 Bakım doğrulaması: Get-ServerComponentState, Get-MailboxServer, Get-ClusterNode, Get-Queue Exchange Management Shell
7 SU11 kurulumu ve sunucuyu yeniden başlatma Command Prompt (Run as administrator (Yönetici olarak çalıştır))
8 ServerWideOffline Active, StopDagServerMaintenance.ps1 -ServerName W25EXCNOD2 Exchange Management Shell
9 HubTransport Active ve Restart-Service MSExchangeTransport Exchange Management Shell
10 Kopya durumu ve Test-ReplicationHealth doğrulaması Exchange Management Shell

Yazıyı kısa tutmak için W25EXCNOD2 üzerindeki bakım ve kurulum adımlarının ekran görüntülerini tekrar vermiyoruz, çünkü komutlar ve çıktılar W25EXCNOD1 ile aynıdır. Aşağıda yalnızca kurulum sonrası kontrollerin W25EXCNOD2 çıktıları var.

Sunucu yeniden başladıktan sonra Disabled servis kontrolü yine boş döner:

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

Bu komut hiçbir şey döndürmemeli. Sonrasında build numarasını doğruluyoruz:

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

Build numarası 15.02.2562.056 olmalıdır:

Ardından W25EXCNOD2 bakımdan çıkarılır. Önce ServerWideOffline Active yapılır, sonra StopDagServerMaintenance.ps1 çalıştırılır:

Set-ServerComponentState W25EXCNOD2 -Component ServerWideOffline -State Active -Requester Maintenance
CD $ExScripts
.\StopDagServerMaintenance.ps1 -ServerName W25EXCNOD2

Transport yeniden etkinleştirilir ve servis yeniden başlatılır:

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

Bileşen durumlarını kontrol ediyoruz:

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


W25EXCNOD1 ile aynı sonucu görüyoruz: yalnızca ForwardSyncDaemon ve ProvisioningRps Inactive, diğer bütün bileşenler Active.

W25EXCNOD1 için yaptığımız gibi Get-MailboxDatabaseCopyStatus ve Test-ReplicationHealth komutlarını W25EXCNOD2 için de çalıştırıp kopyaların Healthy ve kontrollerin Passed olduğunu doğruluyoruz. Son dağılımı bir sonraki bölümde göstereceğiz.

Son Kontroller

Aktif Veritabanlarını Tercih Edilen Sunuculara Geri Dağıtma

İki sunucu da güncellendi, ancak veritabanlarının bir kısmı bakım sırasında taşındığı için tercih edilen sunucuda olmayabilir. Aktif kopyaları Activation Preference değerlerine göre yeniden dağıtıyoruz:

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

Başlangıçta bütün veritabanları W25EXCNOD1 üzerinde aktif (ActiveDbs 2), W25EXCNOD2 üzerinde ise iki kopya da pasif. Script, DB02‘nin Activation Preference değeri 1 olan W25EXCNOD2‘ye taşınmasını değerlendirir ve Database ‘DB02’ successfully moved from ‘W25EXCNOD1’ to ‘W25EXCNOD2’ mesajını verir. Taşıma sonrası her sunucuda 1 aktif, 1 pasif veritabanı olur. Çıktının sonunda görünen `n karakterleri scriptin biçimlendirmesinden kalan bir işarettir, işlemi etkilemez.

Summary of Moves bölümünde Successfully moved 1, Failed to move 0 ve Not moved 1 görünür. DB01 zaten tercih edilen sunucuda olduğu için NoMoveAttempted, DB02 için ise MoveSucceeded yazar. Dağılımı tekrar kontrol ediyoruz:

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

DB01 W25EXCNOD1 üzerinde, DB02 W25EXCNOD2 üzerinde Mounted ve ikisinin de ActivationPreference değeri 1. Diğer kopyalar Healthy ve ActivationPreference değerleri 2. Dağılım güncelleme öncesindeki haline döndü.

HealthChecker ile Sonucu Doğrulama

Önceki raporları ayrı tutmak için önce raporunun çıktısını taşıdıktan sonra iki sunucuyu yeniden tarıyoruz:

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

Servers Overview tablosunda W25EXCNOD1 ve W25EXCNOD2 için Exchange Version değeri Exchange SE RTM Oct26SU, Vulnerability Detected değeri None görünüyor. Server Details bölümünde W25EXCNOD1 için Build Number 15.02.2562.056 ve Exchange IU or Security Hotfix Detected listesinde KB5121608 ile KB5128895 yer alıyor. Aşağı kaydırdığımızda aynı sunucuda Vulnerability Detected satırının da None olduğunu görüyoruz:

Kurulum öncesi ve sonrası rapor şöyle karşılaştırılır:

Satır Kurulum öncesi Kurulum sonrası
Exchange Version Exchange SE RTM Sep26SU Exchange SE RTM Oct26SU (iki sunucuda)
Build Number 15.02.2562.049 15.02.2562.056
Exchange IU or Security Hotfix Detected KB5121608, Not on the latest SU uyarısı KB5121608 ve KB5128895 (Security Update for Exchange Server Subscription Edition) birlikte listelenir
Vulnerability Detected True (7 CVE) None
Server Pending Reboot False False
Exchange Server Maintenance Not in Maintenance Mode Server is not in Maintenance Mode

Rapor dosyasında W25EXCNOD2 için de aynı değerler görünür: Build Number 15.02.2562.056, Exchange Version Exchange SE RTM Oct26SU, KB5128895 listede ve Vulnerability Detected None. İki sunucuda da Enable Download Domains True, Server Pending Reboot False ve Exchange Server Maintenance satırı Server is not in Maintenance Mode.

Download Domains açığını önceki yazıda ayrıca yapılandırmıştık. Bu yapılandırma kurulu olduğu sürece rapordaki Vulnerability Detected değerinin None olması gerekir. Download Domains yapılandırması yoksa SU11 bu açığı kapatmaz ve raporda yalnızca CVE-2021-1730 görünür.

Edition (StandardEvaluation), Physical Memory ve Dynamic Memory gibi sarı satırlar 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.
  • Bakımdan çıktıktan sonra bileşen Inactive kaldı: Kurulum başarısız olduysa ya da bakım modundan çıkış eksik kaldıysa şu komutları sırayla çalıştırın:
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
  • StartDagServerMaintenance.ps1 bir adımda hata verdi: Script, başarısız olduğu durumda veritabanı taşıma dışındaki değişiklikleri geri alır. Sorunu giderip komutu yeniden çalıştırabilirsiniz.
  • Hala Mounted veritabanı görünüyor: StartDagServerMaintenance.ps1 komutunu yeniden çalıştırın. Taşıma tamamlanmadan kuruluma geçmeyin.
  • 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. 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.

Hangi Komut Hangi Konsolda Çalışır

Bu yazıda üç farklı konsol kullandık. Exchange cmdlet’leri (Get-Queue, Set-ServerComponentState, Get-MailboxDatabaseCopyStatus gibi) yalnızca Exchange Management Shell‘de tanınır. Kurulum paketini ise Command Prompt üzerinden Run as administrator (Yönetici olarak çalıştır) başlatıyoruz:

Adım Komut Konsol
HealthChecker çalıştırma .\HealthChecker.ps1 ... Exchange Management Shell (yönetici)
Sürüm tespiti ve doğrulama Get-Command ExSetup.exe ... Windows PowerShell veya Exchange Management Shell
Paket doğrulama Get-FileHash Windows PowerShell
Bekleyen restart ve disk kontrolü Test-Path, Get-PSDrive, Get-Service Windows PowerShell veya Exchange Management Shell
DAG ve kopya sağlığı Get-DatabaseAvailabilityGroup, Get-MailboxDatabaseCopyStatus, Test-ReplicationHealth Exchange Management Shell
Bakım moduna alma ve çıkarma Set-ServerComponentState, StartDagServerMaintenance.ps1, StopDagServerMaintenance.ps1 Exchange Management Shell
Kuyruk ve mesaj yönlendirme Get-Queue, Redirect-Message, Restart-Service MSExchangeTransport Exchange Management Shell
Cluster node kontrolü Get-ClusterNode Exchange Management Shell (ya da yönetici PowerShell)
SU kurulumu ExchangeSubscriptionEdition-KB5128895-x64-en.exe Command Prompt (Run as administrator (Yönetici olarak çalıştır))
Yeniden başlatma ve servis kontrolü Restart-Computer, Get-Service Windows PowerShell veya Exchange Management Shell
Veritabanı dağıtımı RedistributeActiveDatabases.ps1 Exchange Management Shell

Sonuç

DAG ortamında güvenlik güncellemesi, tek sunuculu ortamdan daha fazla adım gerektirir ama sonuçta posta erişimini kesmeden tamamlanır. Özetle akış şöyledir: HealthChecker ile önce raporunu al, paketi iki sunucuya indirip hash’ini doğrula, DAG sağlığını kontrol et, bir üyeyi bakıma al, SU11’i elevated Command Prompt üzerinden kur, sunucuyu yeniden başlat, bakımdan çıkar, kopyaların senkron olmasını bekle ve aynı adımları ikinci üye için tekrarla. Son olarak aktif veritabanlarını tercih edilen sunuculara geri dağıt ve HealthChecker ile güvenlik açıklarının kapandığını teyit et. Güncelleme sırasında iki üyeyi aynı anda bakıma almayın ve her sunucudan sonra kopyaların Healthy olduğunu doğrulamadan diğerine geçmeyin.

Kaynaklar

Bir yanıt yazın

Başa Dön