Exchange Server Güncelleme ve Yama Yönetimi

Yazar:komut.io ekibi Exchange Server Kurulum ve Yönetimi
0 Yorum

Exchange Server ortamında yama yönetimi, birçok sysadmin’in “en sonra hallederiz” listesinde üst sıralarda yer alan konulardan biri. Ama şunu söyleyeyim: Exchange güncellemelerini geciktirmenin bedeli, diğer sistemlere kıyasla çok daha ağır olabiliyor. Hem güvenlik açıklarının ciddiyeti hem de Exchange’in kurumsal altyapıdaki merkezi rolü düşünüldüğünde, bu işi sistematik bir şekilde yapmak bir tercih değil, zorunluluk.

Exchange Güncelleme Yapısını Anlamak

Exchange Server güncelleme mekanizması, Windows’un standart Windows Update sürecinden farklı çalışıyor. Bunu anlamadan düzenli yama yapmak mümkün değil.

Exchange 2016 ve 2019 için güncellemeler iki ana başlık altında geliyor:

  • Cumulative Update (CU): Yılda iki kez yayınlanan büyük güncellemeler. Bir önceki CU üzerine kurulur, tüm hotfix ve güvenlik yamalarını içerir. CU kurulumu aslında Exchange’in kısmi yeniden kurulumu gibidir.
  • Security Update (SU): Belirli güvenlik açıklarını kapatan yamalar. Genellikle Microsoft’un aylık “Patch Tuesday” döngüsünde gelir, bazen de kritik açıklar için bant dışı yayınlanır.

Exchange 2019 ile gelen bir değişiklik de dikkat çekicidir: Microsoft, CU’lar yerine Exchange Server 2019 için yıl bazlı güncellemelere geçti. Bu model biraz farklı çalışıyor, ancak temel prensip aynı.

Kritik bir nokta: Her SU, belirli bir CU versiyonu üzerine uygulanabiliyor. Yani CU’nuzun güncel olmaması durumunda en son güvenlik yamalarını uygulayamayabilirsiniz. Bu nedenle CU takibi ile SU takibini birlikte yürütmek gerekiyor.

Mevcut Versiyonu Doğru Tespit Etmek

Güncellemeye başlamadan önce tam olarak nerede durduğunuzu bilmek gerekiyor. Exchange Management Shell’den şu komutla başlayın:

Get-ExchangeDiagnosticInfo -Server MAILSERVER01 -Process EdgeTransport -Component ResourceThrottling | Select-Object -ExpandProperty Result

Daha doğrudan bir yöntem için:

Get-ExchangeServer | Select-Object Name, Edition, AdminDisplayVersion

Bu çıktı size “Version 15.2 (Build 1118.7)” gibi bir bilgi verecek. Bu build numarasını Microsoft’un Exchange build numaraları sayfasıyla karşılaştırarak tam olarak hangi CU’da olduğunuzu öğrenebilirsiniz.

Birden fazla Exchange sunucusu olan ortamlarda tüm sunucuların versiyonunu tek seferde görmek için:

Get-ExchangeServer | Sort-Object Name | Format-Table Name, AdminDisplayVersion, Edition, ServerRole -AutoSize

Ayrıca .NET Framework versiyonunu da kontrol etmeyi unutmayın. Exchange, belirli .NET versiyonlarıyla çalışıyor ve CU kurulumu öncesinde .NET uyumluluğunu doğrulamak zorundasınız:

Get-ItemProperty -Path "HKLM:SOFTWAREMicrosoftNET Framework SetupNDPv4Full" | Select-Object Release, Version

Güncelleme Öncesi Hazırlık Süreci

Yama günü sabahı kalkıp “hadi yapalım” diyerek başlamak, ciddi sorunlara davet çıkarmak demektir. Profesyonel bir hazırlık süreci şöyle görünmeli:

Veritabanı ve Servis Sağlığı Kontrolü

