Exchange Server ile Active Directory Entegrasyonu
Yıllarca Exchange ortamlarında çalışmış biri olarak şunu rahatlıkla söyleyebilirim: Exchange’i Active Directory’den bağımsız düşünmek mümkün değil. Bu ikisi o kadar iç içe geçmiş durumda ki, birinde yapılan bir hata doğrudan diğerini etkiliyor. Pek çok sysadmin arkadaşım “Exchange kurdum, çalışıyor” diyip geçiyor ama altında yatan AD entegrasyonunu tam anlamıyla kavramadan Exchange’i yönetmek, karanlıkta el yordamıyla ilerlemek gibi.
Bu yazıda Exchange Server ile Active Directory entegrasyonunu, günlük operasyonlarda karşılaştığım gerçek senaryolarla birlikte ele alacağım. Hem teoriyi hem de pratiği bir arada işleyeceğiz.
Exchange ve Active Directory: Temel İlişki
Exchange Server, kullanıcı hesaplarını, posta kutularını ve yapılandırma bilgilerini Active Directory içinde saklar. Bu bir tercih değil, Exchange’in mimarisi gereği böyle tasarlanmış. Exchange kurulduğunda AD schema’sına yaklaşık 4.000’den fazla attribute ve object class eklenir. Yani Exchange’i AD’ye “monte ediyorsunuz” desem yanlış olmaz.
Bu entegrasyonun iki temel bileşeni var:
- Schema Partition: Exchange’e özgü nesne tanımları buraya yazılır, forest genelinde geçerlidir
- Configuration Partition: Exchange organizasyonu yapılandırması, tüm domain controller’lara replicate edilir
- Domain Partition: Kullanıcı posta kutusu bilgileri, her domain’e özgüdür
Exchange, AD’yi hem bir veritabanı hem de bir kimlik doğrulama servisi olarak kullanır. Bu yüzden AD sağlıklı değilse Exchange de sağlıklı çalışmaz.
Schema Extension: İşin Temeli
Exchange kurulumunun ilk adımı schema genişletmektir. Bunu setup.exe otomatik yapabilir ama büyük ortamlarda Schema Admins yetkisine sahip ayrı bir hesapla manuel yapmak daha kontrollü.
# Exchange kurulum medyasından schema extension
.Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
# Schema extension sonrasını doğrulama
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
-Filter {name -like "ms-Exch*"} | Measure-Object
Schema extension tamamlandıktan sonra replicate olması için beklemek gerekiyor. Küçük ortamlarda bu birkaç dakika sürerken, çok siteli büyük ortamlarda saatler alabilir. Ben bir keresinde bu adımı atlayıp bir sonraki aşamaya geçmeye çalıştım ve kurulum yarıda kaldı. O yüzden şunu kontrol etmeden devam etmeyin:
# Schema versiyonunu kontrol et
$SchemaPath = (Get-ADRootDSE).schemaNamingContext
Get-ADObject -Identity "CN=ms-Exch-Schema-Version-Pt,$SchemaPath" `
-Properties rangeUpper | Select-Object rangeUpper
Exchange 2019 için bu değer 17003 olmalı. Farklı bir değer görüyorsanız schema extension tamamlanmamış demektir.
AD Hazırlığı: PrepareAD ve PrepareDomain
Schema extension’dan sonra iki kritik adım daha var. Bu adımları atlamak, sonradan çok başınızı ağrıtır.
# AD genelini hazırla (Enterprise Admins yetkisi gerekir)
.Setup.exe /PrepareAD /OrganizationName:"SirketinizAdi" `
/IAcceptExchangeServerLicenseTerms
# Her domain için ayrı ayrı çalıştır
.Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms
# Tüm domain'leri tek seferde hazırla
.Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms
PrepareAD komutu şunları yapar:
- Exchange için gerekli güvenlik gruplarını oluşturur (Exchange Trusted Subsystem, Exchange Windows Permissions vb.)
- Microsoft Exchange Containers’ı Configuration Partition’a ekler
- RBAC için gerekli role gruplarını oluşturur
Bu noktada önemli bir detay: Exchange Trusted Subsystem grubu, Exchange sunucularına AD üzerinde geniş yetkiler verir. Bu grubun üyelerini asla elle değiştirmeyin. Ben bir ortamda bu gruba yanlışlıkla ek sunucu eklendiğini gördüm ve bu yüzden güvenlik açığı oluşmuştu.
Recipient Management: Posta Kutularını Yönetmek
Exchange yönetiminin günlük koşuşturmasında en çok posta kutusu işlemleriyle uğraşırsınız. Exchange Management Shell (EMS) burada can kurtarır.
# Mevcut AD kullanıcısına posta kutusu bağla
Enable-Mailbox -Identity "cn=AhmetYilmaz,ou=Kullanicilar,dc=sirket,dc=com" `
-Database "Mailbox Database 01"
# Yeni kullanıcı oluşturup posta kutusu ver
New-Mailbox -Name "Fatma Kaya" `
-UserPrincipalName "[email protected]" `
-Password (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) `
-FirstName "Fatma" `
-LastName "Kaya" `
-Database "Mailbox Database 01" `
-OrganizationalUnit "OU=Kullanicilar,DC=sirket,DC=com"
Kullanıcıları toplu oluşturmanız gerektiğinde CSV’den okumak işi çok kolaylaştırır:
# CSV'den toplu posta kutusu oluşturma
$Kullanicilar = Import-Csv "C:UsersAdministratoryeni_kullanicilar.csv" `
-Encoding UTF8
foreach ($Kullanici in $Kullanicilar) {
try {
New-Mailbox -Name $Kullanici.AdSoyad `
-UserPrincipalName $Kullanici.UPN `
-Password (ConvertTo-SecureString $Kullanici.Sifre -AsPlainText -Force) `
-FirstName $Kullanici.Ad `
-LastName $Kullanici.Soyad `
-Database $Kullanici.Database `
-OrganizationalUnit $Kullanici.OU
Write-Host "$($Kullanici.AdSoyad) basariyla olusturuldu" -ForegroundColor Green
}
catch {
Write-Host "$($Kullanici.AdSoyad) olusturulamadi: $_" -ForegroundColor Red
}
}
Exchange ile AD’nin Senkronizasyon Mekanizması
Exchange, AD ile iletişim kurmak için DSAccess bileşenini kullanır. Bu bileşen hangi domain controller’ların kullanılacağına karar verir ve onlarla sürekli iletişim halindedir.
Sorun yaşandığında ilk bakılacak yer burası:
# Exchange'in kullandığı DC'leri göster
Test-SystemHealth | Where-Object {$_.Server -like "*DC*"}
# Exchange DSAccess loglarını kontrol et
Get-EventLog -LogName Application -Source "MSExchange ADAccess" `
-Newest 50 | Where-Object {$_.EntryType -eq "Error"} |
Select-Object TimeGenerated, Message | Format-List
Bir keresinde bir müşteride sabah erkenden Exchange’in mail teslim etmediğine dair çağrı aldım. Sebebi çok basitti: gece yapılan bir DC bakımı sırasında Exchange’in tercih ettiği DC’ler offline kalmış, ama Exchange yedek DC’ye geçememişti çünkü network ACL’leri yanlış yapılandırılmıştı. DSAccess logları bize bunu 5 dakikada gösterdi.
# Exchange'in iletişim kurduğu DC'leri ve durumlarını kontrol et
Test-ReplicationHealth
# Belirli bir DC ile Exchange bağlantısını test et
Test-MapiConnectivity -Server "EXCHANGE01" -Identity "[email protected]"
Global Address List ve AD Attribute Eşleşmesi
GAL (Global Address List) doğrudan AD attribute’larından beslenir. Kullanıcıların GAL’de doğru görünmesi için doğru attribute’ların dolu olması gerekir.
# Belirli kullanıcının GAL'de görünen bilgilerini güncelle
Set-Mailbox -Identity "[email protected]" `
-DisplayName "Ahmet Yilmaz" `
-Office "Istanbul Merkez" `
-Phone "+90 212 555 0100"
# AD attribute'larını doğrudan güncelle (Exchange dışı alanlar için)
Set-ADUser -Identity "ahmetyilmaz" `
-Department "Bilgi Teknolojileri" `
-Title "Sistem Yoneticisi" `
-Company "Sirket A.S."
# GAL'i yenile (offline adres defteri için)
Update-OfflineAddressBook -Identity "Default Offline Address Book"
Çok sık karşılaştığım bir senaryo: HR sistemi AD’yi güncelliyor ama Exchange GAL’de değişiklikler görünmüyor. Bunun nedeni genellikle OAB (Offline Address Book) güncelleme sıklığıdır.
# OAB güncelleme zamanlamasını kontrol et
Get-OfflineAddressBook | Select-Object Name, Schedule, LastRequestedTime
# Hemen güncellemeyi zorla
Get-OfflineAddressBook | Update-OfflineAddressBook
Distribution Group Yönetimi: AD Grupları ile Entegrasyon
Exchange dağıtım grupları AD üzerinde Universal Distribution Group olarak saklanır. Bunları hem Exchange’den hem de AD’den yönetebilirsiniz ama karışık yönetim ciddi sorunlara yol açar.
# Yeni dağıtım grubu oluştur
New-DistributionGroup -Name "IT-Ekibi" `
-DisplayName "IT Ekibi" `
-Alias "it-ekibi" `
-PrimarySmtpAddress "[email protected]" `
-OrganizationalUnit "OU=Gruplar,DC=sirket,DC=com" `
-MemberJoinRestriction Open
# Gruba üye ekle
Add-DistributionGroupMember -Identity "IT-Ekibi" `
-Member "[email protected]"
# Grup üyelerini listele
Get-DistributionGroupMember -Identity "IT-Ekibi" |
Select-Object Name, RecipientType, PrimarySmtpAddress
# Belirli bir kullanıcının üye olduğu tüm grupları bul
Get-DistributionGroup -Filter {Members -eq "CN=AhmetYilmaz,OU=Kullanicilar,DC=sirket,DC=com"} |
Select-Object Name, PrimarySmtpAddress
Dynamic Distribution Group’lar ise AD query’si kullanarak üyelerini otomatik belirler:
# Dinamik dağıtım grubu - İstanbul ofisindeki tüm kullanıcılar
New-DynamicDistributionGroup -Name "Istanbul-Ofis" `
-Alias "istanbul" `
-PrimarySmtpAddress "[email protected]" `
-RecipientFilter {(RecipientType -eq 'UserMailbox') -and (Office -eq 'Istanbul Merkez')}
Permissions ve RBAC: Kimin Ne Yapabileceği
Exchange’in rol tabanlı erişim kontrolü (RBAC) sistemi AD gruplarıyla çalışır. Bu yapıyı anlamak, hem güvenlik hem de yetki devri açısından kritiktir.
# Mevcut yönetim rolü atamalarını gör
Get-ManagementRoleAssignment |
Select-Object Name, Role, RoleAssigneeType, RoleAssigneeName |
Format-Table -AutoSize
# Help Desk ekibine sınırlı yetki ver
New-ManagementRoleAssignment -Name "HelpDesk-ResetPassword" `
-Role "Reset Password" `
-SecurityGroup "HelpDesk-Ekibi"
# Belirli OU için scoped permission
New-ManagementScope -Name "Istanbul-Kullanicilari" `
-RecipientRestrictionFilter {RecipientType -eq 'UserMailbox'} `
-RecipientRoot "OU=Istanbul,DC=sirket,DC=com"
New-ManagementRoleAssignment -Name "Istanbul-MailboxAdmin" `
-Role "Recipient Policies" `
-SecurityGroup "Istanbul-Admins" `
-CustomRecipientWriteScope "Istanbul-Kullanicilari"
Küçük ama önemli bir not: Exchange Recipient Administrators gibi eski Exchange 2007 döneminden kalma grupları Exchange 2013 ve sonrasında kullanmayın. RBAC, bunların yerini tamamen almıştır.
Çoklu Domain Ortamları: Child Domain ve Resource Forest
Birden fazla domain bulunan ortamlarda Exchange entegrasyonu biraz daha karmaşık hale gelir. Resource forest senaryosunda Exchange ayrı bir forest’ta çalışırken kullanıcılar farklı bir forest’tadır.
# Cross-forest mail flow için linked mailbox oluştur
New-Mailbox -LinkedMasterAccount "KullaniciForestahmetyilmaz" `
-LinkedDomainController "dc01.kullanici-forest.com" `
-LinkedCredential (Get-Credential) `
-Name "Ahmet Yilmaz" `
-UserPrincipalName "[email protected]" `
-Database "Mailbox Database 01"
# Forest güven ilişkisi sonrası GAL senkronizasyonu
# GALSync için ayrı PowerShell scripti kullanmak gerekir
# Microsoft Identity Manager veya üçüncü parti araçlar tercih edilir
Child domain senaryosunda önemli bir nokta: Her child domain için PrepareDomain çalıştırılmış olmalı. Bunu atlarsanız o domain’deki kullanıcılar Exchange nesneleri oluşturulurken hata alırsınız.
AD Replikasyon Sorunlarının Exchange’e Etkisi
Exchange yöneticilerinin çoğu AD replikasyon sorunlarını ihmal eder. Ama bu sorunlar doğrudan Exchange’e yansır: bir DC’de güncellenen posta kutusu bilgisi diğer DC’ye geçmediğinde tutarsızlıklar oluşur.
# AD replikasyon durumunu Exchange perspektifinden kontrol et
$AllDCs = Get-ADDomainController -Filter *
foreach ($DC in $AllDCs) {
$ReplicationResult = repadmin /showrepl $DC.HostName 2>&1
if ($ReplicationResult -match "error|fail") {
Write-Host "Replikasyon sorunu: $($DC.HostName)" -ForegroundColor Red
Write-Host $ReplicationResult -ForegroundColor Yellow
}
else {
Write-Host "$($DC.HostName) - OK" -ForegroundColor Green
}
}
Pratikte şunu gördüm: gece yarısı yapılan DC bakımları sırasında replikasyon bozulduğunda, sabah kullanıcılar OWA’ya giriş yapamaz veya Outlook profilleri Autoconfiguration sırasında hata verir. Exchange sunucusu bir DC’den aldığı bilgiyle çalışırken başka bir DC farklı bilgi sunuyorsa bu tür sorunlar yaşanır.
Monitoring: Entegrasyonu Sağlıklı Tutmak
Kurulum ve yapılandırma bir kez yapılır ama izleme sürekli olmalı. Exchange ve AD entegrasyonunu izlemek için birkaç kritik kontrol noktası var:
# Exchange ve AD sağlık kontrolü - günlük çalıştırılacak script
function Test-ExchangeADHealth {
Write-Host "=== Exchange AD Entegrasyon Saglik Kontrolu ===" -ForegroundColor Cyan
# Exchange servislerini kontrol et
$Servisler = @("MSExchangeADTopology", "MSExchangeIS", "MSExchangeTransport")
foreach ($Servis in $Servisler) {
$Durum = Get-Service -Name $Servis -ErrorAction SilentlyContinue
if ($Durum.Status -eq "Running") {
Write-Host "$Servis: Calisiyor" -ForegroundColor Green
}
else {
Write-Host "$Servis: DURDU!" -ForegroundColor Red
}
}
# AD topology servisini test et
Test-ServiceHealth | Where-Object {$_.RequiredServicesRunning -eq $false} |
ForEach-Object {
Write-Host "Sorun: $($_.Role) icin servisler eksik" -ForegroundColor Red
}
# Son 1 saatte AD access hatalarini say
$HataKontrol = Get-EventLog -LogName Application `
-Source "MSExchange ADAccess" `
-After (Get-Date).AddHours(-1) `
-EntryType Error `
-ErrorAction SilentlyContinue
if ($HataKontrol) {
Write-Host "Son 1 saatte $($HataKontrol.Count) AD Access hatasi!" -ForegroundColor Red
}
else {
Write-Host "AD Access: Sorun yok" -ForegroundColor Green
}
}
Test-ExchangeADHealth
Bu scripti Task Scheduler’a ekleyip sonuçları bir log dosyasına yazdırabilir veya kritik hatalar için mail gönderecek şekilde genişletebilirsiniz.
Yaygın Sorunlar ve Çözümleri
Yıllarca Exchange ortamlarında çalışırken tekrar tekrar karşılaştığım birkaç tipik sorun var:
MAPI bağlantı sorunları:
# MAPI bağlantı testi
Test-MapiConnectivity -Server "EXCHANGE01" |
Select-Object Server, Mailbox, Result, Error | Format-List
Posta kutusu veritabanı mount sorunu genellikle AD permission sorunuyla ilgilidir. Exchange Trusted Subsystem grubunun AD üzerindeki izinlerini kontrol edin.
Autodiscover çalışmıyor: SCP (Service Connection Point) kaydını kontrol edin:
# Autodiscover SCP kayitlarini kontrol et
Get-ClientAccessServer | Select-Object Name, AutoDiscoverServiceInternalUri
# SCP'yi guncelle
Set-ClientAccessServer -Identity "EXCHANGE01" `
-AutoDiscoverServiceInternalUri "https://mail.sirket.com/Autodiscover/Autodiscover.xml"
Kullanici attribute’lari GAL’e yansimıyor: Bu genellikle AD Connector veya OAB güncelleme sıklığıyla ilgilidir. Exchange Address List Service’i yeniden başlatmak çoğunlukla çözer.
Sonuç
Exchange ile Active Directory entegrasyonu, “bir kez kur unut” mantığıyla yönetilebilecek bir şey değil. Bu iki sistem birbirinin içine geçmiş durumda ve birindeki sorun anında diğerine yansıyor.
Pratik olarak şunu öneririm: Exchange ortamınızda periyodik olarak AD sağlık kontrolü yapın, replikasyon durumunu izleyin ve Exchange loglarını düzenli olarak inceleyin. Sorun çıkmadan önce görmek, çıktıktan sonra çözmekten her zaman daha az maliyetlidir.
Ayrıca Schema extension ve PrepareAD adımlarını asla aceleye getirmeyin. Bu adımlar geri alınamaz değişiklikler yaptığından, mutlaka test ortamında deneyin ve production’da zamanlamayla yapın. Kurumsal ortamlarda bu işlemler için Change Management süreci işletmek hem sizi hem de kurumunuzu korur.
Son olarak: RBAC’ı öğrenin ve kullanın. Kullanıcılara “Domain Admin” verip Exchange’i oradan yönetmek, hem güvenlik açığı hem de potansiyel felaket reçetesidir. Doğru yetkilendirme, uzun vadede hem güvenliği hem de yönetilebilirliği artırır.
