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

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

Bulgu Envanteri

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:

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

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ı:

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

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

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

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.

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:

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

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

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:

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

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

İkinci komut boş dönmeli. Dönmüyorsa o node aktif kopyaları barındırıyor demektir; ya sırayı değiştirin ya da önce Move-ActiveMailboxDatabase ile kontrollü devredin.

Boş dönmüyorsa, aktif kopyayı diğer node’a devredin ve tekrar kontrol edin:

Move-ActiveMailboxDatabase -Identity DB02 -ActivateOnServer W25EXCNOD1
Get-MailboxDatabaseCopyStatus -Server W25EXCNOD2 | Where-Object {$_.Status -eq "Mounted"}

İkinci komut artık boş dönmeli. Dönmüyorsa devam etmeyin, sebebini araştırın.

Move-ActiveMailboxDatabase -Identity DB02 -ActivateOnServer W25EXCNOD1 komutu sonrası çıktı. DB01 ve DB02’nin aktif kopyaları artık ikisi de W25EXCNOD1‘de (ActiveCopy: True, Status: Mounted); W25EXCNOD2‘deki her iki kopya da Healthy ve ActiveCopy: False durumunda, yani W25EXCNOD2 tamamen pasif hale geldi. CopyQueueLength ve ReplayQueueLength her satırda 0, önceki geçici replay gecikmesi de kapanmış. İkinci komut (Get-MailboxDatabaseCopyStatus -Server W25EXCNOD2 | Where-Object {$_.Status -eq "Mounted"}) boş döndü beklenen sonuç bu; W25EXCNOD2 artık bakım moduna alınabilir durumda.

2. Hedef node kopyaları kabul edebilecek durumda mı?

Kopyalar diğer node’a taşınacak, o node’un bileşenleri hazır olmalı.

Get-ServerComponentState W25EXCNOD1 | Where-Object {$_.State -ne "Active"}

ForwardSyncDaemon ve ProvisioningRps normalde Inactive’dir, sorun değil. Listede HighAvailability veya ServerWideOffline çıkıyorsa durun; taşıma başarısız olur. Bu iki bileşen, önceki başarısız bir bakım denemesinden kalmış olabilir.

3. Kopyalar sağlıklı mı, kuyruklar boş mu?

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

İki komut da boş dönmeli. DisconnectedAndHealthy, Failed veya FailedAndSuspended bir kopya varken bakıma almayın.

4. Cluster ve quorum ayakta mı?

Get-ClusterNode | Format-Table Name,State -AutoSize
Get-ClusterQuorum

Her iki node Up, quorum kaynağı File Share Witness olarak görünmeli.

Bakım moduna alma

Veritabanlarını önceden elle taşımanıza gerek yok. StartDagServerMaintenance.ps1 sırasıyla HubTransport’u Draining’e alır, kuyruktaki mesajları diğer node’a yönlendirir, cluster node’unu askıya alır, DatabaseCopyActivationDisabledAndMoveNow değerini $true yapar ve DatabaseCopyAutoActivationPolicy değerini Blocked olarak ayarlar, en son ServerWideOffline bileşenini Inactive yapar. Aktif kopyaları taşıyan, dördüncü maddedeki ayarın MoveNow kısmıdır.

cd $exscripts
.\StartDagServerMaintenance.ps1 -ServerName W25EXCNOD2

Doğrulama:

Get-ServerComponentState W25EXCNOD2 | Format-Table Component,State -AutoSize
Get-ClusterNode W25EXCNOD2 | Format-List Name,State
Get-Queue -Server W25EXCNOD2

