Classic ve Modern Exchange Hybrid Yapılarının Farkları

Bir kuruluşta tüm Mailbox'ları tek seferde Cloud'a taşımak nadiren mümkün olur. Çoğu zaman kullanıcıların bir kısmı On-Premises Exchange ortamında kalır, bir kısmı Exchange Online'a geçer ve iki ortamın aylarca, bazen yıllarca birlikte çalışması gerekir. Hybrid Deployment, On-Premises Exchange ile Exchange Online arasında bu birlikte çalışma modelini kurar. Free/Busy bilgisi iki taraf arasında karşılıklı görünür, Mail Flow iki platform arasında TLS ile korunarak yönlendirilir ve Mailbox Migration bir gecede bitirilmek zorunda kalmadan kademeli olarak yürütülür.

Hybrid yapılandırmasını Hybrid Configuration Wizard (HCW) uygular ve Wizard'ın sorduğu en belirleyici sorulardan biri topoloji seçimidir. Classic Hybrid Topology, Exchange Online'ın On-Premises Exchange servislerine Internet üzerinden doğrudan ulaştığı geleneksel yaklaşımdır. Modern Hybrid Topology ise Cloud'dan On-Premises'e gelen Free/Busy ve Migration isteklerini Hybrid Agent üzerinden taşır. İkisi de aynı Hybrid hedefine ulaşır; fark, Cloud tarafının On-Premises Exchange'e hangi yoldan eriştiği ve bu tercihin hangi özellikleri kapsam dışında bıraktığıdır.

Aşağıda iki topolojinin Full seçeneklerini, yani Classic Full ve Modern Full yapılarını inceliyorum. Önce ikisi için de geçerli ön koşullara, ardından her topolojinin iletişim mantığına ve sınırlarına, son olarak da 2025 ve 2026'da Hybrid tarafında yapılan değişikliklere ve topoloji karşılaştırmasına geçiyorum.

1- Hybrid Deployment İçin Ortak Ön Koşullar

Topoloji seçiminden önce, iki modelde de değişmeyen gereksinimleri netleştirmek gerekir. HCW bu koşullar sağlanmadan tamamlanamaz.

2- Classic Hybrid Topology (Classic Full)

Classic Hybrid Topology'de Exchange Online, ihtiyaç duyduğu On-Premises servislerine Internet üzerinden doğrudan bağlanır. HTTPS tarafında Autodiscover ve EWS, SMTP tarafında ise TCP/25 dışarıdan erişilebilir olmalıdır. OWA, ECP veya MAPI gibi istemci protokollerinin Hybrid için yayınlanması gerekmez; bunlar ayrı bir karardır.

HCW çalıştırıldığında yapılandırma iki tarafa birden yazılır. On-Premises tarafta Send ve Receive Connector'lar, Federation Trust, Organization Relationship ve OAuth bileşenleri; Exchange Online tarafında ise Inbound ve Outbound Connector'lar, Organization Relationship, IntraOrganizationConnector ve Migration Endpoint oluşturulur. Yani Hybrid davranışı tek bir tarafta değil, iki ortamdaki nesnelerin birlikte çalışmasıyla belirlenir.

İletişim Akışı

Exchange Online, Mailbox'ı Cloud'da olan bir kullanıcının gündelik işlemleri için On-Premises Exchange'e bağlanmaz. Bağlantı ihtiyacı üç durumda doğar. Cloud kullanıcısı On-Premises'teki bir kullanıcının Free/Busy bilgisini sorguladığında, MailTips gibi Cross-Premises özellikler çalıştığında ve bir Mailbox Migration başlatıldığında.

Free/Busy sorgusunda Exchange Online önce hedef EWS adresini bulmak zorundadır. Organization Relationship üzerinde TargetSharingEpr değeri tanımlı değilse bu adresi Autodiscover ile keşfeder, ardından EWS'ye bağlanır. Classic modelde Autodiscover'ın dışarıdan erişilebilir olmasının nedeni budur.

