Exchange Server’da Sorun Giderme: Yaygın Hatalar ve Çözümleri

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

Yıllar önce bir Cuma akşamı saat 18:30’da telefonum çaldı. Müşterinin Exchange ortamında tüm kullanıcılar mail gönderip alamaz hale gelmişti. Hafta sonu tatile çıkmak üzereydim. O gece yaşadıklarım Exchange sorun giderme konusunda bana onlarca saatlik eğitimden daha fazlasını öğretti. Bu yazıda o tür kriz anlarında işe yarayan, sahadan gelen gerçek çözümleri paylaşacağım.

Exchange Servislerini Hızlıca Kontrol Etme

İlk yapmanız gereken şey Exchange servislerinin durumunu kontrol etmek. Bunu GUI’dan yapmak zaman kaybı, PowerShell ile gidin:

Get-Service | Where-Object {$_.DisplayName -like "*Exchange*"} | Select-Object Name, Status, StartType

Çıktıda “Stopped” gören servisler varsa hemen not alın. Özellikle şu servislere dikkat edin:

  • MSExchangeTransport: Bu durunca mail akışı tamamen kesilir
  • MSExchangeIS: Information Store, bu olmadan posta kutuları erişilemez hale gelir
  • MSExchangeFrontEndTransport: Client Access tarafı, OWA ve ActiveSync burada
  • W3SVC: IIS servisi, bu olmadan hiçbir web tabanlı Exchange bileşeni çalışmaz
  • MSExchangeADTopology: Active Directory bağlantısı için kritik

Servisleri toplu başlatmak için:

Get-Service | Where-Object {$_.DisplayName -like "*Exchange*" -and $_.Status -eq "Stopped"} | Start-Service

Ama dikkat edin, her durduğu görülen servisi körü körüne başlatmak sorunun üstünü örtmek olabilir. Neden durduğunu anlamak için Event Log’a bakın.

Mail Akışı Sorunlarını Tespit Etme

Mail gidip gelmiyor ama servisler ayakta görünüyor. Bu klasik bir senaryo. Önce mail queue durumuna bakın:

Get-Queue | Format-Table Identity, Status, MessageCount, NextHopDomain -AutoSize

Eğer burada binlerce mesaj birikmiş kuyruk görüyorsanız ve status “Retry” ise, downstream sunucuyla bağlantı problemi var demektir. “Suspended” görüyorsanız birileri kuyruğu manuel olarak durdurmuş olabilir.

Kuyruktaki mesajlara bakın:

Get-Message -Queue "SUNUCUADISubmission" | Select-Object FromAddress, Subject, Status, LastError | Format-List

LastError alanı genellikle sizi doğrudan sorunun kaynağına götürür. “451 4.4.0 DNS query failed” görüyorsanız DNS sorunu var. “421 4.2.1 Unable to connect” görüyorsanız hedef sunucuya erişim yok.

DNS testini şöyle yapabilirsiniz:

Resolve-DnsName -Name "mail.hedefalan.com" -Type MX
Test-NetConnection -ComputerName "hedefip" -Port 25

Database Bağlantı Sorunları ve Çözümleri

Kullanıcılar Outlook’u açıyor ama “Sunucuya bağlanılamıyor” diyor. Ya da OWA açılıyor ama giriş yapılamıyor. Bu durumda database mount durumuna bakın:

Get-MailboxDatabase -Status | Select-Object Name, Mounted, Server

“Mounted: False” gören database varsa bu ciddi bir durum. Önce neden unmount olduğunu anlayın:

Get-MailboxDatabase "DB_ADI" -Status | Select-Object *

Sonra mount etmeyi deneyin:

Mount-Database "DB_ADI"

Eğer hata verirse ve “dirty shutdown” durumundaysa, Exchange database’i tutarsız bir şekilde kapanmış demektir. Bu noktada ESEUtil devreye girer:

eseutil /mh "C:Program FilesMicrosoftExchange ServerV15MailboxDB_ADIDB_ADI.edb"