Beklenen: Get-ServerComponentState çıktısında ServerWideOffline: Inactive görünmeli. ServerWideOffline bir tür ana anahtardır: Inactive olduğunda altındaki neredeyse tüm bileşenler (HubTransport, FrontendTransport, EcpProxy, EwsProxy, OwaProxy,MapiProxy gibi tüm proxy’ler dahil) de otomatik olarak Inactive raporlanır bu normaldir, tek tek kontrol etmenize gerek yok. Bunun tek istisnası Monitoring ve RecoveryActionsEnabled‘dır; bunlar node bakımdayken bile Active kalmalı, çünkü Managed Availability’nin sağlık izleme ve kendi kendini onarma mekanizmaları offline bir sunucuda da çalışmaya devam eder. Get-ClusterNode çıktısında State: Paused görünmeli Up kalıyorsa node askıya alınmamış demektir, devam etmeyin. Get-Queue -Server çıktısında MessageCount düşük/0 olmalı; yüksekse kuyruk henüz boşalmamıştır, B1’e geçmeden bekleyin.

B1. PageFile ayarı (Bulgu 1, Kırmızı)

Rapordaki hata: System is set to automatically manage the PageFile Size: 0MB. Recommended PageFile size is 25% (8192MB) of the total system memory (32768MB).

Otomatik yönetim açıkken Win32_PageFileSetting boş dönebilir. Aşağıdaki blok her iki durumu da ele alıyor:

$cs = Get-CimInstance -ClassName Win32_ComputerSystem
Set-CimInstance -InputObject $cs -Property @{AutomaticManagedPagefile = $false}

$pf = Get-CimInstance Win32_PageFileSetting
if ($null -eq $pf) {
    New-CimInstance -ClassName Win32_PageFileSetting -Property @{Name="C:\pagefile.sys"; InitialSize=8192; MaximumSize=8192}
} else {
    Set-CimInstance -InputObject $pf -Property @{InitialSize=8192; MaximumSize=8192}
}

Doğrulama (restart sonrası kesinleşir):

Get-CimInstance Win32_ComputerSystem | Select-Object AutomaticManagedPagefile
Get-CimInstance Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize

B2. TCPKeepAlive (Bulgu 2, Kırmızı)

Rapordaki hata: Not Set. Without this value the KeepAliveTime defaults to two hours.

New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters" -Name "KeepAliveTime" -PropertyType DWORD -Value 1800000 -Force

Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters" -Name "KeepAliveTime"

Beklenen: KeepAliveTime = 1800000 (30 dakika)

B3. IPv6 yapılandırması (Bulgu 3, Kırmızı)

Rapordaki hata: IPv6 is disabled on some NIC level settings but not fully disabled. DisabledComponents registry value currently set to ‘0’.

Yani registry tarafı doğru (DisabledComponents = 0), sorun NIC seviyesinde IPv6 binding’inin kaldırılmış olması. Exchange bu yarı devre dışı durumu desteklemez.

Önce mevcut durumu görün:

Get-NetAdapterBinding -ComponentID ms_tcpip6 | Select-Object Name, DisplayName, Enabled

Her iki adapter (Ethernet0 ve Ethernet1) için binding’i etkinleştirin:

Enable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6
Get-NetAdapterBinding -ComponentID ms_tcpip6 | Select-Object Name, Enabled

Registry değerini de kontrol edin; 0 doğru değerdir, farklıysa kaldırın:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name "DisabledComponents" -ErrorAction SilentlyContinue

Son durumu kontrol edin:

Get-NetAdapterBinding -ComponentID ms_tcpip6 | Select-Object Name, DisplayName, Enabled

Beklenen: her iki adapter için Enabled = True

B4. Visual C++ Redistributable (Bulgu 7 ve node farkı, Sarı)

Visual C++ 2012 tarafında durum her iki node’da aynı: mevcut sürüm eski (11.0.50727), ikisinde de güncelleme gerekiyor. Visual C++ 2013 tarafında ise node’lar arasında fark var:

Exchange, Visual C++ 2012 ve 2013 Redistributable paketlerini özellikle arar; daha yeni sürümler (2015-2022) bunların yerine geçmez. Her iki paket için de hedef sürüm aynıdır:

Güncel indirme bağlantıları için: Microsoft Visual C++ Redistributable latest supported downloads

Kurulum sonrası doğrulama:

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall","HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" |
  Get-ItemProperty | Where-Object { $_.DisplayName -like "*Visual C++*Redistributable*" } |
  Select-Object DisplayName, DisplayVersion | Sort-Object DisplayName

Kurulum sonrası her iki node’da da VC++ 2012 ve 2013 aynı hedef sürümde olmalı; node’lar arasındaki tek fark burada kapanmış olur.

B5. Sleepy NIC (Bulgu 8, Sarı)

Her iki adapter için güç yönetimi kapatılmalı.

Get-NetAdapter -Physical | Where-Object { $_.Status -eq "Up" } | ForEach-Object {
    Get-NetAdapterPowerManagement -Name $_.Name | ForEach-Object {
        $_.AllowComputerToTurnOffDevice = "Disabled"
        $_ | Set-NetAdapterPowerManagement
    }
}

Get-NetAdapter -Physical | ForEach-Object { Get-NetAdapterPowerManagement -Name $_.Name | Select-Object Name, AllowComputerToTurnOffDevice }

Beklenen: AllowComputerToTurnOffDevice = Disabled veya Unsupported

B5b. Common Services Not Running (Bulgu 9, Sarı)

Rapor, MSComplianceAudit servisinin StartType: Automatic olarak ayarlı olmasına rağmen çalışmadığını gösteriyor. Servisin durumunu kontrol edin:

Get-Service MSComplianceAudit

Durmuşsa başlatın; bu servisin başlatılması restart gerektirmez:

Start-Service MSComplianceAudit
Get-Service MSComplianceAudit | Select-Object Name,Status,StartType

Beklenen: Status = Running, StartType = Automatic

B6. Replikasyon NIC’i ve DAG Ağ Ayrımı (Kontrol)

HealthChecker bunu bulgu olarak işaretlemiyor; ağ bölümünü satır satır okumak gerekiyor. Replikasyon NIC’i (Ethernet1) 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ı gerekir.

Bu, kozmetik bir ayrıntı değil. Exchange DAG ağlarını otomatik keşfederken NIC’lerin yapılandırmasına bakar. Replikasyon NIC’i MAPI NIC’i gibi yapılandırılmışsa ikisini ayıramaz, tek ağ altında birleştirir ve Misconfigured işaretler. Sonuç, Test-ReplicationHealth çıktısında ClusterNetwork kontrolünün başarısız olması ve kopyaların DisconnectedAndHealthy duruma düşmesidir.

Kendi ortamınızda kontrol edin:

Get-DnsClient | Select-Object InterfaceAlias, RegisterThisConnectionsAddress
Get-ClusterNetwork | Format-Table Name,State,Role,Address,AddressMask -AutoSize
Get-ClusterNetworkInterface | Format-Table Name,Node,Network,State,Adapter,Address -AutoSize
Get-DatabaseAvailabilityGroupNetwork -Identity EXCDAG | Format-List Name,Subnets,Interfaces,ReplicationEnabled,MapiAccessEnabled

Sağlıklı bir iki ağlı DAG’da Get-DatabaseAvailabilityGroupNetwork iki ağ döndürür ve replikasyon NIC’i için Registered In DNS = False, DNS sunucusu alanı boş olmalıdır. Get-DnsClient çıktısındaki RegisterThisConnectionsAddress = True 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.

Bu ortamda kontrol sonucu: her iki node’da da Ethernet1 için Registered In DNS = False ve DNS Server alanı boş, yani replikasyon arayüzü zaten doğru yapılandırılmış; ek bir işlem gerekmiyor.

Eğer kendi ortamınızda bu alan True görünüyorsa veya arayüzde bir DNS sunucusu tanımlıysa, iki adımla düzeltebilirsiniz.

