Merhaba
Bir önceki yazımda HealthChecker.ps1 ile Exchange Server SE sağlık kontrolünü uçtan uca anlatmıştım. Raporu çalıştırdığınızda kırmızı satırlarda “Vulnerable to CVE-XXXX-XXXXX” şeklinde güvenlik açıkları görmüş olabilirsiniz. Bu açıklar neredeyse her zaman eksik bir Güvenlik Güncellemesine (SU) işaret eder. Bu yazıda, tespit edilen açıkları kapatmak için Exchange Server SE üzerine en güncel SU’yu adım adım nasıl kuracağımızı ve sonrasında raporun temizlendiğini nasıl doğrulayacağımızı ele alacağım.
Mevcut Sürümü Tespit Etme
Önce sunucunun hangi build numarasında olduğunu görelim. En doğru yöntem HealthChecker’ın kendisidir; ancak hızlı bir kontrol için Exchange Management Shell’de şu komutu da kullanabilirsiniz:
Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion
Bu komut CU seviyesini gösterir ancak kurulu SU/HU’yu göstermez. SU dahil tam sürümü görmek için:
Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}
Yazının hazırlandığı tarihte en güncel sürüm Exchange Server SE RTM SU9 (KB5121573) olup build numarası 15.2.2562.46 (uzun format: 15.02.2562.046), yayın tarihi 11 Ağustos 2026’dır. Bu güncelleme, bir önceki 14 Temmuz 2026 tarihli SU8 (KB5103212) paketinin yerine geçer; SU/HU’lar kümülatif olduğu için doğrudan SU9’u kurmanız önceki tüm güncellemeleri de kapsar. Kendi sunucunuzda en güncel sürümü ve ilgili KB numarasını her zaman Microsoft’un resmi build numbers and release dates sayfasından teyit edin.
SU9, aşağıdaki güvenlik açıklarını (CVE) kapatır: CVE-2026-62910, CVE-2026-62911, CVE-2026-62912, CVE-2026-62913, CVE-2026-62914, CVE-2026-62915 ve CVE-2026-65813.
Güncellemeyi İndirme
İhtiyacınız olan SU’yu, HealthChecker raporundaki CVE satırına ya da build tablosundaki KB numarasına göre belirleyin. SU’lar kümülatiftir; yani en güncel SU, önceki tüm SU’ları içerir. Bu nedenle yalnızca en son SU’yu kurmanız yeterlidir.
Güncellemeyi ilgili KB sayfasından (SU9 için KB5121573) ya da Microsoft Download Center üzerinden indirin. İndirilen dosyanın adı şu şekildedir:
ExchangeSubscriptionEdition-KB5121573-x64-en.exeBakım Moduna Alma (Maintenance Mode)
Sunucunuz bir DAG üyesiyse, güncelleme öncesinde mutlaka bakım moduna alın. Aksi halde güncelleme sırasında DAG devreye girip veritabanı taşımalarında ve servis kesintilerinde sorun yaşayabilirsiniz. Tek sunuculu (standalone) bir kurulumsa bu adımlar zorunlu değildir, ancak yine de sunucuyu kullanıcı trafiğinden çekmek iyi bir uygulamadır.
Önce aktif veritabanlarını ve kuyrukları başka bir sunucuya taşıyın (DAG senaryosu):
Set-ServerComponentState W25EXCSE -Component HubTransport -State Draining -Requester Maintenance
Redirect-Message -Server W25EXCSE -Target "W25EXCSE2.domain.local"Ardından sunucuyu tam bakım moduna alın:
Set-ServerComponentState W25EXCSE -Component ServerWideOffline -State Inactive -Requester MaintenanceGüvenlik Güncellemesini Kurma
Command Prompt (Komut İstemi)’ni Run as administrator (Yönetici olarak) olarak açmak için: Başlat > cmd yazın > Komut İstemi’ne sağ tıklayıp Run as administrator seçin. Ardından paketin bulunduğu klasöre geçip çalıştırın:
cd C:\ExchangeServerUpdates
ExchangeSubscriptionEdition-KB5121573-x64-en.exeYönetici olarak açılmış Command Prompt (Komut İstemi) üzerinden cd C:\ExchangeServerUpdates ile paketin bulunduğu klasöre geçip ExchangeSubscriptionEdition-KB5121573-x64-en.exe komutunu çalıştırıyoruz.
Kurulum başladığında komut satırında “START: Installation process initiated” ve “SUCCESS: Extracted contents to…” mesajları görünür; paket içeriği geçici klasöre çıkarılır ve “Welcome to the Setup Wizard” karşılama ekranı açılır. Bu aşamada sihirbaz gerekli disk alanını hesaplar (Computing space requirements).
Karşılama ekranı hazır olduğunda “To start the installation, click Next” mesajı görünür. Kuruluma başlamak için Next butonuna tıklayın.
License Terms (Lisans Şartları) ekranında lisans metnini okuyun, “I accept the License Terms” (Lisans şartlarını kabul ediyorum) seçeneğini işaretleyin ve Next ile devam edin.
Kurulum başlar. İlk aşamada sihirbaz disk alanı gereksinimlerini hesaplar (Status: Computing space requirements). Bu ekranda işlemin birkaç dakika sürebileceği belirtilir.
Sihirbaz çalışan Exchange servislerini durdurur (Status: Stopping services). Güncellemenin dosyalara müdahale edebilmesi için bu adım gereklidir.
Güncelleme doğrulama aşamasına geçer (Status: Validating install) ve ilerleme çubuğu dolmaya başlar.
Kurulum dosyaları uygulanırken ilerleme çubuğu neredeyse tamamına ulaşır. Bu, adımın en uzun sürebilen kısmıdır.
Kurulum tamamlanmak üzereyken sihirbaz durdurduğu servisleri yeniden başlatır (Status: Starting services).
“Setup Wizard … Completed” ekranı, güncellemenin başarıyla tamamlandığını gösterir. Sihirbazdan çıkmak için Finish butonuna tıklayın.
Komut satırına dönüldüğünde “COMPLETED: The Exchange Server Update installed successfully” mesajı görünür. Bu satır, güncellemenin sorunsuz kurulduğunu doğrular.
Sunucuyu Yeniden Başlatma
Güvenlik güncellemesinin ardından sunucuyu her zaman yeniden başlatın. Bazı durumlarda sihirbaz yeniden başlatma istemi göstermeyebilir; yine de yeniden başlatmayı atlamayın. Aksi halde Outlook on the web veya ECP’de HTTP 400 gibi oturum açma hatalarıyla karşılaşabilirsiniz.
Windows PowerShell‘i Run as administrator (Yönetici olarak) açın ve aşağıdaki komutu çalıştırın. Bu işlemi manuel olarak direktte yapabilirsiniz.
Restart-Computer
Bakım Modundan Çıkarma
Sunucu yeniden başladıktan sonra bakım modundan çıkarıp servisleri tekrar aktif hale getirin:
Set-ServerComponentState W25EXCSE -Component ServerWideOffline -State Active -Requester Maintenance
Set-ServerComponentState W25EXCSE -Component HubTransport -State Active -Requester MaintenanceDAG üyesiyse veritabanı kopyalarının tekrar sağlıklı (Healthy) duruma geldiğini doğrulayın:
Get-MailboxDatabaseCopyStatus -Server W25EXCSEGüncellemeyi Doğrulama
Şimdi işin en tatmin edici kısmına geldik: açıkların gerçekten kapandığını doğrulamak. Önce build numarasının beklenen sürüme yükseldiğini kontrol edin:
Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}Çıktının 15.2.2562.46 (uzun format: 15.02.2562.046) (veya kurduğunuz SU’nun build numarası) olduğunu görmelisiniz.
Ardından HealthChecker‘ı yeniden çalıştırıp raporu üretin.
Exchange Management Shell‘i Run as administrator (Yönetici olarak) açın.
Aşağıdaki komutu çalıştırın:
cd C:\Scripts
.\HealthChecker.ps1 -Server "W25EXCSE"
Script çalıştıktan sonra herhangi bir hata almadıysanız sonuç ekranı gelir. Ardından sunucu üzerindeki yapılandırma ve eksikliklerle ilgili bütün adımlar sırayla ekranda görüntülenir.
Script çalıştıktan sonra scriptin bulunduğu C:\Scripts klasöründe iki dosya üretir:
-
- TXT dosyası: PowerShell’deki çıktının aynısı; e-postaya eklemek veya arşivlemek için pratiktir.
- XML dosyası: HTML rapor üretmek için kullanılan veri dosyası.
HTML Sağlık Raporu Üretme
Exchange Management Shell‘i Run as administrator (Yönetici olarak) açın.
Eğer daha önce .\HealthChecker.ps1 -Server "W25EXCSE" komutunu çalıştırıp yeni bir veri dosyası (XML) oluşturduysanız, doğrudan aşağıdaki komutla HTML raporunu üretebilirsiniz:
.\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "W25EXCSE-Report.html"-BuildHtmlServersReport parametresi yeni veri toplamaz; yalnızca çalışma klasöründe daha önce oluşturulmuş ...-HealthChecker-*.xml dosyalarını okuyup HTML’e dönüştürür. Bu yüzden raporu üretmeden önce sunucu için en az bir kez -Server parametresiyle scripti çalıştırıp XML çıktısı almış olmanız gerekir. Elde XML yoksa rapor boş çıkar veya hata alırsınız.-HtmlReportFile parametresini vermezseniz script çıktıyı tarih-saat damgalı olarak ExchangeAllServersReport-yyyyMMddHHmmss.html biçiminde otomatik adlandırır. Dosyaya kendi vereceğiniz sade bir isim, özellikle raporları arşivlerken işinizi kolaylaştırır.Güncel bir rapor için önce veri toplayan komutu, ardından HTML dönüştürme komutunu sırayla çalıştırın:
cd C:\Scripts
.\HealthChecker.ps1 -Server "W25EXCSE"
.\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "W25EXCSE-Report.html"
Öncelikli olarak .\HealthChecker.ps1 -Server "W25EXCSE" komutunu çalışacaktır..\HealthChecker.ps1 -Server "W25EXCSE" komutu tamamlandıktan sonra Enter tuşuna basarak .\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile "W25EXCSE-Report.html" komutunun çalışmasını sağlayabilirsiniz.
Script tamamlandıktan sonra HealthChecker.ps1 scriptinin bulunduğu C:\Scripts klasöründe W25EXCSE-Report isimli bir HTML rapor dosyası oluşur.
Klasör görünümünde raporun oluştuğu dizini görüyoruz.
C:\Scripts klasöründe W25EXCSE-Report dosyasını tarayıcıda açarak inceleyebilirsiniz.
Raporu açtığınızda renk kodlarıyla karşılaşırsınız:
- Gri: Bilgilendirme amaçlı öğeler
- Yeşil: Önerilerle uyumlu ayarlar
- Sarı: Göz atmanız gereken uyarılar
- Kırmızı: Performans sorununa yol açabilecek, öncelikli düzeltilmesi gereken ayarlar
Önce kırmızı satırları ele alın; bunlar en kritik olanlardır.
Exchange Information bölümünde build numarasının güncellendiğini ve daha önce kırmızı görünen “Vulnerable to CVE-…” satırlarının artık listede olmadığını göreceksiniz. En temiz kontrol yöntemi, ortam genelinde vulnerability raporunu çıkarmaktır:
Exchange Management Shell‘i Run as administrator (Yönetici olarak) açın ve aşağıdaki komutu çalıştırın.
cd C:\Scripts
.\HealthChecker.ps1 -VulnerabilityReport-VulnerabilityReport parametresi HTML çıktı üretmez; yalnızca JSON dosyası oluşturur ve -HtmlReportFile gibi bir HTML seçeneğiyle birlikte kullanılamaz. Bunun teknik nedeni, HealthChecker’da VulnerabilityReport ile BuildHtmlServersReport özelliklerinin ayrı parametre setleri (parameter set) olması ve ikisinin aynı komutta birleştirilememesidir. Güvenlik açıklarını HTML rapor içinde görmek isterseniz standart HTML raporunu kullanın; -BuildHtmlServersReport ile üretilen rapor, “Security Vulnerabilities” bölümünde CVE satırlarını renk koduyla zaten gösterir.
Script tamamlandıktan sonra HealthChecker.ps1 scriptinin bulunduğu C:\Scripts klasöründe bir JSON rapor dosyası oluşur.
Raporun oluştuğu dizin görünümü.
C:\Scripts klasöründe oluşan JSON dosyasını bir metin düzenleyici ya da tarayıcıyla açarak güvenlik açığı ayrıntılarını inceleyebilirsiniz.
Rapordaki Bulgular ve Çözümleri
HealthChecker raporunu çalıştırdığınızda, sunucunuzun durumuna göre sarı (uyarı) ve kırmızı (hata) satırlarla karşılaşırsınız. Aşağıda kendi Exchange Server SE ortamımda karşılaştığım bulguları ve her birini nasıl gidereceğinizi paylaşıyorum. Ortamınıza göre bu satırların bir kısmı çıkmayabilir. Her bulgunun sonunda, Microsoft’un ilgili resmi kaynağına bağlantı da bulacaksınız.
Önemli bir hatırlatma: Bir bulguyu düzelttikten sonra raporu mutlaka iki adımlı yöntemle (önce -Server , sonra -BuildHtmlServersReport) yeniden üretin. Aksi halde düzelttiğiniz satır raporda hâlâ eski haliyle kırmızı ya da sarı görünmeye devam eder. Ayrıca registry, pagefile ve benzeri bazı değişiklikler yeniden başlatma gerektirir.
PageFile (Sayfa Dosyası) – Kırmızı
Raporda “System is set to automatically manage the PageFile Size: 0MB” hatası görülür ve önerilen boyutun toplam belleğin %25’i olduğu belirtilir. Bu hata, sayfa dosyasının Windows tarafından otomatik yönetildiğini ve Exchange için önerilen sabit boyutta olmadığını gösterir.
Exchange Server SE (2019 tabanlı) için önerilen değer, kurulu belleğin %25’i kadar, sabit (initial ve maximum aynı) bir sayfa dosyasıdır. Örneğin 32 GB RAM için bu değer 8192 MB olur. Ayrıca sistemde yalnızca tek bir sayfa dosyası bulunmalıdır; birden fazla pagefile Exchange’de performans sorunlarına yol açabilir.
En pratik ve her Windows Server sürümünde çalışan yöntem grafik arayüzdür. Run (Çalıştır) penceresine sysdm.cpl yazın ve Advanced (Gelişmiş) sekmesi > Performance (Performans) altında Settings (Ayarlar) > Advanced (Gelişmiş) sekmesi > Virtual Memory (Sanal Bellek) altında Change (Değiştir) yolunu izleyin. Açılan pencerede “Automatically manage paging file size for all drives” (Tüm sürücüler için sayfalama dosyası boyutunu otomatik olarak yönet) kutusunun işaretini kaldırın, C: sürücüsünü seçin, Custom size (Özel boyut) işaretleyin ve hem Initial size (Başlangıç boyutu) hem de Maximum size (En fazla boyut) kutularına 8192 yazın. Ardından mutlaka Set (Ayarla) butonuna basın, sonra OK (Tamam) ile çıkın.
Aynı işlemi Windows PowerShell ile de yapabilirsiniz Run as administrator (Yönetici olarak):
$cs = Get-WmiObject Win32_ComputerSystem
$cs.AutomaticManagedPagefile = $false
$cs.Put()$pf = Get-WmiObject Win32_PageFileSetting
$pf.InitialSize = 8192
$pf.MaximumSize = 8192
$pf.Put()Değişikliğin tam olarak devreye girmesi için sunucuyu yeniden başlatmanız gerekir. Yeniden başlatmadan raporu tekrar alırsanız, ayar doğru yapılmış olsa bile HealthChecker sayfa dosyasını hala “System is set to automatically manage the PageFile Size: 0MB” (Sistem, sayfa dosyası boyutunu otomatik olarak yönetecek şekilde ayarlanmış: 0MB) olarak gösterir.
Yeniden başlatma sonrası ayarın doğru uygulandığını şu komutlarla teyit edebilirsiniz:
Get-CimInstance Win32_ComputerSystem | Select-Object AutomaticManagedPagefileGet-CimInstance Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSizeGet-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSizeÇıktıda AutomaticManagedPagefile değerinin False, boyutların 8192 ve AllocatedBaseSize değerinin 8192 olması, ayarın hem kaydedildiğini hem de çalışma anında aktif olduğunu gösterir.
TCP KeepAlive – Kırmızı
Raporda “TCPKeepAlive Not Set” hatası görülür. Değer tanımlı olmadığında KeepAliveTime varsayılan olarak iki saate düşer; bu da Firewall (güvenlik duvarı) ve Load Balancer (yük dengeleyici) gibi ağ cihazlarıyla Exchange arasında bağlantı kopması ve performans sorunlarına yol açabilir. Çözüm, registry’ye 30 dakikalık (1800000 ms) bir değer eklemektir.
Windows PowerShell‘i Run as administrator (Yönetici olarak) çalıştırıyoruz.
New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters" -Name "KeepAliveTime" -PropertyType DWORD -Value 1800000 -ForceDoğrulama:
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters" -Name "KeepAliveTime" | Select-Object KeepAliveTimeÇıktıda KeepAliveTime : 1800000 görmelisiniz. Bu değişiklik sunucu yeniden başlatıldığında etkin olur.
Visual C++ 2012 ve 2013 x64 Redistributable – Sarı
Raporda “Visual C++ 2012 x64 Redistributable is outdated (11.0.50727)” ve “Visual C++ 2013 x64 Redistributable is outdated (12.0.21005)” uyarıları görülür. Buradaki en kritik nokta şudur: Exchange, özellikle Visual C++ 2012 ve 2013 sürümlerini ister ve bunlar daha yeni VC++ sürümleriyle (2015 / 2017 / 2019 / 2022) değiştirilemez. Yani sistemde en güncel VC++ paketinin kurulu olması yeterli değildir; tam olarak bu iki sürümün güncel build’i gerekir.
Çözüm, Microsoft’un resmi indirme sayfalarından şu iki paketi ayrı ayrı kurmaktır: Visual C++ 2012 Update 4 (x64) ve Visual C++ 2013 (x64). Her iki paketi de yönetici olarak kurduktan sonra sunucuyu yeniden başlatın.
Kurulum sonrası yüklü sürümleri şu komutla doğrulayabilirsiniz:
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 DisplayNameVC++ 2012 x64 için sürümün 11.0.61030 (Update 4), VC++ 2013 x64 için 12.0.40664 civarında olduğunu gördüğünüzde iş tamamdır.
IPv6 Yapılandırması – Kırmızı
Raporda “IPv6 is disabled on some NIC level settings but not fully disabled. DisabledComponents registry value currently set to ‘0’” hatası görülebilir. Bu, IPv6’nın bazı ağ kartı ayarlarında kapatıldığını ancak tam olarak devre dışı bırakılmadığını, yani tutarsız bir durumda olduğunu gösterir.
Önce ağ kartlarında IPv6 bağlamasının etkin olduğunu doğrulayın:
Get-NetAdapterBinding -ComponentID ms_tcpip6 | Select-Object Name, DisplayName, EnabledDevre dışı görünen kart varsa etkinleştirin:
Enable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6Ardından registry’deki tutarsız değeri kaldırın (varsayılan tam-etkin duruma dönmesi için):
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name "DisabledComponents" -ErrorAction SilentlyContinueSonra sunucuyu yeniden başlatın ve raporu tazeleyin.
DisabledComponents değeri 0xFF yapılmalıdır.Download Domains (CVE-2021-1730) – Kırmızı
Raporda “Download Domains are not configured. You should configure them to be protected against CVE-2021-1730” hatası görülür. Bu açık, CU veya SU kurmakla otomatik kapanmaz; ayrı bir yapılandırma gerektirir. Amaç, OWA’daki satır içi görsellerin ve eklerin, OWA’nın kendisinden farklı bir alan adından yüklenmesini sağlamaktır. Bu ayrım, tarayıcının SameSite çerez korumasını devreye sokarak siteler arası istek sahteciliği (CSRF) saldırılarına karşı koruma sağlar.
Diğer maddelerden farklı olarak bu yapılandırma tek komutla bitmez; önce DNS ve sertifika hazırlığı gerektirir. Uygulama üç aşamalıdır ve sırası önemlidir:
Birincisi, indirme için ayrı bir ana bilgisayar adı belirleyin (örneğin iç ağ için download.domainadi.local , dış erişim için download.domainadi.com) ve bunu OWA’ya kullandığınız adrese işaret eden bir CNAME kaydı olarak DNS’e ekleyin. Split-DNS kullanıyorsanız hem iç hem dış DNS’te tanımlayın.
İkincisi, bu yeni ana bilgisayar adını Exchange sertifikanızın SAN (Subject Alternative Name) alanına ekleyip sertifikayı yeniden düzenleyin. Bu adım atlanırsa kullanıcılar OWA’da sertifika hatası alır.
Üçüncüsü, DNS ve sertifika hazır olduktan sonra Exchange Management Shell’de (yönetici) önce OWA sanal dizinlerine indirme host adını tanımlayın, sonra özelliği organizasyon genelinde etkinleştirin:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalDownloadHostName "download.domainadi.com" -InternalDownloadHostName "download.domainadi.local"
Set-OrganizationConfig -EnableDownloadDomains $trueDeğişikliğin aktif olması için her Exchange sunucusunda IIS’i yeniden başlatın:
Exchange Management Shell‘i (ya da Windows PowerShell’i) Run as administrator (Yönetici olarak) açın:
iisresetKüçük bir alternatif: tüm siteyi resetlemek yerine sadece OWA app pool’unu geri döndürmen de yeter ve daha az kesinti yaratır (yine Run as administrator (Yönetici olarak) çalışması gerekir):
Restart-WebAppPool -Name "MSExchangeOWAAppPool"Doğrulama için satır içi görselli bir e-posta gönderip OWA’da açın; görsele sağ tıklayıp Inspect ile URL’nin artık download alan adından geldiğini görün. Sonra HealthChecker’ı yeniden çalıştırdığınızda CVE-2021-1730 satırı temizlenmiş olur. Bu yapılandırma DNS ve sertifika hazırlığı gerektirdiği için, üretim ortamına geçmeden önce planlı bir bakım penceresinde uygulanması önerilir.
NIC Power Saving (Sleepy NIC) – Sarı
Raporda “Sleepy NIC … It’s recommended to disable NIC power saving options” uyarısı görülür. Ağ kartının güç tasarrufu seçenekleri açıksa, kart düşük trafikte uyku moduna geçebilir ve Exchange’de bağlantı ile performans sorunlarına yol açabilir. Çözüm, ağ kartının güç yönetimini kapatmaktır.
Windows PowerShell‘i Run as administrator (Yönetici olarak) açın
Get-NetAdapter -Physical | Where-Object { $_.Status -eq "Up" } | ForEach-Object {
Get-NetAdapterPowerManagement -Name $_.Name | ForEach-Object {
$_.AllowComputerToTurnOffDevice = "Disabled"
$_ | Set-NetAdapterPowerManagement
}
}Alternatif olarak Device Manager (Aygıt Yöneticisi) > Network adapters (Ağ Bağdaştırıcıları) > (ilgili kart) > Properties (Özellikler) > Power Management (Güç Yönetimi) sekmesinden “Allow the computer to turn off this device to save power” (Bilgisayarın bu aygıtı kapatmasına izin ver) kutusunun işaretini kaldırabilirsiniz.
Bilgi Amaçlı Uyarılar
Aşağıdaki sarı satırlar genellikle bir hata değil, ortama bağlı bilgilendirme niteliğindedir ve çoğu lab veya küçük ölçekli kurulumlarda göz ardı edilebilir:
- Physical Memory uyarısı, en iyi performans için en az 128 GB RAM önerildiğini belirtir. Bu bir donanım tavsiyesidir; test veya küçük ölçekli ortamlarda daha düşük bellek genellikle yeterlidir.
- Edition: StandardEvaluation uyarısı, sunucunun değerlendirme (evaluation) lisansında olduğunu gösterir. Üretim ortamında kalıcı lisansa dönüştürülmesi gerekir; lab ortamında sorun teşkil etmez.
- Dynamic Memory Detected: Unknown uyarısı, sanallaştırma platformunda ilgili performans sayacının yüklü olmaması nedeniyle HealthChecker’ın dinamik bellek durumunu okuyamadığını belirtir. Yine de en iyi pratik, Exchange sanal makinelerinde dinamik/balloon bellek yerine sabit ayrılmış bellek kullanmaktır.
Sonuç
Bir güvenlik açığını raporda görmek yeterli değildir; asıl önemli olan onu kapatıp sonucu doğrulamaktır. Exchange Server SE’de güncelleme süreci özetle şu adımlardan oluşur: mevcut sürümü tespit et, en güncel SU’yu indir, (DAG ise) bakım moduna al, güncellemeyi elevated Komut İstemi üzerinden kur, sunucuyu yeniden başlat, bakım modundan çık ve son olarak HealthChecker ile açıkların kapandığını doğrula. Bu döngüyü düzenli aralıklarla tekrarlamak, Exchange ortamınızı hem güvenli hem de kararlı tutmanın en sağlam yoludur.