Cloud -> On-Premises (Free/Busy, MailTips, Migration)

Exchange Online
      |
      |  HTTPS / TCP 443 (Inbound)
      v
Firewall / Reverse Proxy / Load Balancer
      |
      v
On-Premises Exchange (Autodiscover, EWS, MRSProxy)


On-Premises -> Cloud (Free/Busy, MailTips)

On-Premises Exchange
      |
      |  HTTPS / TCP 443 (Outbound)
      v
Exchange Online


Mail Flow (iki yön)

Exchange Online  <-- SMTP / TCP 25 + TLS -->  On-Premises Exchange veya Edge Transport

Exchange Online'ın bağlandığı On-Premises adresleri aşağıdaki gibidir.

Yayınlama ve Yönetim Sorumlulukları

Classic modelde yayınlama katmanının tamamı kurumun sorumluluğundadır. HCW Exchange yapılandırmasını yapar, ancak aşağıdaki bileşenleri kurum tasarlar ve işletir.

» Public sertifikanın alınması, yenilenmesi ve Exchange servislerine atanması.
» Autodiscover ve EWS'nin Reverse Proxy, Load Balancer veya Firewall üzerinden yayınlanması.
» Public DNS ve NAT kayıtları.
» TCP/25 için Inbound ve Outbound Firewall kuralları.

Bunun karşılığında trafik uçtan uca kurumun kendi cihazlarından geçer. IIS Log'ları, Reverse Proxy kayıtları ve Firewall oturumları üzerinden bir isteğin nerede kesildiğini izlemek mümkündür. Yayın yalnızca Hybrid amacıyla yapılıyorsa Inbound trafiği Microsoft 365 IP aralıklarıyla sınırlamak saldırı yüzeyini belirgin biçimde daraltır.

Mailbox Migration ve MRSProxy

Hybrid Migration'da taşıma işlemini Exchange Online'daki Mailbox Replication Service başlatır ve On-Premises tarafta MRSProxy'ye bağlanır. MRSProxy ayrı bir servis değildir; EWS Virtual Directory altında çalışan /EWS/mrsproxy.svc yoludur. Dolayısıyla EWS yayını çalışıyorsa Migration için ek bir adres yayınlamak gerekmez, MRSProxy'nin etkin olması yeterlidir.

HCW bu ayarı kendisi de açabilir. Yine de IIS Cache'in temizlenmesine zaman tanımak için HCW'den önce etkinleştirmek daha sağlıklı sonuç verir. Komut Exchange Management Shell'de çalışır.

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

Classic modelde birden fazla Migration Endpoint tanımlanabilir ve her biri farklı bir URL'yi gösterebilir. Büyük ortamlarda Migration yükünü farklı sunuculara veya lokasyonlara dağıtmak için bu esneklikten yararlanılır.

Hybrid Modern Authentication (HMA)

HMA, On-Premises Mailbox'lara erişen Outlook istemcilerinin Microsoft Entra ID'den aldığı Token ile kimlik doğrulamasını sağlar. Böylece On-Premises Mailbox'lar için de MFA ve Conditional Access uygulanabilir.

HMA'nın çalışması için istemcilerin Internet üzerinden Autodiscover, EWS, ActiveSync, MAPI ve OAB Endpoint'lerine ulaşabilmesi gerekir. Bu nedenle HMA yalnızca Classic topolojide desteklenir. HCW Full, HMA için gereken altyapıyı hazırlar ancak HMA'yı etkinleştirmez; etkinleştirme ayrı adımlarla yapılır.

Teams Calendar Entegrasyonu

Mailbox'ı On-Premises'te olan bir kullanıcının Teams içinde toplantı oluşturup görüntüleyebilmesi için Teams servisinin On-Premises Exchange'e ulaşması gerekir. Microsoft Learn bu senaryo için şu koşulları sayar.