Adım 1: Replikasyon NIC’ini temizleyin. Her iki node üzerinde ayrı ayrı, pasif node’dan başlayarak:

Set-DnsClient -InterfaceAlias "Ethernet1" -RegisterThisConnectionsAddress $false
Set-DnsClientServerAddress -InterfaceAlias "Ethernet1" -ResetServerAddresses
Get-NetIPConfiguration -InterfaceAlias "Ethernet1"

Replikasyon NIC’inde default gateway, DNS sunucusu ve DNS kaydı olmamalıdır. Tek sahip olması gereken şey IP adresi ve alt ağ maskesidir.

Adım 2: Cluster ağ rolünü ayarlayın. Replikasyon ağının rolü Cluster Only, MAPI ağının rolü ClusterAndClient olmalıdır. Hangi cluster network’ün hangi alt ağa karşılık geldiğini yukarıdaki çıktıdan doğrulayın:

(Get-ClusterNetwork "Cluster Network 1").Role = 1
Get-ClusterNetwork | Format-Table Name,State,Role,Address -AutoSize

Rol değerleri: 0 = cluster kullanmaz, 1 = yalnızca cluster iletişimi (Cluster Only), 3 = cluster ve istemci (ClusterAndClient).

B7. Yeniden başlatma

Bu adım, plandaki tüm restart gerektiren maddeleri tek seferde kapatır. Her node için bir kez yapılır ve node bakım modundayken gerçekleştiği için kullanıcı tarafında kesinti oluşmaz.

Yeniden başlatmanın kapsadıkları:

Restart-Computer

Sunucu ayağa kalktıktan sonra Exchange servislerinin başladığını doğrulayın:

Get-Service MSExchange* | Where-Object {$_.StartType -eq "Automatic" -and $_.Status -ne "Running"}

Çıktı boş dönmelidir.

B8. Bakım modundan çıkma

cd $exscripts
.\StopDagServerMaintenance.ps1 -ServerName W25EXCNOD2

Doğrulama:

Get-ServerComponentState W25EXCNOD2 | Format-Table Component,State -AutoSize
Get-ClusterNode
Test-ReplicationHealth -Identity W25EXCNOD2
Get-MailboxDatabaseCopyStatus -Server W25EXCNOD2

Kopyalar Healthy duruma gelene ve CopyQueueLength sıfırlanana kadar ikinci node’a geçmeyin.

B9. İkinci node

Aktif kopyaları güncellenmiş node’a taşıyın, ardından B0 – B8 adımlarını ikinci node için tekrarlayın. B0’daki dört ön kontrolü atlamayın; bu kez hedef node az önce bakımdan çıkan node olacağı için Get-ServerComponentState çıktısında beklenmedik bir Inactive bileşen bulunmadığını doğrulayın.

Move-ActiveMailboxDatabase -Server W25EXCNOD1 -ActivateOnServer W25EXCNOD2 -Confirm:$false
Get-MailboxDatabaseCopyStatus * | Where-Object {$_.Status -eq "Mounted"} | Format-Table Name,MailboxServer -AutoSize

Faz C: Doğrulama

C1. DAG sağlığı

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

C2. Kopyaları dengeleme

cd $exscripts
.\RedistributeActiveDatabases.ps1 -DagName EXCDAG -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution -Confirm:$false