Çıktıda “State: Dirty Shutdown” yazıyorsa soft recovery deneyin:

eseutil /r E0n /l "C:Program FilesMicrosoftExchange ServerV15MailboxDB_ADI" /d "C:Program FilesMicrosoftExchange ServerV15MailboxDB_ADI"

Buradaki “E0n” log prefix’ini database özelliklerinden ya da ESEUtil /mh çıktısından öğrenebilirsiniz. E00, E01, E02 gibi değerler olabilir.

Eğer bu da çözümlemediyse hard recovery gerekebilir ki bu veri kaybı riski taşır, mutlaka backup kontrolü yapın.

OWA ve ActiveSync Erişim Sorunları

“OWA açılmıyor” şikayeti Exchange yöneticilerinin en sık duyduğu şeylerden. Çoğu zaman IIS ve sanal dizin konfigürasyonuyla ilgili.

Önce sanal dizinleri kontrol edin:

Get-OwaVirtualDirectory | Select-Object Name, Server, InternalUrl, ExternalUrl
Get-EcpVirtualDirectory | Select-Object Name, Server, InternalUrl, ExternalUrl
Get-ActiveSyncVirtualDirectory | Select-Object Name, Server, InternalUrl, ExternalUrl

URL’ler boş görünüyorsa ya da yanlış hostname içeriyorsa sorun buradan kaynaklanıyor olabilir. Düzeltmek için:

Set-OwaVirtualDirectory "OWA (Default Web Site)" -InternalUrl "https://mail.sirket.com/owa" -ExternalUrl "https://mail.sirket.com/owa"

Değişikliklerin etkin olması için IIS’i yeniden başlatın:

iisreset /noforce

SSL sertifika sorunları da OWA’yı çökertebilir. Sertifika durumunu kontrol edin:

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

“Status: Invalid” ya da tarihi geçmiş sertifika görüyorsanız hemen yenilemeniz gerekiyor. Ayrıca sertifikanın Exchange servislerine atanıp atanmadığını kontrol edin:

Get-ExchangeCertificate | Where-Object {$_.Services -ne "None"} | Format-List Thumbprint, Subject, Services

Autodiscover Konfigürasyon Sorunları

Outlook otomatik yapılandırma yapamıyor, kullanıcılar sürekli şifre soruyor ya da profil bozuk görünüyorsa Autodiscover’a bakın. Bu servisi test etmek için:

Test-OutlookWebServices -Identity [email protected] -MailboxCredential (Get-Credential)

Ya da dışarıdan test etmek için şu komutu kullanın:

Test-OutlookConnectivity -ProbeIdentity OutlookSelfTestProbe

Autodiscover SCP (Service Connection Point) kayıtlarını kontrol edin:

Get-ClientAccessService | Select-Object Name, AutoDiscoverServiceInternalUri

Bu URI’nin doğru olduğundan ve DNS’te çözümlenebildiğinden emin olun. Dışarıdan erişim için ise DNS’te autodiscover.sirket.com’un doğru IP’ye işaret ettiğini doğrulayın.

Transport Kuralları ve Spam Filtresi Kaynaklı Sorunlar

Bazen mail akışı problemi transport kurallarından kaynaklanır. Özellikle güvenlik ekibinin eklediği kurallar farkında olmadan tüm mail akışını etkileyebilir.

Get-TransportRule | Select-Object Name, Priority, State, Description | Format-List

Şüpheli görünen ya da yakın zamanda değiştirilen kuralları devre dışı bırakarak test yapabilirsiniz:

Disable-TransportRule "Kural_ADI"

Content Filter ve Anti-spam ayarlarını kontrol edin:

Get-ContentFilterConfig | Select-Object Enabled, SCLDeleteThreshold, SCLRejectThreshold, SCLJunkThreshold
Get-SenderFilterConfig | Select-Object Enabled, BlockedSenders

Eğer SCLDeleteThreshold çok düşük ayarlanmışsa meşru mailler de silinebilir. Örneğin bu değer 1 olarak ayarlanmışsa neredeyse her mail silinecektir.

Message Tracking ile Sorun Kökünü Bulma

En güçlü araçlardan biri message tracking. “Mail göndermedim” ya da “Mail almadım” denildiğinde önce tracking log’a bakın:

Get-MessageTrackingLog -Sender "[email protected]" -Start (Get-Date).AddHours(-24) -EventId SEND | Select-Object Timestamp, EventId, Source, Sender, Recipients, MessageSubject

Alıcı tarafından aramak için:

Get-MessageTrackingLog -Recipients "[email protected]" -Start (Get-Date).AddHours(-24) | Select-Object Timestamp, EventId, Source, Sender, Recipients, MessageSubject | Sort-Object Timestamp

EventId değerlerini anlamak önemli:

  • RECEIVE: Mesaj alındı
  • SEND: Mesaj gönderildi
  • DELIVER: Posta kutusuna teslim edildi
  • FAIL: Gönderim başarısız
  • REDIRECT: Başka hedefe yönlendirildi
  • RESOLVE: Alıcı adresi çözümlendi
  • EXPAND: Dağıtım listesi genişletildi

Eğer RECEIVE var ama DELIVER yoksa mesaj bir noktada takılmış demektir.

Disk Doluluğu ve Log Dosyası Yönetimi

Exchange’in en sinsi düşmanı dolan diskler. Transaction log dosyaları birikmeye başladığında hem performans düşer hem de database mount olmayabilir.

Disk kullanımına bakın:

Get-MailboxDatabase -Status | Select-Object Name, DatabaseSize, AvailableNewMailboxSpace

Transaction logların birikip birikmediğini kontrol edin:

$logpath = "C:Program FilesMicrosoftExchange ServerV15MailboxDB_ADILogs"
(Get-ChildItem $logpath -Filter "*.log" | Measure-Object -Property Length -Sum).Sum / 1GB

DAG (Database Availability Group) ortamında circular logging kapalıysa loglar backup yapılana kadar silinmez. Düzenli backup alındıktan sonra loglar temizlenir. Backup alınamıyorsa circular logging açabilirsiniz ama bu production ortamda önerilmez.

Eğer anlık müdahale gerekiyorsa ve disk kritik seviyeye geldiyse, Exchange Management Shell üzerinden şunu çalıştırın:

Get-MailboxDatabase | Select-Object Name, Server, LogFolderPath, EdbFilePath

Hangi path’lerin dolduğunu tespit edip ilgili volume’ü genişletin ya da eski arşiv logları temizleyin. Ama log silme işlemini yaparken son derece dikkatli olun, aktif log sırası üzerindeki logları silmek database’i bozar.

Permission ve Delegate Sorunları

Kullanıcılar başkasının posta kutusuna erişemiyor ya da delegate olarak mail gönderemiyorsa önce permission’ları kontrol edin:

Get-MailboxPermission -Identity "hedef_kullanici" | Where-Object {$_.User -notlike "NT AUTHORITY*" -and $_.User -notlike "S-1-*"} | Select-Object Identity, User, AccessRights

“Send As” yetkisi için:

Get-RecipientPermission -Identity "hedef_kullanici" | Select-Object Identity, Trustee, AccessRights

“Send on Behalf” yetkisi için:

Get-Mailbox "hedef_kullanici" | Select-Object -ExpandProperty GrantSendOnBehalfTo

Eksik yetki eklemek için:

Add-MailboxPermission -Identity "hedef_kullanici" -User "yetkili_kullanici" -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity "hedef_kullanici" -Trustee "yetkili_kullanici" -AccessRights SendAs

Event Log Okumayı Alışkanlık Haline Getirin

Tüm bu komutlardan önce aslında yapmanız gereken en temel şey Event Log kontrolü. Application ve System log’larında Exchange ile ilgili hataları filtreleyin:

Get-EventLog -LogName Application -Source "*Exchange*" -EntryType Error,Warning -Newest 50 | Select-Object TimeGenerated, EventID, Source, Message | Format-List

MSExchange ile başlayan kaynak adlarına dikkat edin. Event ID’leri Microsoft’un Exchange ekibi çok iyi belgelemiştir, bir Event ID ile arama yapıldığında genellikle doğrudan çözüme ulaşılır.

Kritik Event ID’lerden bazıları:

  • 1000-1002: Application crash, ciddi servis sorunları
  • 9519, 9518: Mailbox database ile ilgili kritik hatalar
  • 4999: Watson raporu, genellikle Exchange crash öncesinde görülür
  • 2080: Back pressure mekanizması devrede, disk ya da bellek baskısı var

Back pressure durumunda Exchange mail kabul etmeyi durdurabilir. Bunu kontrol edin:

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

Yaygın Hata Mesajları ve Anlamları

Sahada en sık karşılaşılan hata mesajları ve ne yapmanız gerektiği:

“550 5.7.1 Unable to relay”: Relay izni yok. Gönderen IP’yi veya hesabı Receive Connector’da yetkilendirin. Internal sunuculardan gelen mesajlarda bu hata alınıyorsa Receive Connector authentication ayarlarına bakın.

“452 4.3.1 Insufficient system resources”: Disk doldu ya da back pressure devrede. Hemen disk durumuna bakın.

“500 5.3.3 Unrecognized command”: SSL/TLS zorunlu tutulmuş bir connector’a plain text bağlantı denenmiş. Telnet ile debug yapıyorsanız bu normaldir.

“421 4.3.2 Service not available”: Transport servisi yeni başladı ya da overload altında. Birkaç dakika bekleyip tekrar deneyin, düzelmezse servis loglarına bakın.

NDR kodu 5.2.2: Alıcının posta kutusu doldu. Quota’ya bakın:

Get-Mailbox "kullanici" | Select-Object DisplayName, IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota
Get-MailboxStatistics "kullanici" | Select-Object DisplayName, TotalItemSize, DatabaseName

Proaktif Sağlık Kontrolü

Sorun çıkmadan önce ortamın sağlığını düzenli kontrol etmek en iyi savunmadır. Bunun için Exchange’in yerleşik araçlarını kullanın:

Test-ServiceHealth

Bu komut tüm Exchange servislerinin beklenen şekilde çalışıp çalışmadığını özetler. Ayrıca mail akışını end-to-end test etmek için:

Test-Mailflow -TargetMailboxServer SUNUCUADI

Ortamın genel sağlık durumu için:

Get-HealthReport -Server SUNUCUADI | Where-Object {$_.AlertValue -ne "Healthy"} | Select-Object HealthSet, AlertValue, LastTransitionTime | Format-List

Bu komut sağlıklı olmayan bileşenleri listeler. Managed Availability’nin topladığı verileri görürsünüz.

Sonuç

Exchange sorun giderme, deneyimle geliştirilen bir sezgi işidir. Komutları ezberlemekten çok, sistemin nasıl çalıştığını anlamak önemli. Mail akışının SMTP seviyesinde nasıl ilerlediğini, database motorunun nasıl çalıştığını ve IIS’in Exchange ile nasıl entegre olduğunu kavrarsanız yeni bir hatayla karşılaştığınızda bile mantıklı bir yol izleyebilirsiniz.

O Cuma akşamı yaşadığım kriz, biriken transaction logların diski doldurmasından kaynaklanıyordu. Backup job aylardır hata veriyormuş ama kimse izlemiyormuş. Disk dolunca database unmount oldu, servisler peş peşe düştü. Çözüm teknik olarak basitti, asıl sorun monitoring eksikliğiydi.

Düzenli test backupları alın, disk kullanımını izleyin, servis sağlığını günlük kontrol edin. Exchange karmaşık bir sistemdir ama sizi nadiren beklenmedik şekilde yarı yolda bırakır. Çoğu zaman uyarılar zaten oradaydı, biz bakmamıştık.

Bir yanıt yazın

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