# DAG ortamlarında veritabanı kopyalarının durumunu kontrol edin
Get-MailboxDatabaseCopyStatus * | Select-Object Name, Status, CopyQueueLength, ReplayQueueLength | Sort-Object Name

# Kuyruk durumunu kontrol edin
Get-Queue | Where-Object {$_.MessageCount -gt 0} | Select-Object Identity, Status, MessageCount, NextHopDomain

Kopyalama kuyruğu (CopyQueueLength) sıfır veya bire yakın olmalı. Eğer yüksek değerler görüyorsanız, bu replikasyon gecikmesi demektir ve güncelleme öncesinde bunun çözülmesi gerekir.

Yedekleme Doğrulaması

Güncelleme öncesinde yedek almak standart prosedür ama yeterli değil. Yedeğin restore edilebilir olduğunu da doğrulamanız gerekiyor. En azından son başarılı yedeğin tarihini ve boyutunu kontrol edin:

# Windows Server Backup ile alınan son yedeği kontrol etmek için
Get-WBJob -Previous 5 | Select-Object StartTime, EndTime, JobType, JobState

IIS Uygulama Havuzlarının Durumu

Exchange, IIS üzerinde birçok servis çalıştırır. Güncelleme öncesinde bunların sağlıklı olduğunu teyit edin:

Import-Module WebAdministration
Get-WebConfiguration system.applicationHost/applicationPools/add | 
  Where-Object {$_.name -like "*Exchange*"} | 
  Select-Object name, @{n="State";e={(Get-WebAppPoolState -Name $_.name).Value}}

Sertifika Son Kullanma Tarihleri

CU kurulumu bazen sertifika bağlamalarını bozabilir. Öncesinde mevcut sertifika durumunu kaydedin:

Get-ExchangeCertificate | Select-Object Thumbprint, Subject, NotAfter, Services, Status | Format-List

DAG Ortamlarında Güncelleme Stratejisi

Database Availability Group ortamında güncelleme yapmak, tek sunuculu ortama göre çok daha dikkatli bir planlama gerektiriyor. Genel kural şu: bir seferde bir sunucu, aktif veritabanlarını taşıyarak ilerle.

Önce pasif kopya barındıran sunucudan başlayın. Güncelleme yapılacak sunucudaki aktif veritabanlarını diğer sunucuya taşıyın:

# Belirli sunucudaki tüm aktif veritabanlarını başka sunucuya taşı
Move-ActiveMailboxDatabase -Server MAILSERVER01 -ActivateOnServer MAILSERVER02 -Confirm:$false

# Taşımanın başarılı olduğunu doğrula
Get-MailboxDatabaseCopyStatus * | Where-Object {$_.ActiveServer -eq "MAILSERVER01"}

Taşıma sonrasında MAILSERVER01 üzerinde aktif veritabanı kalmadığını doğrulayın. Sonra maintenance moduna alın:

# DAG maintenance modunu başlat
Set-ServerComponentState MAILSERVER01 -Component HubTransport -State Draining -Requester Maintenance
Redirect-Message -Server MAILSERVER01 -Target MAILSERVER02.domain.local
Suspend-MailboxDatabaseCopy -Identity *MAILSERVER01 -Confirm:$false
Set-MailboxServer MAILSERVER01 -DatabaseCopyActivationDisabledAndMoveNow $true -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState MAILSERVER01 -Component ServerWideOffline -State Inactive -Requester Maintenance

Güncelleme tamamlandıktan sonra maintenance modundan çıkış:

Set-ServerComponentState MAILSERVER01 -Component ServerWideOffline -State Active -Requester Maintenance
Set-MailboxServer MAILSERVER01 -DatabaseCopyActivationDisabledAndMoveNow $false -DatabaseCopyAutoActivationPolicy Unrestricted
Resume-MailboxDatabaseCopy -Identity *MAILSERVER01 -Confirm:$false
Set-ServerComponentState MAILSERVER01 -Component HubTransport -State Active -Requester Maintenance