» Mailbox, Exchange Server 2016 CU3 veya daha yeni bir sürümde barınmalıdır.
» Autodiscover ve EWS dışarıya yayınlanmış olmalıdır.
» OAuth yapılandırılmış olmalıdır. Tercih edilen yöntem HCW'nin Full seçeneğidir.
» Kullanıcı Microsoft Entra ID'ye senkronize edilmiş ve Teams lisansı atanmış olmalıdır.
» Microsoft Entra Connect'te Exchange Hybrid Deployment seçeneği işaretli olmalıdır.

Burada gereken OAuth'tur, HMA değil. İkisi sık karıştırılıyor: OAuth, Teams ve Exchange Online gibi servislerin On-Premises Exchange'e Token ile bağlanmasını sağlar; HMA ise kullanıcı istemcilerinin kimlik doğrulamasıyla ilgilidir. Teams Calendar için HMA'nın etkin olması şart değildir.

Microsoft, On-Premises entegrasyonu için Exchange Server 2016 veya üzeriyle Classic Full Hybrid'i önerir. Gerekçe basittir: Teams'in ihtiyaç duyduğu Autodiscover ve EWS yayını Classic modelde zaten vardır.

Kimin İçin Uygun?

Classic Full, Hybrid yapıyı uzun süre işletecek ve On-Premises Mailbox barındırmaya devam edecek kurumlar için doğru tercihtir. HMA, Cross-Premises Message Tracking veya Multi-Mailbox Search kullanılacaksa Classic bir tercih olmaktan çıkar, zorunluluk haline gelir. Teams Calendar için de Microsoft'un önerdiği topoloji budur.

3- Modern Hybrid Topology (Modern Full)

Modern Hybrid Topology, Cloud'dan On-Premises'e gelen Free/Busy ve Migration isteklerini Internet'e açık bir Endpoint yerine Hybrid Agent üzerinden taşır. Hybrid Agent, Microsoft Entra Application Proxy ile aynı teknoloji üzerine kuruludur. Agent, Microsoft tarafındaki Proxy altyapısına Outbound HTTPS bağlantısı açar ve Exchange Online'dan gelen istekler bu bağlantı üzerinden iç ağdaki Exchange Server'a iletilir.

Bu sayede Free/Busy ve Migration için EWS'yi dışarıya yayınlamak, bu amaçla External DNS kaydı açmak, sertifika güncellemek ve Firewall'da Inbound kural tanımlamak gerekmez. Kurulum Classic'e göre daha hızlıdır.

Sadeliğin bir bedeli var. Agent yalnızca belirli trafik türlerini taşır ve taşımadığı her şey için ya Classic gereksinimleri geçerli kalır ya da özellik hiç kullanılamaz. Modern Hybrid'i doğru senaryoda kullanmak, bu sınırları kurulumdan önce bilmeye bağlıdır.

Nasıl Çalışır?

Topoloji seçimi HCW'nin Hybrid Topology sayfasında yapılır. Aşağıdaki görselde Classic ve Modern seçenekleri, Wizard'ın her biri için verdiği kısa açıklamayla birlikte görünüyor.



Bu sayfada Use Exchange Modern Hybrid Topology seçilip ilerlendiğinde Wizard Agent kurulum paketini indirir, Agent'ı bilgisayara kurar, Agent'ı Microsoft Entra ID'ye kaydeder ve Exchange Online'dan On-Premises'e Migration yapılabildiğini test eder. Bu süreç 10 dakikaya kadar sürebilir.

Kayıt sırasında Tenant'a özel bir URL oluşturulur: [GUID].resource.mailboxmigration.his.msappproxy.net

HCW, Exchange Online'daki Migration Endpoint'i bu adrese yönlendirir. Aynı adresi Organization Relationship ve IntraOrganizationConnector üzerindeki TargetSharingEpr değerine de yazar. Böylece Exchange Online, Free/Busy için Autodiscover ile adres keşfetmeye çalışmaz; doğrudan bu URL'ye gider.

