Exchange szakértői körökben sokat szoktunk azzal tréfálkozni, hogy a Transport az egyszerű, hiszen a nevében is ott van, hogy Simple (SMTP: simple mail transfer protocol). De, hogy ez mennyire nem igaz, azt talán az Exchange Server 2013 bizonyította be nekünk a legjobban. Ebben a rövid bejegyzésben az Exchange Server 2013 transport szolgáltatásának architektúráját fogom bemutatni a következő célzattal:

• misztikum eloszlatása azoknak akik már elkezdtek foglalkozni a témával
• misztifikáljuk azoknak akik még nem fogtak hozzá az ismerkedéshez, ezzel egyben pár kényelmetlenségtől megszabadítjuk

Bevezetés

Ha architektúrálisan nézzük, akkor a legnagyobb változás az Exchange Server 2013 esetében az, hogy a korábbi szerepkörökhöz képest lényegesen kevesebb, szám szerint két szerepkörünk van:

• Client Access Server (CAS)
• Mailbox Server (MBX)

A levéltovábbítás (transport) szempontjából ez jelentős változás. Korábban a levéltovábbításért az Exchange organizáción belül egy dedikált szerepkör a HUB-Transport felelt. (Egy lazán kapcsolt szerepkör az Edge amiről jelenleg nem fogok írni, az Exchange Server 2013 esetében –még- nincs Edge szerepkör.)

Az Exchange Server 2010 esetében a dedikált Hub-Transport szerepkör viszonylag egyszerű architektúrával működött. Volt egy Windows szolgáltatás, MSExchangeTransport, ami az MSExchangeTransport.exe futtatható kódot indította el. Az MSExchangeTransport feladata volt, hogy, hogy gondos gazda módjára a worker processt (dolgozó méheket) elindítsa és gondoskodjon arról, hogy a dolgozó jól érezze magát. Amolyan modern főnök, földesúr stb.

A dolgozó process az edgetransport.exe. Ezt a technika nyelvére lefordítva azt mondhatjuk, hogy a TCP-25 –s porton valójában az edgetransport.exe hallgat, ő fogadja a bejövő kapcsolatokat. Az MSExchangeTransport.exe csak elindítja, ha kell újraindítja, vagy újra beindítja a dolgozót.

Ezt viszonylag egyszerűen ellenőrizhetjük, ha lekérdezzük egy Exchange Server 2010-es kiszolgálón azt, hogy a TCP-25-s porton melyik szolgáltatás hallgat:

Ennél az egyszerű architektúránál jóval komplikáltabb az Exchange Server 2013.

Transport Exchange Server 2013 módra

A következő áttekintő ábrán azt láthatjuk, hogy szerepkörönként elosztva milyen Windows szolgáltatások futnak és azok milyen futtatható állományt indítanak (fent a szolgáltatás neve, lent a futtatott állomány neve):

Első ránézésre elég sokkoló a látvány, ki vitte el a régi egyszerű architektúrát? Azonban ha az egyes szolgáltatások funkcióját megértjük akkor kevésbé lesz rémisztő. Ezért vegyük sorra az egyes szolgáltatásokat:

• CAS szerepkör
• MSExchangeFrontEndTransport– ez az egyetlen Transport szolgáltatás ezen a szerepkörön. Feladata, hogy fogadja az SMTP kapcsolatokat, az SMTP kommunikációban az EOH (End of Header folyamatig), majd a küldő számára transzparens módon továbbítsa, proxyzza a kapcsolatot egy általa kiválasztott Mailbox kiszolgálónak. Ez a szolgáltatás nem tárol leveleket, egyszerűen csak a kapcsolatot továbbítja a Mailbox szerepkörnek. A szolgáltatás a
• MBX szerepkör
• MSExchangeTransport– a régi  Exchange 2010-es HUB-Transport szerepkörnél megismert szolgáltatás, azonos funkcióval. Elindítja a dolgozót, az EdgeTransport.exe-t. SMTP funkciót nem lát el, ez látható abból is, hogy nem tartozik hozzá TCP listener.
• EdgeTransport.exe– a dolgozó. Ez a komponens fogadja a bejövő SMTP kapcsolatokat. Látható hogy a TC P25, a TC P465 portokon hallgat, IPv4 és IPv6 címeken egyaránt. Két további high-range TCP porton is hallgat, azok nem a levéltovábbításhoz kapcsolódnak. Csak a TC P25 és a TCP 465 tartozik a levéltovábbításhoz.
• MSExchangeDelivery – az Exchange 2010 esetében a postaláda vagy nyílvános mappa adatbázisba történő kézbesítést egy store driver végezte, ami nem egy önálló processz volt, hanem az EdgeTransport.exe-ben volt (nagyon leegyszerűsítve). A store-ba történő kézbesítést az Exchange Server 2013 esetében az MSExchangeDelivery végzi. SMTP kapcsolatot a TCP 475-s porton keresztül fogad el, ahogy az a lenti képen is látható. További egy high-range TCP porton is hallgat a szolgáltatás aminek a levéltovábbítás szempontjából nincs szerepe.
• MSExchangeSubmission– amikor a felhasználó egy levelet elküld, akkor az Outbox (Póstázandó) mappájába helyezzük át. Az MSExchangeSubmission szolgáltatás a levelet az Outbox folderből kiveszi feldolgozza és továbbítja. Az MSExchangeSubmission szolgáltatás levelet soha nem fogad, csak küld

    Az egyes komponensek közti kapcsolatokat a következő áttekintő ábra mutatja:

A legfontosabb jellemzők:

• A CAS szervereken az MSExchangeFrontEndTransport.exe fogadja az SMTP kapcsolatokat a TCP25 vagy a TCP587-es portokon alapértelmezésben. Két SMTP receive connector van a CAS kiszolgálókon és ezek a receive connectorok határozzák meg, hogy valójában melyik portokon hallgat az MSExchangeFrontEndTransport.exe.
• A CAS szerver a bejövő SMTP levelet egy Mailbox szervernek továbbítja az End Of Header eseményt követően. Ez a továbbítás a Mailbox szerver EdgeTransport.exe-nek megy, vagy a TCP25, vagy a TCP465 portra. A CAS a TCP25-re vagy bármilyen általunk létrehozott receive-connectorra érkező kapcsolatokat a Mailbox szerver TCP25-re továbbít míg a TCP587-re érkező kapcsolatokat a TCP465-re továbbítja.
• Az EdgeTransport.exe nem végez közvetlen kézbesítést az adatbázisokba. A levelet a TCP475-s porton keresztül elküldi az MSExchangeDelivery.exe-nek ami RPC kapcsolaton keresztül elvégzi a levélkézbesítést az adatbázisba.
• Az MSExchangeSubmission.exe a levelet az EdgeTransport.exe-nek továbbítja TCP25-s porton keresztül.
• Az EdgeTransport.exe a levelet vagy
• egy másik SMTP kiszolgálónak küldi a TCP25-s portra
• a CAS kiszolgáló TCP717-es portjára, ha úgy van beállítva, hogy a CAS-on keresztül küldje a levelet (erről később még bővebben)

Egyéb kommunikáció a komponensek között nem történhet!

De miért jó ez?

Exchange Server 2010 esetében a HUB-Transport szerver fogadta a levelet és kézbesítette AD telephelyen belül a Store Driver segítségével az adatbázisba. Ez bizony RPC forgalom volt. Tételezzük fel, hogy van két kiszolgálónk, az egyik SMTP komponense fogadja a levelet, de a cél postaláda a másik kiszolgálón van. Ebben az esetben RPC kommunikáció megy a két kiszolgáló között. Amit nem szeretünk. Lassú, érzékeny a hálózati közegre stb.