Script’in çıktısı üç bölümden oluşur ve okunması gereken sıra şudur: Starting Server Distribution, çalışmaya başlamadan önceki dağılımı gösterir (bu ortamda W25EXCNOD2 üzerinde 2 aktif, W25EXCNOD1 üzerinde 0 aktif kopya vardı, çünkü tüm bakım süreci boyunca aktif kopyalar sırayla W25EXCNOD2‘ye taşınmıştı). Starting Database Moves, script’in tercih listesine (PreferenceCountList) göre hangi veritabanını hangi node’a taşımaya çalıştığını satır satır gösterir; burada DB01 için AP = 2 olan W25EXCNOD2‘den AP = 1 olan W25EXCNOD1‘e taşıma denendi ve Database 'DB01' successfully moved from 'W25EXCNOD2' to 'W25EXCNOD1' mesajıyla başarılı oldu. Summary of Moves bölümündeki DbName detaylarında DB01 için MoveStatus: MoveSucceeded görünürken, DB02 için MoveStatus: NoMoveAttempted ve IsOnMostPreferredCopy: True görünür; yani DB02 zaten en tercih edilen kopyasında olduğu için script ona hiç dokunmadı. Son olarak Ending Server Distribution, her iki node için de 1 Active / 1 Passive dağılımı gösterir. Bu, DAG’ın artık aktivasyon tercihine göre tam dengeli olduğunu ve Faz 0’daki başlangıç durumuna döndüğünü doğrular; Successfully moved: 1, Failed to move: 0 satırları da işlemin sorunsuz tamamlandığını özetler.

C3. Raporu tazeleme

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

Sık Karşılaşılan Sorunlar

StartDagServerMaintenance.ps1 sessizce hiçbir şey yapmadan bitiyor

Belirti. Script çalıştırılıyor, $? True dönüyor, yani PowerShell hata görmüyor. -Verbose parametresiyle çalıştırsanız bile tek satır çıktı gelmiyor. Ancak Get-ServerComponentState çıktısında ServerWideOffline hala Active, yani script hiçbir şey değiştirmemiş. Bu, aşağıdaki “HighAvailability yarım kalıyor” senaryosundan farklıdır; orada bileşenlerin bir kısmı değişmiş ve yarım kalmıştı, burada script sanki hiç çalışmamış gibi görünüyor.

Kök sebep.$? True olması scriptin hata fırlatmadığını gösterir, ama gerçekten işini tamamladığı anlamına gelmez. En olası açıklama, script içindeki bir ön koşul kontrolünün hata basmadan return ile sessizce durmasıdır; yani script bir kontrolü geçemiyor ama bunu kullanıcıya bildirmiyor. Bu noktada scripti tekrar tekrar çalıştırmak ya da -Verbose ile debug etmeye çalışmak zaman kaybettirir; script içindeki kontrolü görmeden hangi koşulun engellediğini dışarıdan kestirmek mümkün değildir.

Ne zaman elle devam edilir. DAG tarafında güvenli olduğunuzdan emin olun: aktif kopyalar zaten manuel olarak diğer node’a taşınmış olmalı (B0’daki 1. madde) ve Test-ReplicationHealth her iki node için de temiz dönmeli. Bu iki şart sağlanıyorsa scripti daha fazla debug etmek yerine bakım moduna elle devam edebilirsiniz:

Set-MailboxServer -Identity W25EXCNOD2 -DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer -Identity W25EXCNOD2 -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState W25EXCNOD2 -Component HubTransport -State Draining -Requester Maintenance
Suspend-ClusterNode W25EXCNOD2
Set-ServerComponentState W25EXCNOD2 -Component ServerWideOffline -State Inactive -Requester Maintenance

Ardından B0’daki doğrulama bloğunu çalıştırın; ServerWideOffline dahil bileşenlerin (Monitoring ve RecoveryActionsEnabled hariç) Inactive, ClusterNode durumunun Paused olduğunu görmelisiniz.

Bakım moduna alma başarısız oluyor, HighAvailability yarım kalıyor

Belirti. StartDagServerMaintenance.ps1 çalıştırılıyor, hata veriyor veya sessizce dönüyor. Sonrasında Get-ServerComponentState çıktısında ServerWideOffline ve HubTransport Active görünüyor, yani bakım modu uygulanmamış, ama HighAvailability Inactive kalmış.

Kök sebep. Script bileşenleri belirli bir sırada değiştirir ve HighAvailability bileşenini Inactive yapmak bu sıranın ilk adımlarındandır. Sonraki adım olan Move-ActiveMailboxDatabase başarısız olursa script durur, ancak yaptığı ilk değişikliği geri almaz. Her yeniden deneme aynı kalıntıyı üretir.