Cloud -> On-Premises (Free/Busy, Migration)

Exchange Online
      |
      v
[GUID].resource.mailboxmigration.his.msappproxy.net
      ^
      |  HTTPS / TCP 443 (Outbound, bağlantıyı Agent başlatır)
      |
Hybrid Agent
      |
      |  HTTPS / TCP 443 (iç ağ)
      v
On-Premises Exchange (EWS, MRSProxy)


On-Premises -> Cloud (Free/Busy)

On-Premises Exchange  -- HTTPS / TCP 443 (Outbound) -->  Exchange Online
(Agent kullanılmaz)


Mail Flow (iki yön)

Exchange Online  <-- SMTP / TCP 25 + TLS -->  On-Premises Exchange veya Edge Transport
(Agent kullanılmaz)

Diyagramdaki asimetri önemlidir. Agent yalnızca Cloud'dan On-Premises'e gelen istekleri taşır. On-Premises kullanıcısının bir Cloud kullanıcısının Free/Busy bilgisini sorgulaması Agent'tan geçmez; bu istek Exchange sunucusundan doğrudan Exchange Online'a gider.

Oluşan değerleri Exchange Online PowerShell oturumunda aşağıdaki komutlarla görüyorum.

Get-MigrationEndpoint | Format-List Identity,RemoteServer
Get-OrganizationRelationship | Format-List Name,TargetSharingEpr

Hybrid Agent Gereksinimleri

Hybrid Agent iki farklı konuma kurulabilir. Birincisi doğrudan bir Exchange sunucusudur: Exchange Server 2016 ve sonrasında Mailbox rolü, Exchange Server 2013'te Client Access rolü. İkincisi, Agent için ayrılmış bağımsız bir Windows Server'dır. İki konum da desteklenir. HCW, Agent'ın kurulacağı bilgisayarda çalıştırılmalıdır.

Hangi konum seçilirse seçilsin bilgisayarın karşılaması gereken temel gereksinimler aynıdır.

HCW'nin Agent MSI paketini kendisinin indirip kurabilmesi için bunlara ek koşullar gerekir.

Kuruluma başlamadan önce bilgisayarın gerekli Endpoint'lere ulaşıp ulaşamadığını test etmek, HCW'nin yarıda kesilmesini önler. Microsoft'un HybridManagement.psm1 modülü bu testi yapar.

Import-Module .\HybridManagement.psm1
Test-HybridConnectivity -TestO365Endpoints

Ortamda Outbound Proxy varsa Agent kurulduktan sonra Proxy adresi ayrıca tanımlanır. Script, Agent'ın kurulduğu bilgisayarda \Program Files\Microsoft Hybrid Service\ klasöründe bulunur.

.\ConfigureOutBoundProxy.ps1 -ProxyAddress http://proxyserver:8080

Exchange sunucusunun kendi Proxy ayarı da ayrıca önemlidir. HCW, Federation Trust için Exchange sunucusundan dışarıya bağlantı kurar ve On-Premises'ten Cloud'a Free/Busy istekleri de yine sunucudan çıkar. Sunucudaki InternetWebProxy değeri yanlışsa bu iki işlem başarısız olur.

Dış Yayınlama Gereksinimleri

Modern Full'da yayınlama yükü azalır ama sıfırlanmaz. Hangi gereksinimin kalktığını, hangisinin kaldığını ayrı ayrı görmek gerekir.

Hybrid Agent'ın Kapsam Dışında Bıraktığı İşlevler

Aşağıdaki kısıtların tamamı Microsoft Learn'de belgelenmiştir. Kurum ihtiyaçlarından biri bu listeye giriyorsa Modern Hybrid uygun topoloji değildir.

1. SMTP Mail Flow

