Exchange Server Nedir? Kurumsal E-posta Altyapısının Temelleri

Neden Kendi Mail Sunucun?

Bulut tabanlı e-posta hizmetleri yaygınlaşsa da, verinin kurum sınırları içinde kalmasını gerektiren düzenlemeler ya da mevcut altyapı yatırımları nedeniyle şirket içi Exchange kurulumları hâlâ yaygındır.

Exchange Server, posta kutularını, dağıtım gruplarını, takvimleri ve ortak klasörleri tek bir yönetim noktasından denetlemenizi sağlar. Karşılığında ise kurulum, sertifika, yedekleme ve güvenlik sorumluluğu tamamen size geçer.

Karar vermeden önce iki modelin gerçekte neyi devrettiğine bakmak faydalı olur:

Konu	Şirket içi Exchange	Bulut (Exchange Online)
Verinin konumu	Kendi veri merkezinizde	Sağlayıcının bölgesinde
Güncelleme / yama	Sizde — güvenlik açıkları kritik	Sağlayıcıda
Sertifika yönetimi	Sizde	Sağlayıcıda
Yedekleme ve kurtarma	Sizde	Kısmen sağlayıcıda
Maliyet biçimi	Peşin donanım + lisans + emek	Kullanıcı başına aylık
Özelleştirme sınırı	Geniş	Sağlayıcının izin verdiği kadar

Şirket içi tercih ediliyorsa, yama yönetimi pazarlık konusu değildir. Exchange, internete açık olduğu için geçmişte en çok hedef alınan ürünlerden biri olmuştur; güncellenmeyen bir sunucu kurumun en zayıf noktasıdır.

Sunucu Rolleri ve Kurulum Öncesi

Exchange kurulumu, Active Directory ortamının hazır olmasını şart koşar. Şema hazırlığı yapılmadan kurulum ilerlemez ve bu adım forest genelinde kalıcı bir değişikliktir — geri alınamaz, bu yüzden önce test ortamında denenir.

# Şemayı ve AD'yi hazırla (Schema Admins + Enterprise Admins yetkisi gerekir)
.\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareSchema
.\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAD /OrganizationName:"Bapati"
.\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAllDomains

# Ön gereksinim Windows özellikleri
Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, `
  RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, `
  WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, `
  Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, `
  Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, `
  Web-ISAPI-Filter, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, `
  Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, `
  Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

Klasik rol ayrımında Mailbox rolü posta kutularını barındırır, Client Access istemci bağlantılarını karşılar, Hub Transport ise mesaj yönlendirmesini üstlenir. Yeni sürümlerde bu roller Mailbox rolünde birleştirilmiş, yalnızca Edge Transport ayrı kalmıştır.

Mailbox Database: Hepsini Tek Yere Koymayın

Tüm posta kutularını tek bir veritabanında toplamak kurulum aşamasında pratik görünür; ancak yedekleme süresi ve kurtarma riski açısından sağlıklı değildir. Tek veritabanı bozulduğunda herkes etkilenir ve geri dönüş, veritabanının tamamının kopyalanması kadar sürer.

# Amaca göre ayrı veritabanları; veri ve log farklı disklerde
New-MailboxDatabase -Name "DB-Personel" `
  -EdbFilePath  "E:\Exchange\DB-Personel\DB-Personel.edb" `
  -LogFolderPath "F:\Exchange\Logs\DB-Personel"

New-MailboxDatabase -Name "DB-Arsiv" `
  -EdbFilePath  "E:\Exchange\DB-Arsiv\DB-Arsiv.edb" `
  -LogFolderPath "F:\Exchange\Logs\DB-Arsiv"

Mount-Database "DB-Personel"
Mount-Database "DB-Arsiv"

# Boyut ve son yedek tarihini izle — "son tam yedek" alanı boşsa alarm ver
Get-MailboxDatabase -Status |
  Select-Object Name, DatabaseSize, LastFullBackup, Mounted |
  Format-Table -AutoSize

Veri (.edb) ve log dosyalarını farklı disklere yerleştirmek yalnızca performans meselesi değildir: log diski dolduğunda veritabanı kendini kapatır, ama veri diski ayrı olduğu için kurtarma çok daha temiz ilerler.

Tam yedek almak da bir bakım işidir. Exchange, işlem loglarını ancak başarılı bir tam yedek sonrası temizler (circular logging kapalıysa). Yedek alınmayan bir sunucuda log diski sessizce dolar ve posta akışı bir sabah durur.

Accepted Domain ve E-mail Address Policy

Exchange'in hangi alan adına gelen postaları kabul edeceğini accepted domain tanımı belirler. Bu tanım olmadan dışarıdan gelen mailler reddedilir.

Accepted domain türü	Anlamı	Ne zaman
Authoritative	Bu alan adının tüm kutuları bende	Ana kurumsal alan adı
Internal Relay	Bir kısmı bende, kalanını içeride başka sunucuya ilet	Göç dönemi, birleşme
External Relay	Kutular dışarıda, ben yalnızca aktarırım	Bağlı şirket, dış sağlayıcı

New-AcceptedDomain -Name "Bapati" -DomainName "bapati.com" -DomainType Authoritative

# Yeni açılan her kutuya ad.soyad@bapati.com biçiminde adres ata
New-EmailAddressPolicy -Name "Standart" `
  -IncludedRecipients MailboxUsers `
  -EnabledEmailAddressTemplates "SMTP:%g.%s@bapati.com" `
  -Priority 1