Bu durumda Test-ReplicationHealth şu hatayı verir:

DatabaseAvailability  *FAILED*  Availability Count: 1. Expected Availability Count: 2.
                                Server 'W25EXCNOD2' component (HighAvailability) state is offline.

Yani Exchange o node’u aktivasyon hedefi olarak saymaz; veritabanları tek kopyaya düşmüş gibi raporlanır.

Hangi requester yaptı?

Get-ServerComponentState W25EXCNOD2 -Component HighAvailability | Format-List Component,State,LocalStates

Çıktıdaki Requestor değeri genellikle Maintenance olur:

Component   : HighAvailability
State       : Inactive
LocalStates : {Requestor:Maintenance; State:Inactive; Timestamp:...}

Düzeltme. Önce temiz çıkış deneyin:

cd $exscripts
.\StopDagServerMaintenance.ps1 -ServerName W25EXCNOD2

Hala Inactive kalırsa, LocalStates çıktısındaki requester ile elle geri alın:

Set-ServerComponentState W25EXCNOD2 -Component HighAvailability -State Active -Requester Maintenance
Get-ServerComponentState W25EXCNOD2 -Component HighAvailability | Format-List Component,State,LocalStates

DatabaseAvailability  *FAILED*  Availability Count: 1. Expected Availability Count: 2.
                                Server 'W25EXCNOD2' has database copy auto activation policy configuration of 'Blocked'.

Bu durumda ikisini de kontrol edip düzeltin:

Get-MailboxServer W25EXCNOD2 | Format-List DatabaseCopyAutoActivationPolicy,DatabaseCopyActivationDisabledAndMoveNow

Set-MailboxServer W25EXCNOD2 -DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer W25EXCNOD2 -DatabaseCopyActivationDisabledAndMoveNow $false

HighAvailability, DatabaseCopyAutoActivationPolicy ve DatabaseCopyActivationDisabledAndMoveNow üçü birbirinden bağımsız olarak takılı kalabilir. Birini düzelttikten sonra Test-ReplicationHealth çıktısını tekrar okuyun; hala FAILED dönüyorsa hata mesajının hangi ayarı işaret ettiğine bakıp onu da elle düzeltin, üçü de temizlenene kadar tekrarlayın.

Bakım modundan çıkma da sessizce başarısız olabilir

Belirti. StopDagServerMaintenance.ps1 çalıştırılıyor, tek satırlık bilgilendirme mesajı dışında hiçbir hata vermiyor. Ancak Get-ServerComponentState çıktısında ServerWideOffline ve HighAvailability hala Inactive, yani B0’daki bakım moduyla birebir aynı görünüyor. Test-ReplicationHealth çıktısında DatabaseAvailability kontrolü FAILED döner, hata mesajı HighAvailability bileşeninin offline olduğunu gösterir.

Kök sebep. Start scriptindeki ile aynı davranış: script belirli bir ön koşulda sessizce erken çıkıyor, kalan adımları uygulamıyor. Kopyaların kendisi (Get-MailboxDatabaseCopyStatus) Healthy ve kuyruklar 0 olabilir; sorun kopyalarda değil, component state’in geri açılmamasındadır.

Düzeltme. Aşağıdaki adımları elle, sırayla uygulayın:

Resume-ClusterNode -Name W25EXCNOD2

Set-ServerComponentState W25EXCNOD2 -Component HubTransport -State Active -Requester Maintenance

Set-MailboxServer W25EXCNOD2 -DatabaseCopyActivationDisabledAndMoveNow $false -DatabaseCopyAutoActivationPolicy Unrestricted

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

Ardından B8’deki doğrulama bloğunu tekrar çalıştırın; ServerWideOffline dahil tüm bileşenlerin Active, cluster node durumunun Up ve Test-ReplicationHealth çıktısının tamamen Passed olduğunu görmelisiniz.

