Exchange Server’da Hybrid Yapılandırma: On-Premises ve Cloud Entegrasyonu

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

Yıllar önce bir müşterimizin “biz buluta geçiyoruz ama on-prem’i de tutacağız” dediğinde içimden “bu iş kolay olmayacak” diye geçirmişimdir. Haklıydım. Exchange Hybrid yapılandırması, Microsoft’un en karmaşık ürünlerinden birini en karmaşık geçiş senaryosuna sokmak demek. Ama doğru yapılandırıldığında inanılmaz güçlü bir altyapı sunuyor. Bu yazıda, teoriden çok sahada öğrendiğim şeyleri paylaşacağım.

Hybrid Yapılandırma Neden Gerekli?

Tamamen Office 365’e geçmek istiyorsanız ama bir gecede tüm kullanıcıları taşıyamıyorsanız, hybrid tam size göre. Ya da bazı kullanıcıların posta kutularını yasal gereklilikler nedeniyle on-prem tutmak zorunda kalıyorsanız, ya da internet bağlantısı olmadan da mail akışının çalışmasını istiyorsanız, hybrid kaçınılmaz oluyor.

Asıl güzelliği şu: kullanıcılar hangi tarafta olursa olsun, birbirlerine sanki aynı sistemdeymiş gibi mail atabiliyorlar, takvim paylaşabiliyorlar, oda rezervasyonu yapabiliyorlar. Buna “shared namespace” deniyor ve bu olmadan hybrid’in pek bir anlamı kalmıyor.

Ama şunu da söyleyeyim: hybrid yapı, iki ayrı sistemi aynı anda yönetmek anlamına geliyor. İki kat iş, iki kat sorun giderme, iki kat dikkat gerektiriyor.

Ön Gereksinimler ve Ortam Hazırlığı

Başlamadan önce kontrol etmeniz gereken bir liste var. Bu listeyi atladığınızda, kurulumun ortasında rezil duruma düşme ihtimaliniz çok yüksek.

Exchange Versiyonu Kontrolü

Microsoft, hybrid için belirli Exchange versiyonlarını destekliyor. En az Exchange 2013 CU12 veya Exchange 2016 olması gerekiyor. Exchange 2019 ise en sorunsuz çalışan versiyon. Bunu kontrol etmek için:

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

Eğer “Microsoft Exchange Server 2013 (Build 15.0.1497)” gibi bir şey görüyorsanız, CU seviyenizi de kontrol edin. Eksik CU’larla hybrid çalışmaz, ya da çalışır ama beklenmedik şekillerde patlar.

SSL Sertifika Durumu

Hybrid için geçerli, güvenilir bir CA’dan alınmış SSL sertifikası zorunlu. Self-signed sertifika kesinlikle kabul görmüyor. Ayrıca sertifikanın üzerinde şu subject alternative name’lerin bulunması lazım:

  • autodiscover.sirketiniz.com
  • mail.sirketiniz.com
  • webmail.sirketiniz.com (varsa)
Get-ExchangeCertificate | Select-Object Subject, NotAfter, Services, Thumbprint | Format-List

DNS Kayıtları

Autodiscover kaydınızın düzgün çalışıyor olması kritik. Bunu test etmek için:

Test-OutlookWebServicesConnectivity -ClientAccessServer EXCHANGE-SUNUCU -MailboxCredential (Get-Credential)

Eğer bu test başarısız oluyorsa, hybrid kurulumuna geçmeyin. Önce bu problemi çözün.

Azure AD Connect Kurulumu ve Senkronizasyon

Hybrid’in temeli Azure AD Connect. On-prem Active Directory’deki kullanıcıları Azure AD’ye senkronize eden bu araç olmadan hiçbir şey çalışmaz. Birçok yerde “şu linki indir, next next finish yap” diye anlatılıyor ama gerçek hayat o kadar basit değil.

Önce mevcut UPN suffix’lerinizi kontrol edin:

Get-ADForest | Select-Object -ExpandProperty UPNSuffixes

Eğer burada “sirket.local” gibi bir şey görüyorsanız, problem var demektir. Microsoft 365, “.local” gibi routable olmayan domain’leri kabul etmiyor. Bu durumda kullanıcıların UPN’lerini değiştirmeniz gerekiyor:

# Tüm kullanıcıların UPN'lerini güncellemek için
Get-ADUser -Filter {UserPrincipalName -like "*@sirket.local"} | ForEach-Object {
    $newUPN = $_.SamAccountName + "@sirketiniz.com"
    Set-ADUser $_ -UserPrincipalName $newUPN
    Write-Host "Updated: $($_.Name) -> $newUPN"
}

Bu scripti çalıştırmadan önce mutlaka test ortamında deneyin. Ve HR departmanı ile konuşun çünkü bazı sistemler kullanıcıları UPN ile tanımlıyor olabilir.

Azure AD Connect kurulduktan sonra ilk senkronizasyonu başlatmak için:

Start-ADSyncSyncCycle -PolicyType Initial

Senkronizasyon durumunu izlemek için:

Get-ADSyncScheduler

Hybrid Configuration Wizard ile Kurulum

İşte can alıcı nokta burası. Microsoft’un Hybrid Configuration Wizard (HCW) aracı hayatı kolaylaştırmak için tasarlanmış ama bazen sizi çıldırtabilir.

HCW’yi Exchange Admin Center üzerinden değil, doğrudan Microsoft’un sunucularından çalıştırın:

https://aka.ms/hybridwizard

Wizard başlarken Global Admin hesabınızı ve on-prem Exchange admin hesabınızı hazır bulundurun. İki set credential gerekiyor çünkü iki tarafta da değişiklik yapıyor.

Wizard’ın yaptığı başlıca işlemler:

  • Organization Configuration Transfer: On-prem organization ayarlarını EXO’ya aktarıyor
  • Connector Oluşturma: Inbound ve outbound mail flow connector’ları
  • OAuth Yapılandırması: İki sistem arasında güvenli iletişim için
  • Federation Trust: Free/Busy bilgisi paylaşımı için

Bir sorunla karşılaşırsanız, wizard’ın loglarını şu konumda bulabilirsiniz:

C:Users%USERNAME%AppDataRoamingMicrosoftExchange Hybrid Configuration

Bu log dosyalarını okumak başlangıçta zor gelebilir ama zamanla “ah, bu OAuth hatası, şu yüzden olmuş” diye anlayabiliyorsunuz.

Mail Flow Yapılandırması

Hybrid’de mail flow’u nasıl ayarlayacağınız, şirketinizin güvenlik politikalarına ve internet bağlantısı topolojisine göre değişiyor. İki temel senaryo var:

Centralized Mail Transport: Tüm mailler (Exchange Online’dan gelen de dahil) on-prem’den geçiyor. Bu yaklaşım, on-prem’deki DLP ve mail scanning çözümlerinizin cloud kullanıcıları için de çalışmasını sağlıyor. Büyük şirketlerde tercih edilen yöntem bu.

Decentralized Mail Transport: EXO kullanıcılarının mailleri doğrudan internet üzerinden gidiyor, on-prem’den geçmiyor. Daha basit ama kontrolü azaltıyor.

Centralized mail transport için on-prem connector’ını kontrol edelim:

Get-SendConnector | Where-Object {$_.AddressSpaces -like "*onmicrosoft.com*"} | Select-Object Name, AddressSpaces, SmartHosts

EXO tarafında inbound connector’ı kontrol etmek için Exchange Online PowerShell’e bağlanın:

Connect-ExchangeOnline -UserPrincipalName [email protected]

Get-InboundConnector | Select-Object Name, ConnectorType, SenderDomains, Enabled | Format-List

Eğer mail flow’da sorun yaşıyorsanız, test etmek için:

# EXO'dan on-prem'e test maili
Send-MailMessage -From "[email protected]" -To "[email protected]" -Subject "Hybrid Test" -Body "Test mesajı" -SmtpServer outlook.office365.com -Port 587 -UseSsl -Credential (Get-Credential)

Posta Kutusu Taşıma (Migration)

Kullanıcıları on-prem’den EXO’ya taşımak için MRS (Mailbox Replication Service) kullanıyoruz. Bu işlem arka planda çalışıyor ve kullanıcı neredeyse hiç kesinti yaşamıyor.

Önce MRS Proxy endpoint’inin etkin olduğunu kontrol edin:

Get-WebServicesVirtualDirectory | Select-Object Server, MRSProxyEnabled, InternalUrl, ExternalUrl

MRSProxyEnabled false ise:

Set-WebServicesVirtualDirectory -Identity "SUNUCUEWS (Default Web Site)" -MRSProxyEnabled $true

Şimdi migration batch oluşturalım. Ben genellikle test kullanıcılarıyla başlıyorum:

# Önce migration endpoint oluşturun (EXO PowerShell'de)
New-MigrationEndpoint -ExchangeRemoteMove -Name "OnPrem-Hybrid-Endpoint" -RemoteServer mail.sirketiniz.com -Credentials (Get-Credential)

# Migration batch oluşturun
New-MigrationBatch -Name "Pilot-Migration-Batch01" -SourceEndpoint "OnPrem-Hybrid-Endpoint" -CSVData ([System.IO.File]::ReadAllBytes("C:migrationpilot_users.csv")) -TargetDeliveryDomain "sirketiniz.mail.onmicrosoft.com" -AutoStart

CSV dosyası basit bir formatta olmalı:

EmailAddress
[email protected]
[email protected]
[email protected]

Migration durumunu izlemek için:

Get-MigrationBatch -Identity "Pilot-Migration-Batch01" | Select-Object Status, TotalCount, SyncedCount, FailedCount
Get-MigrationUser -BatchId "Pilot-Migration-Batch01" | Select-Object Identity, Status, PercentComplete, ItemsTransferred

Büyük posta kutularında bu işlem saatler sürebilir. Ben genellikle cuma akşamı başlatıp pazartesi sabahı kullanıcıları switchover ile tamamlıyorum. Switchover anında kullanıcı en fazla 15-20 dakika mail alamayabiliyor, bu süreyi minimumda tutmak için iyi bir zamanlama şart.

Free/Busy ve Takvim Paylaşımı

Hybrid’in en çok takdir gören özelliklerinden biri bu. On-prem kullanıcısı, EXO’daki bir kullanıcının takvimini görebiliyor, toplantı planlayabiliyor. Ama bu özellik OAuth doğru yapılandırılmazsa çalışmıyor.

OAuth durumunu test etmek için:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox "[email protected]" -Verbose | Format-List

Eğer bu test başarısız oluyorsa ve “The remote certificate is invalid” gibi hatalar alıyorsanız, muhtemelen on-prem EWS endpoint’inizin sertifika problemi var.

Free/Busy sorgusunu manuel test etmek için:

Get-AvailabilityConfig
Test-FreeBusyAccess -TargetAddress "[email protected]" -User "[email protected]"

Yaygın Sorunlar ve Çözümleri

Hybrid yapılandırmasında en sık karşılaştığım sorunları ve çözümlerini paylaşayım.

“550 5.7.64 TenantAttribution” Hatası

Bu hata, on-prem’den EXO’ya mail göndermeye çalışırken karşınıza çıkabilir. Genellikle send connector’ın TLS sertifika uyumsuzluğundan kaynaklanıyor.

# On-prem connector'ın TLS ayarlarını kontrol edin
Get-SendConnector -Identity "Outbound to Office 365" | Select-Object TlsAuthLevel, TlsDomain, RequireTLS

TlsAuthLevel’in “DomainValidation” olması ve TlsDomain’in “mail.protection.outlook.com” olması gerekiyor.

Autodiscover Çakışmaları

Hem on-prem hem EXO için autodiscover yapılandırması varsa çakışma yaşanabilir. Outlook hangi tarafa bağlanacağını bilemez. Bunu çözmek için on-prem’de şu ayarı yapın:

# On-prem kullanıcılar için autodiscover'ı on-prem'e yönlendir
Set-ClientAccessServer -Identity "EXCHANGE-SUNUCU" -AutoDiscoverServiceInternalUri https://autodiscover.sirketiniz.com/Autodiscover/Autodiscover.xml

EXO kullanıcıları için ise DNS’te autodiscover CNAME kaydını autodiscover.outlook.com’a yönlendirin. Bu şekilde taşınan kullanıcılar doğru yere gidecek.

Taşınan Kullanıcılar Hala On-Prem’e Bakıyor

Migration tamamlandıktan sonra bazı Outlook istemcileri hala on-prem’e bağlanmaya çalışabilir. Bu durumda kullanıcıdan Outlook profilini silip yeniden oluşturmasını isteyin. Ama bu da bazen yetmiyor. Outlook’un autodiscover cache’ini temizlemek gerekebilir:

# Outlook'un autodiscover cache'ini temizlemek için kullanıcı bilgisayarında çalıştırın
Remove-Item -Path "$env:LOCALAPPDATAMicrosoftOutlook*.xml" -Force

Ardından Outlook’u yeniden başlatın.

Monitoring ve Sürekli Bakım

