Exchange Server SE DAG Ortamında Sağlık Kontrolü: HealthChecker.ps1 ile Uçtan Uca

Merhaba

Daha önce yayınladığım Exchange Server SE Sağlık Kontrolü: HealthChecker.ps1 ile Uçtan Uca yazısında, tek sunuculu bir ortamda HealthChecker.ps1 scriptinin nasıl indirileceğini ve çalıştırılacağını anlatmıştım. Bu yazıda ise aynı işlemi Database Availability Group (DAG) yapısında, iki node ve bir File Share Witness (FSW) üzerinde uçtan uca uyguluyoruz.

DAG ortamında sağlık kontrolü, tek sunucudaki adımların iki kez tekrarlanmasından ibaret değildir. İki nedenden dolayı farklıdır:

• Yapılandırma kayması (configuration drift): İki node zaman içinde birbirinden ayrışır. Bir node’da yapılan bir düzeltme diğerinde unutulur ve fark, ancak failover olduğunda performans sorunu olarak ortaya çıkar. HealthChecker‘ın birleşik HTML raporu bu farkları yan yana gösterir.
• DAG’ın kendi sağlığı: HealthChecker sunucu bazlı çalışır. Replikasyon durumu, Cluster Quorum, Witness erişilebilirliği ve veritabanı kopya durumu gibi DAG’a özel konuları ayrıca kontrol etmeniz gerekir.

Bu yazının amacı tespit etmek ve anlamak. Raporda çıkan bulguları tek tek açıklıyor, hangisinin ne anlama geldiğini ve neden önemli olduğunu ele alıyoruz. Bulguların kapatılması ve Security Update kurulumu bir sonraki yazının konusu olacak.

Lab Topolojisi

Bu çalışmada kullandığım ortam aşağıdaki gibidir:

DAG adı EXCDAG, witness sunucu W25WITNESS‘tir. Tanık dizini W25WITNESS üzerinde C:\DAGFileShareWitnesses\EXCDAG, bu dizini yayınlayan paylaşımın adı ise EXCDAG.bakicubuk.com‘dur. Dizin adı ile paylaşım adının farklı olması normaldir; yazının sonundaki witness kontrollerinde bu ayrım önem kazanacak.

Domain bakicubuk.com, AD Site Default-First-Site-Name, işletim sistemi her iki node’da Windows Server 2025 Datacenter (OS Build 26100.33296) ve Exchange sürümü Exchange SE RTM, build 15.02.2562.017.

Her node’da iki adapter var: Ethernet0 MAPI (istemci) ağı, Ethernet1 ise replikasyon ağı. Bu ayrım, raporu yorumlarken önemli olacak.

1. Adım: HealthChecker.ps1 Hazırlığı

Scripti her iki node üzerinde de değil, yönetim yapacağınız tek bir Node üzerinde çalıştırmak yeterlidir. HealthChecker uzak sunuculardan da veri toplayabilir. Ben W25EXCNOD1 üzerinden ilerliyorum.

Öncelikle sunucuda bir çalışma klasörü oluşturalım (yoksa):

Windows PowerShell’i Run as administrator (Yönetici olarak çalıştır) ile açıp:

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

Scripti doğrudan resmi GitHub sürümünden indirin (her zaman en güncel sürümü çeker):

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

İndirilen dosya internetten geldiği için block işareti taşıyabilir. Çalıştırırken hata almamak adına engeli kaldırın:

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

Windows, internetten indirilen dosyalara güvenlik amacıyla Mark of the Web (MOTW) adı verilen bir işaret ekler. Bu işaret, dosyanın harici bir kaynaktan geldiğini belirtir ve PowerShell, imzalı olsa bile bu tür dosyaları çalıştırmadan önce ek güvenlik uyarısı verebilir ya da execution policy nedeniyle engelleyebilir. Unblock-File cmdlet’i bu işareti kaldırarak scriptin sorunsuz çalışmasını sağlar. Dosyanın kaynağına güvendiğinizden (bu örnekte Microsoft’un resmi GitHub deposundan indirildiğinden) emin olduğunuz için bu işaretlemeyi güvenle kaldırabilirsiniz.

İmza Doğrulaması

İnternetten indirilen bir scripti Exchange sunucusunda çalıştırmadan önce imzasını mutlaka doğrulayın. Status değeri Valid, imzalayan ise Microsoft Corporation olmalıdır.

Get-AuthenticodeSignature -FilePath "C:\Scripts\HealthChecker.ps1" | Select-Object Status, SignerCertificate | Format-List

İsterseniz oturumunuz için execution policy’yi geçici olarak esnetebilirsiniz (kalıcı değişiklik yapmadan):

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

PowerShell, imzasız veya harici scriptlerin çalıştırılmasını execution policy ile kontrol eder. Varsayılan olarak bir Windows Server’da bu politika Restricted veya RemoteSigned olabilir ve script çalıştırmayı engelleyebilir. Buradaki komutta önemli nokta -Scope Process parametresidir: bu, politikayı yalnızca o an açık olan PowerShell/EMS (Exchange Management Shell) oturumu için değiştirir. Oturumu kapattığınızda ayar otomatik olarak eski haline döner, yani sunucunun genel güvenlik politikasında kalıcı bir değişiklik yapmazsınız. RemoteSigned değeri ise yerel scriptlerin serbestçe, internetten inen scriptlerin ise yalnızca geçerli bir dijital imzaya sahipse çalışmasına izin verir. HealthChecker Microsoft imzalı olduğu için bu ayarla sorunsuz çalışır. Bu yaklaşım, sistem genelinde kalıcı bir politika gevşetmesi yapmadan işi güvenli biçimde halletmenizi sağlar.

2. Adım: DAG Genelinde Sağlık Kontrolü

Tek sunucu yerine DAG’daki tüm Exchange sunucularını tek seferde taramak istiyoruz.

Exchange Management Shell‘i Run as administrator (Yönetici olarak) açın ve çalışma klasörüne geçin:

Her iki node için veri toplama:

cd C:\Scripts
.\HealthChecker.ps1 -Server "W25EXCNOD1"
.\HealthChecker.ps1 -Server "W25EXCNOD2"

Script her sunucu için bir TXT ve bir XML dosyası üretir; iki node’lu bu ortamda C:\Scripts klasöründe toplam dört dosya oluşur.

• TXT dosyası: PowerShell’deki çıktının aynısıdır; e-postaya eklemek veya arşivlemek için pratiktir.
• XML dosyası: HTML rapor üretmek için kullanılan veri dosyasıdır. Windows’ta .xml uzantısı Edge ile ilişkilendirildiği için Explorer’ın “Type” sütununda “Microsoft Edge HTML Document” görünebilir; dosya yine de XML’dir.

Alternatif: organizasyondaki tüm sunucuları otomatik tarama

Sunucu sayısı arttıkça tek tek yazmak yerine pipeline kullanmak daha pratiktir:

Exchange Management Shell‘i Run as administrator (Yönetici olarak) açın ve çalışma klasörüne geçin:

cd C:\Scripts
Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -Match "^Version 15"} | .\HealthChecker.ps1

Çıktılar bu yöntemde de aynıdır; yalnızca dosya adındaki zaman damgası değişir.

Sadece DAG üyelerini taramak isterseniz:

cd C:\Scripts
(Get-DatabaseAvailabilityGroup EXCDAG).Servers | ForEach-Object { .\HealthChecker.ps1 -Server $_.Name }

Çıktılar bu yöntemde de aynıdır; yalnızca dosya adındaki zaman damgası değişir.

Birleşik HTML raporu üretme

DAG’da HealthChecker‘ın asıl faydası burada ortaya çıkıyor. Toplanan XML dosyalarından tek bir karşılaştırmalı rapor üretiliyor ve iki node’un ayarları yan yana geliyor.

cd C:\Scripts
.\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "EXCDAG-Report.html"
.\EXCDAG-Report.html

Yukarıdaki iki satırı tek seferde yapıştırırsanız önce .\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "EXCDAG-Report.html komutunu çalışır. Bu satır tamamlandıktan sonra Enter tuşuna basarak .\EXCDAG-Report.html komutunun çalışmasını sağlayabilirsiniz.

XML dosyalarını ayrı bir klasörde topluyorsanız:

cd C:\Scripts
.\HealthChecker.ps1 -BuildHtmlServersReport -XMLDirectoryPath "C:\Scripts\Reports" -HtmlReportFile "EXCDAG-Report.html"

Sık kullanılan parametreler

Açık (vulnerability) raporu

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

3. Adım: Raporu Okuma

HealthChecker çıktısı renk kodludur.

DAG ortamında raporu okurken üç şeye özellikle dikkat edin:

1. Kırmızı satırların ikisinde de aynı olması. Bir node’da kırmızı, diğerinde yeşil olan bir madde varsa orada yapılandırma kayması var demektir.
2. Donanım ve bellek farkları. İki node’un RAM, işlemci ve NIC yapılandırması aynı olmalıdır. Aksi halde failover sonrası performans düşer.
3. Exchange build numaraları. İki node’un build numarası birbirinden farklıysa, güncelleme çalışmasına başlamadan önce bunu not edin.

Build numaralarını hızlıca karşılaştırmak için:

Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion
Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}

4. Adım: EXCDAG Raporunun Çıktısı

Şimdi asıl konuya geliyoruz: raporda ne çıktı ve bunlar ne anlama geliyor.

Servers Overview

Raporun en üstündeki özet tablo, iki node’u yan yana koyuyor:

İlk bakışta görülen şu: iki node birebir aynı. DAG açısından bu iyi haber, yapılandırma kayması yok. Kötü haber ise her iki node’da da güvenlik açığı tespit edilmiş olması.

Kırmızı Bulgular

Raporda dört kırmızı madde var ve dördü de her iki node’da aynı.

Üçüncü maddeye dikkat etmek gerekiyor, çünkü sık yanlış anlaşılıyor. Registry tarafı aslında doğru: DisabledComponents değeri 0, yani IPv6 devre dışı bırakılmamış. Sorun NIC seviyesinde: adapter özelliklerinden IPv6 binding’i (ms_tcpip6) kaldırılmış. Ortaya yarı yapılandırılmış bir durum çıkıyor ve Exchange bunu desteklemiyor. Microsoft’un önerisi IPv6’yı hiç kapatmamaktır.

Sarı Bulgular

On birinci madde teknik bir hata gibi durmuyor ama lab’ın ömrünü belirleyen madde bu. Deneme süresi dolduğunda Exchange servisleri durur, bu yüzden bir kenara not etmekte fayda var.

On ikinci madde ise DAG açısından anlamlı: iki node arasındaki tek fark bu. Bekleyen bir restart varken güvenlik güncellemesi kurmak, kurulumun yarıda kalmasına yol açabilir.

Uyumlu Alanlar

Rapor sadece sorunları göstermiyor. Aşağıdaki kalemler yeşil, yani öneriyle uyumlu:

Güvenlik Açıkları

Vulnerability bölümü build 15.02.2562.017 üzerinde açık olan 29 CVE listeliyor:

CVE-2021-1730, 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-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

Listenin ilk maddesi olan CVE-2021-1730 diğerlerinden ayrışıyor. Bu açık bir Security Update ile değil, Download Domains yapılandırmasıyla kapatılıyor. Raporda Enable Download Domains = False olarak görünüyor. Diğer 28 CVE ise güncel SU kurulumuyla kapanacak.

Raporun Göstermediği Bir Ayrıntı

HealthChecker bunu bir bulgu olarak işaretlemiyor, ancak ağ bölümüne dikkatli bakınca görülüyor: Ethernet1 (192.168.2.x) replikasyon ağı olmasına rağmen her iki node’da da Registered In DNS = True. Üstelik W25EXCNOD2‘de bu arayüzde bir DNS sunucusu da tanımlı.

DAG’da replikasyon NIC’lerinin DNS’e kaydolmaması, gateway ve DNS sunucusu tanımlanmaması önerilir. Aksi halde istemciler MAPI trafiğini replikasyon ağına yönlendirmeye çalışabilir. Raporu okurken, scriptin renklendirmediği satırlara da bakmakta fayda var.

Get-DnsClient | Select-Object InterfaceAlias, RegisterThisConnectionsAddress
Get-DatabaseAvailabilityGroupNetwork -Identity EXCDAG | Format-List Name,Subnets,ReplicationEnabled,MapiAccessEnabled

5. Adım: DAG’a Özel Sağlık Kontrolleri

HealthChecker‘ın kapsamadığı, DAG’a özel kontroller aşağıdadır. Her birinin beklenen değeri tabloda verilmiştir.

DAG yapılandırması ve witness durumu

Get-DatabaseAvailabilityGroup EXCDAG -Status | Format-List Name,Servers,WitnessServer,WitnessDirectory,PrimaryActiveManager,OperationalServers

OperationalServers alanında her iki node da görünmelidir. Bir node eksikse, o node cluster’dan düşmüş demektir.

Replikasyon sağlığı

Test-ReplicationHealth -Identity W25EXCNOD1
Test-ReplicationHealth -Identity W25EXCNOD2

Sadece başarısız olanları görmek için:

Test-ReplicationHealth -Identity W25EXCNOD1 | Where-Object {$_.Result.ToString() -ne "Passed"}
Test-ReplicationHealth -Identity W25EXCNOD2 | Where-Object {$_.Result.ToString() -ne "Passed"}

Veritabanı kopya durumu

Get-MailboxDatabaseCopyStatus * | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState -AutoSize

Aktif kopyaların hangi node’da olduğunu görmek için:

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

Bu çıktı, bir sonraki yazıda hangi node’dan başlayacağımızı belirleyecek: güncelleme her zaman pasif node’dan başlar.

Cluster ve Quorum durumu

Get-ClusterNode
Get-ClusterQuorum | Format-List *
Get-ClusterResource

İki node’lu bir DAG’da Quorum modeli Node and File Share Majority olmalı ve witness kaynağı Online görünmelidir.

File Share Witness erişilebilirliği

Get-ClusterResource | Where-Object {$_.ResourceType -eq "File Share Witness"} |
    Format-List Name,State,OwnerNode

Genel sunucu sağlığı

Get-ServerHealth -Identity W25EXCNOD1 | Where-Object {$_.AlertValue -ne "Healthy"}
Get-ServerHealth -Identity W25EXCNOD2 | Where-Object {$_.AlertValue -ne "Healthy"}

Bu komut, durumu Healthy olmayan tüm monitör tanımlarını listelediği için çıktı ilk bakışta uzun ve ürkütücü görünür. Satırlara bakarken State sütununa dikkat edin: değeri NotApplicable ise o monitör henüz hiç veri toplamamış demektir, yani gerçek bir alarm değildir. Unknown değeri de aynı şekilde ölçüm yok anlamına gelir. Gerçekten müdahale gerektiren durumları görmek için özet rapora bakmak daha doğrudur:

Sağlık Kontrolü Kontrol Listesi

Düzenli Sağlık Kontrolü

Sağlık kontrolünü sadece güncelleme öncesinde değil, düzenli aralıklarla da yapmanızı öneririm. Aşağıdaki komutla haftalık çalışan bir zamanlanmış görev oluşturabilirsiniz.

Burada dikkat edilmesi gereken bir nokta var: HealthChecker.ps1 Exchange Management Shell ister. Zamanlanmış görev düz PowerShell.exe ile başlatıldığında Exchange cmdlet’leri yüklü olmaz ve rapor eksik veriyle üretilir. Bu yüzden görevin komutunda önce Exchange ortamını yüklüyoruz:

$cmd = ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; " +
       "Connect-ExchangeServer -auto; " +
       "C:\Scripts\HealthChecker.ps1 -Server W25EXCNOD1,W25EXCNOD2"

$action = New-ScheduledTaskAction -Execute "PowerShell.exe" `
  -Argument "-NonInteractive -ExecutionPolicy Bypass -Command `"$cmd`"" `
  -WorkingDirectory "C:\Scripts"

$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 06:00

Register-ScheduledTask -TaskName "Exchange HealthChecker - EXCDAG" `
  -Action $action -Trigger $trigger -RunLevel Highest -User "BAKICUBUK\svc-healthchecker" -Password "********"

Sonuç

EXCDAG ortamında yaptığımız sağlık kontrolü, 4 Kırmızı ve 10 Sarı bulgu ortaya çıkardı. İki node’un yapılandırması neredeyse birebir aynı olduğu için yapılandırma kayması yok; tek fark W25EXCNOD2 üzerindeki bekleyen restart.

DAG ortamında HealthChecker.ps1, iki node arasındaki farkları tek bir raporda görmenizi sağlıyor. Ancak scriptin kapsamı sunucu düzeyinde kalıyor; replikasyon sağlığı, Quorum ve Witness durumu gibi DAG’a özel konuları ayrıca kontrol etmeniz gerekiyor. Bir de scriptin renklendirmediği satırlara bakmakta fayda var; replikasyon NIC’inin DNS kaydı buna iyi bir örnek.

Bir sonraki yazıda bu bulguları sırayla kapatacağız: hangi düzeltmenin restart gerektirdiği, hangilerinin organizasyon genelinde bir kez uygulandığı, node’ların hangi sırayla bakıma alınacağı ve son olarak SU9 (KB5121573) kurulumu.

Başka bir yazımızda görüşmek dileğiyle…