SMTP trafiği Hybrid Agent'ın kapsamı dışındadır. Exchange Online ile On-Premises arasındaki Mail Flow için Public sertifika ve TCP/25 erişimi gerekir. "Modern Hybrid kullanırsam Internet'e hiçbir şey açmam" varsayımı Full seçeneğinde geçerli değildir.

2. Hybrid Modern Authentication (HMA)

HMA, Hybrid Agent ile desteklenmez. Outlook istemcilerinin Autodiscover, EWS, ActiveSync, MAPI ve OAB Endpoint'lerine Internet üzerinden ulaşması gerekir ve bu ancak Classic topolojide yapılan yayınla sağlanır. On-Premises Mailbox'lar için MFA veya Conditional Access hedefleniyorsa topoloji Classic olmalıdır.

3. Cross-Premises Message Tracking ve Multi-Mailbox Search

Bu iki özellik Agent üzerinden geçmez. İkisi de EWS ve Autodiscover'ın dışarıya yayınlandığı ve Exchange Online tarafından erişilebildiği Classic bağlantı modeline ihtiyaç duyar. Cross-Premises MailTips ise bu kısıtın dışındadır ve Modern Full'da desteklenir.

4. Teams Calendar (On-Premises Mailbox)

Microsoft Learn'e göre Modern Hybrid desteği Free/Busy ile sınırlıdır ve Teams'ten On-Premises Mailbox'lara takvim entegrasyonu sağlamaz. Nedeni HMA eksikliği değildir; Teams servisinin ihtiyaç duyduğu Autodiscover ve EWS yayını bu modelde bulunmaz. Mailbox'ı Exchange Online'da olan kullanıcılar bu kısıttan etkilenmez.

5. Birden Fazla Migration Endpoint ve Exchange Organizasyonu

Hybrid Agent, servis varsayılan limitleriyle tek bir Migration Endpoint destekler. Özel URL'lerle birden fazla Migration Endpoint tanımlanamaz. Aynı şekilde tek bir Exchange organizasyonu desteklenir; birden fazla Exchange organizasyonunun aynı Tenant'a bağlandığı yapılarda Modern Hybrid kullanılamaz.

6. Sovereign Cloud Ortamları

Modern Hybrid; GCC, GCC High ve Gallatin (21Vianet tarafından işletilen Microsoft 365) ortamlarında desteklenmez. Bu ortamlarda Hybrid yapılandırması Classic topolojiyle yapılır.

7. OWA ve ECP'nin Application Proxy ile Yayınlanması

OWA ve ECP'nin Microsoft Entra Application Proxy üzerinden yayınlanması desteklenmez. Bu, Modern Hybrid kullanan bir kurumun OWA yayınlayamayacağı anlamına gelmez. OWA ve ECP, Classic'te olduğu gibi Reverse Proxy veya Load Balancer ile yayınlanabilir; desteklenmeyen şey yayının Application Proxy üzerinden yapılmasıdır.

Extended Protection ve Hybrid Agent

Windows Extended Protection, Hybrid Agent ile yayınlanan Exchange sunucularında Front-End EWS Virtual Directory üzerinde etkinleştirilmemelidir. Agent araya giren bir Proxy olduğu için Channel Binding kontrolü başarısız olur ve Free/Busy ile Migration durur.

Asıl risk CU yükseltmelerindedir. Exchange Server 2019 CU14 ve sonraki Setup sürümleri Extended Protection'ı varsayılan olarak etkinleştirir. Hybrid Agent ile yayınlanan bir sunucu standart şekilde yükseltilirse EWS üzerinde Extended Protection açılır ve Hybrid özellikleri kırılır. Bu sunucularda Setup aşağıdaki parametreyle çalıştırılmalıdır.

Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS

Extended Protection'ı Script ile yapılandırırken de aynı istisna uygulanır. Komuttaki sunucu adları, Agent ile yayınlanan Exchange sunucularıdır.

.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"