Exchange Server 2013 esetében, hogy a Store kézbesítés egy önálló szolgáltatás lett (MSExchangeDelivery) és ahhoz tartozik egy önálló SMTP listener, azt jelenti, hogy az előző esetet feltételezve, a két kiszolgáló között SMTP kommunikáció lesz és nem közvetlenül a Store-t írjuk távolról. Ez egy fontos architektúrális lépés.

Következmények

Két fontos következménye van ennek az architektúrális módosításnak.

1, Az úgynevezett multi-role gépeken egy ellentmondásba ütközünk a fenti világképünk ismerete mellett. A multi-role szerver az, amire a CAS és az MBX szerepkör is telepítve van. Ebben az esetben a fenti világképet figyelembe véve, két szolgáltatás hallgatna a TCP25-s porton:

• A CAS szerepkör MSExchangeFrontEndTransport szolgáltatása
• Az MBX szerepkör EdgeTransport.exe komponense

Ez viszont nem fordulhat elő, legalábbis úgy nem, hogy annak jó vége legyen. Ezért ezekben az esetekben az EdgeTransport.exe automatikusan a TCP2525-s porton hallgat, míg a TCP25 az MSExchangeFrontEndTransport szolgáltatásé. Itt azonban nagyon figyelni kell. Ugyanis amikor egy új receive-connector-t hozunk létre powershell segítségével az alapértelmezésben a multirole gépeken a Mailbox szerepkörhöz hozza létre a connectort. Tehát, ha multi-role gépünk van és szeretnénk egy új TCP25-n hallgató connectort létrehozni powershell-ből, az a Mailbox szerepkörhöz fog létrejönni. Vagyis az EdgeTransport.exe szeretne a TCP25-s porton hallgatni, ami már foglalt. Ezekben az esetekben használjuk a new-receiveconnector TransportRole paraméterét, amivel a connector a FrontEndTransport (CAS) szerepkörön hozható létre:

Pontosan ugyanez érhető el azzal, ha az EAC segítségével hozunk létre egy receive connectort, és a Role (szerepkör) beállításnál kiválasztjuk a megfelelő szerepkört. Ennek a hatását ne felejtsük el, ha:

• HubTransport – akkor az EdgeTransport.exe, vagyis a Mailbox szerepkört konfiguráljuk
• Frontend Transport – akkor az MSExchangeFrontEndTransport szolgáltatást, vagyis a CAS szerepkört konfiguráltuk

2, A másik következmény az, hogy a Mailbox kiszolgálóról a levél két úton is kimehet:

• A Mailbox kiszolgáló jogosult elküldeni a levelet a célállomásnak, ami lehet egy másik Mailbox szerver, vagy lehet egy MX rekord alapján megtalált Interneten működő SMTP szerver, vagy egy Smart-Host
• Azonban a levelet küldheti a CAS kiszolgálón keresztül is. Ilyenkor a tényleges levélküldést a Mailbox kiszolgáló végzi, de úgy, hogy Layer4 nézetből nézve az valójában a CAS kiszolgálótól megy ki. Ilyenkor a Mailbox szerver a CAS kiszolgáló TCP717-es portjára küldi a forgalmat, a CAS pedig intelligens proxy módjára továbbítja az SMTP forgalmat a célkiszolgálónak. Ezt a funkciót a Send Connector beállításával szabályozhatjuk. A “proxy through client access server” funkció engedélyezésével a levél a korábban leírt módon jut el a célkiszolgálóhoz.

Zárszó

Talán ez a rövid összefoglaló sokadszori elolvasása után mindenkinek érthető lesz, hogy mi és miért változott és nem lesz ördögtől való a látvány amikor egy Exchange Server 2013-as kiszolgálón az alábbi gyárilag létrehozott receive connectorokat látja (a kép egy multirole kiszolgálón készült):

A játék indul, feltudod írni a fenti képen látható összes connector-hoz tartozóan:

• melyik szerepkörhöz tartozik? – ez elég egyszerű
• milyen porton hallgat?
• melyik Windows szolgáltatás vagy melyik futtatható állomány tartozik hozzá?