# Tüm bileşenlerin aktif olduğunu kontrol et
Get-ServerComponentState MAILSERVER01 | Select-Object Component, State

CU Kurulum Süreci

CU’ları doğru indirdiğinizden emin olmak için Microsoft’un resmi indirme sayfasından SHA256 hash doğrulaması yapın. İndirdiğiniz dosyanın bütünlüğünü kontrol etmek için:

Get-FileHash -Path "C:UpdatesExchangeServer2019-x64-CU14.ISO" -Algorithm SHA256 | Select-Object Hash

CU kurulumunu her zaman yönetici komut isteminden çalıştırın, GUI arayüzünden değil. Bu size daha iyi log çıktısı ve hata ayıklama imkanı sağlar:

# CU kurulumunu sessiz modda başlat, log dosyası oluştur
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

# AD hazırlığı tamamlandıktan sonra kuruluma devam et
Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /on-premise-server /l C:LogsExchangeSetup.log

Kurulum sırasında şema güncellemesi gereken durumlarda PrepareAD ve PrepareAllDomains adımlarının önce çalıştırılması gerekiyor. Bunu Domain Admin ve Schema Admin yetkili bir hesapla yapmalısınız:

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF
Setup.exe /PrepareAD /OrganizationName:"SirketAdi" /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF
Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

Güncelleme Sonrası Doğrulama

Kurulum tamamlandıktan sonra otomatik olarak çalıştırabileceğiniz bir doğrulama scripti işinizi çok kolaylaştırır:

# Exchange servislerinin durumunu kontrol et
$services = Get-Service | Where-Object {$_.DisplayName -like "*Microsoft Exchange*"}
$services | Select-Object DisplayName, Status | Sort-Object DisplayName

# Sorunlu servisleri bul
$stoppedServices = $services | Where-Object {$_.Status -ne "Running"}
if ($stoppedServices) {
    Write-Host "UYARI: Su servisler calismıyor:" -ForegroundColor Red
    $stoppedServices | ForEach-Object {
        Write-Host $_.DisplayName -ForegroundColor Yellow
        # Servisi yeniden başlatmayı dene
        Start-Service $_.Name
    }
} else {
    Write-Host "Tüm Exchange servisleri calisiyor." -ForegroundColor Green
}

OWA ve ECP’nin çalışıp çalışmadığını test etmek için:

# OWA health check
$owaTesti = Invoke-WebRequest -Uri "https://mail.sirket.com/owa/healthcheck.htm" -UseBasicParsing
if ($owaTesti.StatusCode -eq 200) {
    Write-Host "OWA erişilebilir durumda" -ForegroundColor Green
} else {
    Write-Host "OWA erişim sorunu: HTTP $($owaTesti.StatusCode)" -ForegroundColor Red
}

E-posta akışını doğrulamak için test mesajı gönderme:

Send-MailMessage -To "[email protected]" -From "[email protected]" -Subject "CU14 Sonrasi Test" -Body "Guncelleme sonrasi test maili. Zaman: $(Get-Date)" -SmtpServer "MAILSERVER01"

Sık Karşılaşılan Sorunlar ve Çözümleri

Yıllarca Exchange ortamı yönetince bazı hatalarla o kadar çok karşılaşıyorsunuz ki artık neredeyse refleks olarak çözüyorsunuz.

“The local server does not have an up-to-date copy” hatası: Bu genellikle AD replikasyon gecikmesinden kaynaklanır. Güncelleme öncesinde AD sağlığını kontrol etmek şart:

repadmin /showrepl
repadmin /replsummary

.NET versiyon uyumsuzluğu: CU kurulumunun en sık durduğu noktalardan biri. Microsoft’un desteklediği .NET versiyonunu önce yükleyin, sonra Exchange güncellemesine geçin. .NET güncellemesi sonrasında mutlaka yeniden başlatın, ardından Exchange kurulumunu yapın.