Update-EmailAddressPolicy -Identity "Standart"

Authoritative yerine yanlışlıkla relay seçmek, mailin kendi sunucusuna geri dönüp durduğu mail döngüsü hatasının klasik sebebidir.

Dışarıdan Mail Alabilmek: MX, NAT ve Port 25

Bir kurumun mail alabilmesi için üç şeyin aynı anda doğru olması gerekir: DNS'te MX kaydı, güvenlik duvarında 25 portunun yönlendirilmesi ve Exchange üzerinde uygun receive connector.

Bugün bunlara dördüncüsü de eklendi: gönderdiğiniz mailin karşı tarafça kabul edilmesi için kimlik doğrulama kayıtları. Bunlar olmadan mailleriniz büyük sağlayıcılarda doğrudan spam klasörüne düşer.

Kayıt	Ne söyler	Örnek
MX	Bu alan adının postası hangi sunucuya teslim edilecek	10 mail.bapati.com
SPF	Bu alan adı adına kimler mail gönderebilir	v=spf1 mx -all
DKIM	Mail yolda değiştirilmemiş (imza)	Seçici + genel anahtar
DMARC	SPF/DKIM başarısızsa ne yapılsın	v=DMARC1; p=quarantine
PTR	Giden IP'nin ters kaydı sunucu adıyla uyuşuyor	ISP'den istenir

Sorun yaşandığında tahmin yürütmek yerine mesaj izleme kayıtlarına bakmak gerekir. Mailin nerede takıldığını tek komut gösterir:

# Son 2 saatte bu adrese gelen/giden her hareket
Get-MessageTrackingLog -Start (Get-Date).AddHours(-2) `
  -Recipients "ayse.yilmaz@bapati.com" |
  Select-Object Timestamp, EventId, Source, Sender, MessageSubject |
  Sort-Object Timestamp

# Kuyrukta bekleyen var mı, sebebi ne?
Get-Queue | Where-Object { $_.MessageCount -gt 0 } |
  Select-Object Identity, Status, MessageCount, LastError

EventId alanı okumayı bilene çok şey söyler: RECEIVE geldi, DELIVER kutuya düştü, FAIL reddedildi, DEFER ertelendi. Kayıtta hiç iz yoksa mail sunucuya hiç ulaşmamış demektir; sorun DNS ya da güvenlik duvarındadır.

OWA, Sertifika ve O Meşhur Uyarı

Outlook Web App, kullanıcıların tarayıcıdan e-postaya erişmesini sağlar. İç ağda çalıştırmak kolaydır; asıl mesele dışarıya güvenli biçimde açmaktır.

Kurulumla gelen self-signed sertifika tarayıcıda güven uyarısı üretir. Uyarının en sık sebebi, sertifikadaki adın kullanıcıların yazdığı adresle uyuşmamasıdır. Çözüm iki adımlıdır: dış adı kapsayan geçerli bir sertifika, ve iç/dış URL'lerin aynı ada hizalanması.

$ad = "mail.bapati.com"
foreach ($svc in "OWA","ECP","OAB","EWS","ActiveSync","MAPI") {
  switch ($svc) {
    "OWA"         { Set-OwaVirtualDirectory        -Identity "*\owa (Default Web Site)"        -InternalUrl "https://$ad/owa"        -ExternalUrl "https://$ad/owa" }
    "ECP"         { Set-EcpVirtualDirectory        -Identity "*\ecp (Default Web Site)"        -InternalUrl "https://$ad/ecp"        -ExternalUrl "https://$ad/ecp" }
    "OAB"         { Set-OabVirtualDirectory        -Identity "*\OAB (Default Web Site)"        -InternalUrl "https://$ad/OAB"        -ExternalUrl "https://$ad/OAB" }
    "EWS"         { Set-WebServicesVirtualDirectory -Identity "*\EWS (Default Web Site)"       -InternalUrl "https://$ad/EWS/Exchange.asmx" -ExternalUrl "https://$ad/EWS/Exchange.asmx" }
    "ActiveSync"  { Set-ActiveSyncVirtualDirectory -Identity "*\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl "https://$ad/Microsoft-Server-ActiveSync" -ExternalUrl "https://$ad/Microsoft-Server-ActiveSync" }
    "MAPI"        { Set-MapiVirtualDirectory       -Identity "*\mapi (Default Web Site)"       -InternalUrl "https://$ad/mapi"       -ExternalUrl "https://$ad/mapi" }
  }
}

# Otomatik yapılandırma adresi de aynı ada bakmalı
Set-ClientAccessService -Identity EXCH01 -AutoDiscoverServiceInternalUri "https://$ad/Autodiscover/Autodiscover.xml"

İç ağdaki kullanıcıların da dış adı çözebilmesi için iç DNS'te aynı ada bir kayıt açmak (split-brain DNS) gerekir; aksi halde ofiste sertifika uyarısı, dışarıda sorunsuz erişim gibi tuhaf bir tablo çıkar.

Kota ve Arşivleme

Sınırsız posta kutusu, er ya da geç dolan bir disk demektir. Exchange üç eşik sunar ve bunları veritabanı düzeyinde tanımlayıp istisnaları kutu bazında yönetmek en sürdürülebilir yoldur.

Eşik	Aşılınca ne olur
IssueWarningQuota	Kullanıcıya uyarı maili gider, her şey çalışır
ProhibitSendQuota	Gönderemez, almaya devam eder
ProhibitSendReceiveQuota	Ne gönderir ne alır — gönderen geri dönüş alır

Set-MailboxDatabase "DB-Personel" `
  -IssueWarningQuota           4.5GB `
  -ProhibitSendQuota           5GB `
  -ProhibitSendReceiveQuota    5.5GB

# En çok yer kaplayan 15 kutu — disk dolmadan önce bakılacak yer
Get-MailboxStatistics -Database "DB-Personel" |
  Sort-Object TotalItemSize -Descending |
  Select-Object DisplayName, TotalItemSize, ItemCount -First 15

Journal Rule ise kurumsal yazışmaların ayrı bir posta kutusunda saklanmasını sağlar; yasal saklama yükümlülüğü olan kurumlar için gereklidir. Journaling'in disk tüketimini ciddi biçimde artırdığını — pratikte yazışma hacmini ikiye katladığını — ve bu nedenle kapsamının baştan planlanması gerektiğini unutmamak gerekir.

Hibrit: İkisinin Arasında Kalmak

Pratikte kurumların çoğu ikisinin arasında bir yerdedir. Bir kısım posta kutusu şirket içinde, bir kısmı bulutta durur; kullanıcılar bu ayrımı hissetmez. Buna hibrit yapılandırma denir ve genellikle iki sebeple kurulur: kademeli göç, ya da bazı kutuların kalıcı olarak içeride tutulması zorunluluğu.

Hibritin bedeli, iki ortamın da yönetilmesidir. Kimlik eşitlemesi, ortak alan adı, serbest/meşgul takvim paylaşımı ve posta akışı yönlendirmesi ayrı ayrı kurulur.

Bileşen	Görevi
Azure AD Connect	Şirket içi AD hesaplarını buluta eşitler
Hybrid Configuration Wizard	Bağlayıcıları ve güven ilişkisini kurar
Organization Relationship	İki taraf arasında takvim paylaşımı
Send/Receive Connector	Posta akışının iki yönde de sürmesi

# Bir posta kutusunu buluta taşı (şirket içi kabuktan)
New-MoveRequest -Identity "ayse.yilmaz@bapati.com" `
  -Remote -RemoteHostName "mail.bapati.com" `
  -TargetDeliveryDomain "bapati.mail.onmicrosoft.com" `
  -RemoteCredential (Get-Credential) `
  -BadItemLimit 10

# Taşımanın durumu
Get-MoveRequest | Get-MoveRequestStatistics |
  Select-Object DisplayName, StatusDetail, PercentComplete, BytesTransferred

Göç tamamlansa bile şirket içi Exchange sunucusu genellikle tamamen kaldırılamaz: hesaplar şirket içi AD'de yönetildiği sürece, posta özniteliklerini düzenlemek için en az bir yönetim sunucusu gerekir. Bu sunucunun da güncel tutulması gerektiğini planlamaya dahil etmek gerekir.

Kurulumdan Sonra Unutulan Üç Şey

Sahada en sık karşılaşılan sorunlar kurulum hatalarından değil, kurulumdan sonra yapılmayanlardan doğar:

Atlanan iş	Ne zaman patlar
Tam yedek planlanmamış	Log diski dolduğu gün posta akışı durur
Sertifika bitiş tarihi izlenmiyor	Süre dolduğu sabah kimse bağlanamaz
Güvenlik güncellemeleri ertelenmiş	İnternete açık sunucu hedef olur
SPF/DKIM/DMARC kurulmamış	Giden mailler karşı tarafta spam'e düşer
Disk boş alanı izlenmiyor	Veritabanı kendini kapatır

Bu beş maddeyi bir izleme sistemine bağlamak, Exchange yönetiminin gündelik yükünü belirgin biçimde azaltır.

---

Daha fazlası: Exchange Server eğitim serimizde kurulumdan MX kaydına, public folder'dan room mailbox yapılandırmasına kadar tüm adımları uygulamalı olarak anlatıyoruz.

Videoyu sitemizde izle  ·  YouTube'da aç  ·  Kanala abone ol

---

Daha fazlası: Exchange kurulumunu ve yönetimini adım adım gösterdiğimiz seriyle devam edebilirsiniz.

Videoyu sitemizde izle  ·  YouTube'da aç  ·  Bapati kanalına abone ol