Hybrid yapı kurulduktan sonra iş bitmiyor. Sürekli izlemeniz gereken şeyler var.

Connector sağlığını düzenli olarak kontrol etmek için bir PowerShell scripti oluşturmanızı öneririm:

# Hybrid sağlık kontrol scripti - zamanlanmış görev olarak çalıştırın
$report = @()

# Send connector durumu
$sendConnector = Get-SendConnector -Identity "Outbound to Office 365" -ErrorAction SilentlyContinue
if ($sendConnector.Enabled -eq $false) {
    $report += "KRITIK: Office 365 Send Connector devre disi!"
}

# SSL sertifika kontrolü
$cert = Get-ExchangeCertificate | Where-Object {$_.Services -like "*SMTP*"} | Sort-Object NotAfter | Select-Object -Last 1
$daysLeft = ($cert.NotAfter - (Get-Date)).Days
if ($daysLeft -lt 30) {
    $report += "UYARI: Exchange SSL sertifikasi $daysLeft gun icinde sona erecek!"
}

# AD Connect senkronizasyon kontrolü
$lastSync = (Get-ADSyncScheduler).LastSyncTime
$syncAge = (Get-Date) - $lastSync
if ($syncAge.TotalHours -gt 3) {
    $report += "UYARI: Azure AD Connect son $([math]::Round($syncAge.TotalHours)) saattir senkronize etmedi!"
}

if ($report.Count -gt 0) {
    $body = $report -join "`n"
    Send-MailMessage -From "[email protected]" -To "[email protected]" -Subject "Hybrid Exchange Uyari" -Body $body -SmtpServer localhost
} else {
    Write-Host "$(Get-Date): Hybrid saglik kontrolu tamam." -ForegroundColor Green
}

Bu scripti Windows Task Scheduler ile her saat çalıştırın. Uyku saatinizde bir şeyler patlasa bile sabah işe geldiğinizde ne olduğunu anlarsınız.

Güvenlik Konuları

Hybrid yapıda güvenliği ihmal etmek çok kolay. İki platform arasında güven ilişkisi kuruyorsunuz, bu ilişkiyi korumak önemli.

Modern Authentication

Eğer hala Basic Authentication kullanıyorsanız, hybrid bunu yapmak için iyi bir fırsat. Modern Auth’u etkinleştirmek için:

# On-prem Exchange'de modern auth ayarları
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

# OWA ve ECP için
Set-OwaVirtualDirectory -Identity "SUNUCUowa (Default Web Site)" -OAuthAuthentication $true
Set-EcpVirtualDirectory -Identity "SUNUCUecp (Default Web Site)" -OAuthAuthentication $true

Conditional Access Politikaları

EXO tarafında Conditional Access ile eski ve uyumsuz istemcilerin bağlantısını kesebilirsiniz. Bu on-prem kullanıcılarını etkilemez ama EXO kullanıcılarınız için ciddi güvenlik katmanı oluşturur.

Sonuç

Exchange Hybrid yapılandırması, sabır ve dikkat isteyen bir süreç. Wizard sizi çoğu yerde yönlendiriyor ama körü körüne tıklamak yerine her adımda ne yapıldığını anlamak kritik. Sorun çıktığında “wizard yaptı” demek sizi kurtarmıyor.

Şunu da belirtmek lazım: hybrid, kalıcı bir çözümden çok bir geçiş dönemi mimarisi. Microsoft’un uzun vadeli hedefi kullanıcıları tamamen EXO’ya taşımak ve bunu destekleyen araçlar giderek daha da olgunlaşıyor. Eğer yasal zorunluluklar veya teknik kısıtlamalar yoksa, hybrid’i mümkün olduğunca kısa süre içinde tamamlayıp tam bulut geçişini hedeflemek daha sürdürülebilir.

Ama bunu yaparken acele etmeyin. Her migration batch’i küçük tutun, test kullanıcılarıyla başlayın, VIP kullanıcıları en son taşıyın. Bir yönetim kurulu üyesinin maili iki saat gelmese hayatınız cehenneme dönebilir, bunu deneyimleyen olarak söylüyorum.

Son olarak: belgeleme yapın. Hybrid yapınızı kim kurdu, hangi kararlar neden alındı, özel connector ayarlarınız neler, bunları yazılı tutun. İki yıl sonra bir şey patladığında, o belgeye bakıp hayır duası alacaksınız.

Bir yanıt yazın

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