IIS yeniden bağlama sorunları: CU sonrasında OWA çalışmıyor ama servisler ayakta görünüyorsa, IIS’i sıfırlamak çoğunlukla işe yarıyor:

iisreset /noforce
# Eğer noforce çalışmazsa
net stop W3SVC
net start W3SVC

Sertifika servis bağlamalarının kaybolması: Kurulum sonrasında sertifikayı servislere yeniden atamak gerekebilir:

$thumbprint = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Enable-ExchangeCertificate -Thumbprint $thumbprint -Services IIS,SMTP -Force

Güncelleme Takvimi ve Otomasyon

Exchange güncellemelerini tamamen otomasyona bırakmak önerilen bir yaklaşım değil, çünkü her CU kurulumu ortama özgü doğrulama gerektiriyor. Ama hazırlık adımlarını otomatize etmek zaman kazandırıyor.

Bir önceki bölümdeki sağlık kontrollerini bir script haline getirip, güncelleme öncesinde otomatik rapor oluşturabilirsiniz. Bunu görev zamanlayıcıda her Salı günü (Patch Tuesday sonrası) çalışacak şekilde ayarlamak, sizi güncellemeler için uyarabilir.

Güncelleme takvimi için pratik bir yaklaşım:

  • Test ortamı: Microsoft yayınladıktan sonraki ilk iki hafta içinde uygulayın
  • Üretim ortamı: Test ortamında en az bir hafta sorunsuz çalışma sonrasında planlayın
  • Bakım penceresi: Haftanın en düşük trafikli gecesini seçin, çoğu ortam için Cuma veya Cumartesi gecesi

Bakım penceresi için change management sistemine kayıt oluştururken şu bilgileri dahil edin: etkilenen kullanıcı sayısı, beklenen kesinti süresi, geri alma planı (rollback prosedürü) ve acil iletişim kanalları.

Güvenlik Yamalarını Takip Etme

Microsoft, Exchange güvenlik açıklarını MSRC (Microsoft Security Response Center) üzerinden yayınlıyor. Bu sayfayı RSS ile takip edebilirsiniz. Ayrıca CISA Known Exploited Vulnerabilities kataloğunu da izlemenizi tavsiye ederim; Exchange açıkları burada sıklıkla yer alıyor ve kurumsal compliance açısından bu listedeki açıkları kapatmak çoğu zaman zorunlu hale geliyor.

ProxyLogon, ProxyShell, ProxyNotShell gibi son yıllarda ortaya çıkan kritik Exchange açıklarını düşündüğünüzde, SU’ları Patch Tuesday sonrasında en geç bir hafta içinde uygulamak artık bir standart haline gelmeli.

Hangi güvenlik yamalarının uygulandığını raporlamak için:

# Yüklü Windows güncellemelerini listele
Get-HotFix | Where-Object {$_.InstalledOn -gt (Get-Date).AddMonths(-3)} | 
  Select-Object HotFixID, Description, InstalledOn | 
  Sort-Object InstalledOn -Descending

Sonuç

Exchange güncelleme yönetimi, bir kez doğru yapılandırıldığında rutin bir süreç haline gelebiliyor. Ama bu noktaya gelmek için önce sistematik bir yaklaşım benimsemek, hazırlık scriptlerini hazırlamak ve her güncelleme sonrasında öğrenilen dersleri bir sonrakine yansıtmak gerekiyor.

En büyük risk, güncelleme yapmamak değil, plansız güncelleme yapmak. Ortamı tanıyan, bakım penceresi belirlenmiş, rollback planı hazır ve doğrulama adımları netleşmiş bir güncelleme süreci, Exchange gibi kritik bir sistemde sizi hem güvenlik açıklarından hem de operasyonel sürprizlerden koruyor.

Bir sonraki CU yayınına kadar mevcut versiyonunuzun sağlık durumunu düzenli izleyin, SU’ları geciktirmeyin ve her büyük güncelleme öncesinde bu yazıdaki hazırlık adımlarını bir kontrol listesi olarak kullanın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir