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.

Çalışma dizini oluşturma

Ö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

Scriptin son sürümünü indirme

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"

Dosya engelini kaldırma

İ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ğrulama

İ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

Oturuma özel execution policy

İ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.

Script sürümünü kontrol etme

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

Bu çalışmada kullandığım sürüm: Exchange Health Checker v26.08.11.1651

Hangi Shell’de Çalıştırmalı?

Bu soru sık geliyor, o yüzden ayrı bir başlık açmakta fayda var. Microsoft’un dokümantasyonundaki ifade net: This script must be run as Administrator in Exchange Management Shell on an Exchange Server.

Script kendi içinde bir shell kontrolü yapıyor ve Exchange sunucusunda düz Windows PowerShell’den başlatıldığında Exchange ortamını yüklemeye çalışıyor. Çoğu zaman da başarılı oluyor. Ancak Get-ExchangeServer, Get-OwaVirtualDirectory gibi cmdlet’lere ulaşamadığı durumlarda raporu eksik veriyle üretiyor ve bunu her zaman açık bir hata olarak vermiyor. Eksik rapor, hatalı rapordan daha tehlikelidir.

Ayrım aslında basit: script hangi cmdlet’leri kullanıyor?

EMS (Exchange Management Shell) zaten Windows PowerShell 5.1’in Exchange cmdlet’leri yüklenmiş hali, yani bir üst küme. Exchange sunucusunda yönetici olarak açılmış EMS (Exchange Management Shell) kullanmanın hiçbir dezavantajı yok; pratik kural bu.

Üç noktaya dikkat edin:

• PowerShell 7 kullanmayın. On-premises Exchange yönetim cmdlet’leri PowerShell 7’de desteklenmiyor, Windows PowerShell 5.1’e bağlı.
• Yetki iki ayrı katman. Local Administrator olmak Exchange hakkı vermez, Organization Management üyeliği de sunucuda yönetici yapmaz. Registry yazmak için elevation, Set-OrganizationConfig için RBAC (Role-Based Access Control) gerekir; ikisi birden açık olmalıdır.
• Nesneler deserialized gelir. EMS implicit remoting kullandığı için dönen nesneler seri hale getirilmiş kopyalardır. Property okuyabilirsiniz ama nesnenin metotlarını çağıramazsınız. Kendi scriptinizi yazarken en sık takılınan yer burasıdır.

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

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

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:

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.

Çıktı  EXCDAG-Report.html olarak oluşturulacaktır.

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ı

EXCDAG-Report.html dosyasını tarayıcıda açtığınızda, HealthChecker.ps1‘in her iki node için ürettiği raporu görürsünüz. Bu rapor Exchange Health Checker v26.09.08.1649 sürümüyle üretilmiştir; kendi ortamınızda farklı bir sürüm görüyorsanız script’i -ScriptUpdateOnly ile güncelleyip tekrar çalıştırmanız faydalı olur.

Servers Overview

İ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ı.

Sarı Bulgular

Onuncu maddeyi olduğu gibi kabul etmeyin. 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, raporda kapalı gibi görünüyor. Gerçek durumu şu komutla teyit edebilirsiniz:

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

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.

İki Node Arasındaki Fark

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 38 CVE listeliyor. 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 37 CVE ise güncel SU (Security Update) kurulumuyla kapanacak; her birinin türünü (Elevation of Privilege, Spoofing, RCE vb.) MSRC danışma sayfalarından teyit ederek Kapanma Yöntemi sütununa ekledim, böylece tabloya bakan biri hangi CVE’nin ne tür bir risk taşıdığını da görebiliyor.

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

EXCDAG-Report.html dosyasını açarak detaylı kontrol edebilirsiniz.

W25EXCNOD1 isimli sunucumuz üzerindeki bulgular

W25EXCNOD2 isimli sunucumuz üzerindeki bulgular

Her bir CVE’nin ayrıntısı EXCDAG-Report.html içindeki bağlantılardan (MSRC advisory) incelenebilir; yazıda tek tek açıklamak yerine sayıyı ve kapanma yöntemini vermek daha okunur oluyor.

Raporun Göstermediği Bir Ayrıntı

HealthChecker bu tür bir ayrıntıyı bulgu olarak işaretlemez; ağ bölümünü satır satır okumak gerekir. Replikasyon ağı (Ethernet1, 192.168.2.x) DAG’da yalnızca node’lar arası veritabanı replikasyonu için kullanılır; bu arayüzün DNS’e kayıtlı olmaması ve üzerinde bir DNS sunucusu tanımlı olmaması önerilir. Aksi halde istemciler MAPI trafiğini yanlışlıkla replikasyon ağına yönlendirmeye çalışabilir.

Kendi ortamınızda bu ayrıntıyı kontrol etmek için:

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

Get-DnsClient çıktısındaki RegisterThisConnectionsAddress = True değeri her adapter için görünse de bu sadece kayıt denenir mi ayarıdır; adapterde DNS sunucusu tanımlı değilse fiilen kayıt oluşmaz. Asıl teyit HealthChecker raporundaki Registered In DNS alanıdır.

Eğer replikasyon arayüzünde bu alan True görünüyorsa veya arayüzde bir DNS sunucusu tanımlıysa, adaptörün ağ ayarlarından (veya Set-DnsClient -InterfaceAlias "Ethernet1" -RegisterThisConnectionsAddress $false komutuyla) kaydı kapatıp DNS sunucu adresini boşaltmanız gerekir.

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

W25EXCNOD1 isimli sunucumuz üzerindeki çıktı:

W25EXCNOD2 isimli sunucumuz üzerindeki çıktı:

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.

Ekran görüntünüzdeki QuorumType alanı Majority olarak görünüyor, NodeAndFileShareMajority değil. Bunun nedeni bir yapılandırma sorunu değil; Microsoft, FailoverClusters modülünde QuorumType alanını zaman içinde sadeleştirdi. Eskiden NodeMajority, NodeAndDiskMajority, NodeAndFileShareMajority gibi detaylı değerler dönerken, güncel sürümlerde (Windows Server 2025 dahil) hepsi tek bir genel Majority değeri olarak raporlanıyor. Witness’ın gerçek türü artık QuorumType alanında değil, QuorumResource alanında görünüyor.

Önerilen düzeltme:

Get-CimInstance -Namespace root\MSCluster -ClassName MSCluster_ClusterConfiguration | Select-Object QuorumType

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ı ayırt etmek için sadece AlertValue‘ya değil, State sütununa da birlikte bakmak daha güvenilir bir yöntemdir.

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 7 Sarı bulgu ortaya çıkardı. İki node’un yapılandırması neredeyse birebir aynı olduğu için yapılandırma kayması yok; tek fark W25EXCNOD1‘de Visual C++ 2013 x64 paketinin bulunamaması (W25EXCNOD2‘de ise sadece eski bir sürümde kurulu olması).

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 SU10 (KB5121608) kurulumu.

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