Replikasyon örneği çalışmıyor hatası

Bu hata, Move-ActiveMailboxDatabase sırasında en sık karşılaşılan hatadır ve genellikle sıra hatasından kaynaklanır: hedef node hala bakım modundadır. StartDagServerMaintenance.ps1 cluster node’unu askıya aldığı ve aktivasyon politikasını Blocked yaptığı için o node veritabanı kabul edemez.

Sırayla kontrol edin:

Get-ServerComponentState W25EXCNOD2 | Format-Table Component,State -AutoSize
Get-MailboxServer W25EXCNOD2 | Format-List DatabaseCopyAutoActivationPolicy,DatabaseCopyActivationDisabledAndMoveNow
Get-ClusterNode
Get-Service MSExchangeRepl -ComputerName W25EXCNOD2
Get-MailboxDatabaseCopyStatus -Server W25EXCNOD2
Test-ReplicationHealth -Identity W25EXCNOD2

Beklenen değerler:

Bakım modundan çıkmadıysanız önce onu tamamlayın:

cd $exscripts
.\StopDagServerMaintenance.ps1 -ServerName W25EXCNOD2

Node yeni restart olduysa servislerin ayağa kalkması bir iki dakika sürebilir; beklemek yeterlidir.

Kapanış Kontrol Listesi

Bu liste tamamlandığında raporda geriye yalnızca 4 ve 5 numaralı maddeler (CVE listesi ve son SU) kalacak. Onları da SU10 (KB5121608) kurulumuyla kapatacağız.

Sonuç

Bu çalışmanın sonunda EXCDAG ortamındaki 4 kırmızı bulgunun üçü (PageFile, TCPKeepAlive, IPv6) ve 7 sarı bulgunun altısı (Visual C++ 2012, Sleepy NIC, Common Services Not Running, AMSI Request Body Scanning, Edition, Known Issue) kapanmış olacak; ayrıca node’lar arasındaki tek fark olan Visual C++ 2013 durumu da giderilecek. Geriye kalan iki madde, güvenlik açığı listesi ve kurulu olmayan son Security Update, aynı kökten geliyor: sunucular SU10 öncesi bir build üzerinde çalışıyor.

Sertifika tarafında bu turda yalnızca bir doğrulama yaptık: önceki raporda görülen PendingRequest kaydı bu raporda yok, tüm sertifikalar Valid durumda. Ancak DAG ortamında sertifika yönetimi (SAN planlama, namespace ilişkisi, auth certificate, iki node’a dağıtım ve yenileme) kendi başına bir yazıyı hak ediyor, onu ayrıca ele alacağım.

Bir sonraki yazıda DAG yapısında Security Update kurulumunu adım adım yapacağız: bakım moduna alma, pasif node’dan başlayarak SU10 (KB5121608) kurulumu, switchover ve veritabanı kopyalarının activation preference değerlerine göre yeniden dengelenmesi.

Buradaki en önemli alışkanlık şu: her fazın sonunda Test-ReplicationHealth ve Get-MailboxDatabaseCopyStatus çıktılarını kontrol etmeden bir sonraki adıma geçmeyin. DAG’da hata, işlemi yaptığınız anda değil, bir sonraki failover’da ortaya çıkar.

İlgili Yazılar

• Exchange Server SE DAG Ortamında Sağlık Kontrolü: HealthChecker.ps1 ile Uçtan Uca
• Exchange Server SE Sağlık Kontrolü: HealthChecker.ps1 ile Uçtan Uca
• Exchange Server SE Güncelleme: HealthChecker ile Tespit Edilen Açıkları Kapatma
• Microsoft Exchange Server SE DAG Serisi Bölüm 4: Veritabanı Kopyaları, Switchover ve Yönetim
• Exchange Server Build Numbers

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