EWS üzerinde Extended Protection kapalı kaldığı için Microsoft iki ek önlem önerir. Agent ile yayınlanan Exchange sunucularına gelen bağlantılar Firewall'da yalnızca Agent'ın kurulu olduğu bilgisayara izin verecek şekilde kısıtlanmalı ve bu sunucularda Mailbox barındırılmamalıdır. Bu öneri, Agent'ın Exchange dışında ve farklı bir ağ segmentinde çalıştığı senaryo için verilmiştir.

Yüksek Erişilebilirlik ve Agent Yönetimi

Modern Hybrid'de iki ayrı tek hata noktası vardır ve ikisi farklı yöntemlerle giderilir.

Birincisi Agent'ın kendisidir. Yedeklilik için birden fazla Agent kurulabilir. HCW ikinci bir bilgisayarda çalıştırılıp Modern Hybrid seçildiğinde mevcut Agent'ların durumunu gösteren sayfada Install an additional agent seçeneği çıkar. Alternatif olarak MSHybridService.msi paketi elle indirilip kurulabilir. Kurulumdan sonra Windows Services konsolunda Microsoft Hybrid Service (mshybridsvc) servisinin çalıştığı görülür.

İkincisi hedef Exchange sunucusudur. Agent, HCW'de seçilen sunucunun Internal FQDN değerini Proxy altyapısına kaydeder. O sunucu Offline olursa kaç Agent kurulu olursa olsun Cloud'dan On-Premises'e Free/Busy ve Migration çalışmaz. Sunucu kalıcı olarak devre dışı kaldıysa HCW yeniden çalıştırılıp yeni bir sunucu kaydedilmelidir.

Bu bağımlılığı kaldırmanın yolu, hedefi tek bir sunucu yerine Load Balancer adresine çevirmektir. Önce modülü içe aktarıp Agent'ların durumuna bakıyorum.

Import-Module .\HybridManagement.psm1
Get-HybridAgent -UserPrincipalName admin@contoso.onmicrosoft.com

Ardından hedef adresi değiştiriyorum. Buradaki appId değeri Agent kimliği değildir; Migration Endpoint'teki URL'nin başında yer alan Tenant'a özel GUID'dir.

Update-HybridApplication -TargetUri "https://mail.contoso.com" -AppId 123e4567-e89b-12d3-a456-426614174000 -UserPrincipalName admin@contoso.onmicrosoft.com

Doğrulama için Exchange Online PowerShell'de Migration testini çalıştırıyorum. Komut On-Premises kimlik bilgilerini ister.

Test-MigrationServerAvailability -ExchangeRemoteMove:$true -RemoteServer '123e4567-e89b-12d3-a456-426614174000.resource.mailboxmigration.his.msappproxy.net' -Credentials (Get-Credential)

Test başarılı olduğunda Agent'ın kurulu olduğu bilgisayarda Performance Monitor'de Microsoft AD App Proxy Connector nesnesinin # requests sayacının arttığı görülür. Test Load Balancer adresiyle başarısız oluyorsa Microsoft, hedefi geçici olarak tek bir Exchange sunucusuna çevirip yeniden denemeyi önerir.

Agent yönetimi için modülde Get-HybridAgent, Get-HybridApplication, New-HybridApplication, Update-HybridApplication ve Remove-HybridApplication Cmdlet'leri bulunur. Bunların dışında ince ayar yapılabilecek bir alan yoktur; port, yönlendirme ve Proxy altyapısı Microsoft tarafından yönetilir.

Nerede Tercih Edilir?

Modern Hybrid, amacı Mailbox'ları Exchange Online'a taşımak olan ve taşıma süresince Free/Busy ile MailTips dışında bir Cross-Premises özelliğe ihtiyaç duymayan kurumlara uygundur. EWS'yi Internet'e yayınlamak istemeyen ya da yayınlama altyapısı bulunmayan yapılarda Migration'ı hızlıca başlatmanın en kısa yoludur.

On-Premises Mailbox'ların uzun süre kalacağı, Teams kullanan veya HMA hedefleyen bir ortamda ise aynı sadelik kısa sürede engele dönüşür.

4- Dedicated Exchange Hybrid App ve EWS Değişiklikleri

Topoloji hangisi olursa olsun, 2025'ten itibaren Hybrid yapıların tamamını etkileyen bir değişiklik var. Eskiden Exchange Server, Exchange Online ile OAuth iletişimi için Microsoft'a ait paylaşımlı bir Service Principal kullanıyordu ve HCW, Auth Certificate'i bu paylaşımlı nesneye yüklüyordu. Microsoft bu modeli bırakıp her Tenant'ta ayrı oluşturulan Dedicated Exchange Hybrid App modeline geçti.

Değişiklik, On-Premises sunuculardan Exchange Online'a yapılan Hybrid çağrılarını etkiler. Mailbox Migration bu değişiklikten etkilenmez. Microsoft'un açıklamasına göre uygulama hem Classic hem de Modern Hybrid için geçerlidir ve Tenant başına bir kez yapılandırılır.

Desteklenen Sürümler

Bu Build'lerin altındaki sunucular, Exchange Server 2013 dahil, Dedicated App'i kullanamaz ve dolayısıyla Cloud yönündeki Free/Busy, MailTips ve profil fotoğrafı özelliklerinden yararlanamaz.

Yapılandırma

Ön koşul, Classic Full veya Modern Full Hybrid'in HCW ile kurulmuş olmasıdır. Microsoft'un önerdiği yöntem ConfigureExchangeHybridApplication.ps1 Script'ini All-in-one modunda çalıştırmaktır. Script uygulamayı Microsoft Entra ID'de oluşturur, Auth Certificate'i yükler, Auth Server nesnesini günceller ve özelliği etkinleştirir. Uygulamayı oluşturmak için en az Application Administrator, Exchange tarafı için Organization Management yetkisi gerekir.

.\ConfigureExchangeHybridApplication.ps1 -FullyConfigureExchangeHybridApplication

HCW'nin güncel sürümü de uygulamayı oluşturabilir, ancak özelliği kendisi etkinleştirmez. Uygulama HCW ile oluşturulduysa aşağıdaki komutlar Exchange Management Shell'de ayrıca çalıştırılmalıdır.

New-SettingOverride -Name "EnableExchangeHybrid3PAppFeature" -Component "Global" -Section "ExchangeOnpremAsThirdPartyAppId" -Parameters @("Enabled=true") -Reason "Enable dedicated Exchange hybrid app feature"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

Yapılandırmanın çalıştığını OAuth testiyle doğruluyorum. Sonuçta ResultType değeri Success olmalı ve Detail alanında Dedicated App'in appId değeri görünmelidir.

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com -Mailbox user@contoso.com | Format-List ResultType,Detail

Geçişten sonra paylaşımlı Service Principal üzerinde kalan eski sertifikaların temizlenmesi de önerilir. Bu adım CVE-2025-53786 için belirtilen önlemin parçasıdır ve Global Administrator yetkisi ister.

.\ConfigureExchangeHybridApplication.ps1 -ResetFirstPartyServicePrincipalKeyCredentials

EWS'nin Kullanımdan Kalkması ve Graph API

Dedicated App varsayılan olarak EWS izniyle oluşturulur. Microsoft'un duyurduğu takvime göre Exchange Online'da EWS'nin kullanımdan kaldırılması Ekim 2026'da başlıyor. Bu nedenle Exchange Server SE, May 2026 HU ile birlikte Hybrid çağrılarını Graph API üzerinden yapabilir hale geldi.

Graph API tabanlı akış şu an Free/Busy ve profil fotoğraflarını tam, MailTips'i ise yalnızca Automatic Replies için destekler. Cloud'daki Archive Mailbox'a taşıma gibi senaryolar EWS'ye bağlı kalmaya devam eder. Akış bugün yalnızca Microsoft 365 Global ortamında kullanılabilir; desteklenmeyen bir Cloud ortamında etkinleştirilirse Hybrid özellikleri durur.

Free/Busy için OAuth yerine Federation Trust ve Organization Relationship'e dayanan DAuth kullanan ortamlar ayrıca dikkat etmelidir. Microsoft, EWS kullanımdan kalktığında DAuth'un Exchange Online ile çalışmayacağını belirtiyor ve OAuth'a geçişi öneriyor. HMA ise bu değişiklikten etkilenmez; paylaşımlı Service Principal'ı kullanmaya devam eder.

5- Classic Full ve Modern Full Arasındaki Farklar

İki topolojinin ayrıştığı yer, Exchange Online'ın On-Premises Exchange'e nasıl ulaştığıdır. Classic'te bağlantı yayınlanmış adreslere doğrudan yapılır. Modern'de Free/Busy ve Migration istekleri Agent'ın açtığı bağlantıdan iç Network ortamındaki Exchange'e iletilir. Bu tek fark; yayınlama gereksinimlerini, desteklenen özellikleri ve işletme modelini birlikte değiştirir. Aşağıdaki tablolar farkları konu bazında özetliyor.

Port ve Yayınlama Gereksinimleri

Migration ve Free/Busy

Kimlik Doğrulama ve İstemci Entegrasyonu

Cross-Premises Özellikler ve Platform Kısıtları

Güvenlik, Yönetim ve Uygun Senaryolar

Agent sunucusuyla ilgili bir notum var. Microsoft dokümantasyonu bu sunucu için belirli bir güvenlik katmanı tanımlamıyor. Ben Agent sunucusunu, Tenant'a kayıtlı olduğu ve Exchange'e doğrudan eriştiği için Microsoft Entra Connect sunucusuyla aynı hassasiyette ele alıyor, erişimi ve yönetici hesaplarını buna göre kısıtlıyorum.

6- Topolojiler Arası Geçiş

Topoloji seçimi geri alınamaz bir karar değildir, ancak iki yönün maliyeti farklıdır.

Modern'den Classic'e: HCW, Agent'ın kurulduğu bilgisayarda yeniden çalıştırılır ve Classic Connectivity seçilir. Bu seçim Agent'ı bilgisayardan kaldırır ve Microsoft Entra ID'deki kaydını siler. Ardından Wizard Classic yapılandırmasıyla devam eder. Geçişten önce Autodiscover ve EWS yayınının, sertifikanın ve DNS kayıtlarının hazır olması gerekir.

Classic'ten Modern'e: Exchange Online'daki mevcut Migration Batch'ler ve Migration Endpoint silinir, HCW yeniden çalıştırılıp Modern Hybrid seçilir. Microsoft bu geçişi yalnızca Classic kurulum tamamlandığı halde Mailbox Migration yapılamıyorsa önerir; çünkü Classic'te çalışan bazı Hybrid özellikleri Agent ile desteklenmez.

İki topolojiyi yan yana koyduğumda karar çoğu zaman tek bir soruya iniyor: On-Premises'te Mailbox kalacak mı? Kalacaksa HMA, Teams Calendar ve Cross-Premises arama ihtiyaçları er ya da geç gündeme geliyor ve bunların hepsi Classic Full gerektiriyor. Amaç Mailbox'ları taşıyıp On-Premises Exchange'i yalnızca yönetim için tutmaksa Modern Full, EWS'yi yayınlamadan Migration'ı başlatmanın en kısa yolu oluyor. Hangisi seçilirse seçilsin Mail Flow için TCP/25 ve Public sertifika, Hybrid özellikleri için de Dedicated Exchange Hybrid App gereksinimi değişmiyor.

Faydalı olması dileğiyle...