Scenario 1 – Incoming mail on multi-role server
Internet email is received on port 25 of Frontend transport service running on CAS server and then it proxies to the Transport component of mailbox server on port 2525, the transport component processes and routes it to the transport delivery on server(mailbox server) where the mailbox is active. Mailbox transport service then listens/receives email on port 475 and delivers email local active mailbox database.
Scenario 2 – Incoming mail on two multi-roles
Internet email is received to Hardware Load balancer/NLB on port 25 and at the backend which ever CAS server is available it receives email, further it delivers to the one of the CAS server’s frontend transport service on port 25 in this case meaning as per the slide it choose server2. Here we notice the recipients are two sitting individual on both the server, since CAS is nothing but stateless and proxies the request. It then passes the email to Transport service component of the mailbox server(server2) before it sends to the transport service(of mailbox server) it checks the recipient type if it is mailbox or mail enabled, if mailbox then its versions, no. of recipients, distribution group, so on and accordingly it routes to the best available transport service of any mailbox server(in this case it delivered on the server1 CAS/MBX server, it could have equally delivered to its local server1 also but it doesn’t matter at all, what CAS server looks is for the Transport service of the mailbox server locally or remotely which ever it finds and best available).
Transport service on Server1 is going to categorize the message and checks there are two recipients, located on two different mailbox server active databases, bifurcate that into 2 copies and submits that to the mailbox transport service on each mailbox server that is local to the active database copy for message delivery.
Mailbox transport service then does the content conversion and delivers the copy to the local active mailbox database via RPC.
Scenario 3 – Originating mail on two multi-roles
Let us know consider the same scenario like second instead of mail coming on premise we will see email going out of premises originating from mailbox server roles.
Message originating from server1 send email to 3 recipients (one on the same server1, second on the server2 and third on the internet)
User when tries to send an email the mailbox submission service submits the message to the mailbox transport service via RPC, once the transport service on mailbox server1 receives the message it will then choose any of the local or remote mailbox server transport service. In this scenario the message from Transport service of server1 connects to the transport service of server2, transport service on mailbox server2 categorizes and sees there are three recipients (2 internal and 1 external), bifurcates the recipients and delivers(one on server1 FE transport service, one on server1 mailbox transport service and local server mailbox transport service) the message accordingly. Then the mailbox transport service will deliver the message to the local active mailbox database copy via RPC and to the FE service on Server1(assuming that we configured on send connector with proxy enabled server1 for outgoing) for external delivery.
Scenario 4 – Incoming to DG on separated roles
Here we have now four sites having 1 CAS and 1 MBX server as separate role on each sites.
So now internet users wants to target this four recipients sitting on each site mailbox server sending email.
Having MX pointed to one of the sites and behind the CAS if there is load balancer it will deliver to one of the available CAS servers to that particular site. In this scenario let us choose the third CAS right corner of the slide.
Frontend transport receives that message, it checks there are multiple recipients having mailbox enabled which needs to be delivered, so it choose the local site available transport service as its best for that particular CAS server and delivers it to the transport service on the mailbox server to that local site. The transport service is then going to bifurcate that message, will create 4 copies and delivers that to the mailbox transport component (one locally and 3 to the remotel site mailbox server transport service). Then finally the mailbox transport service on each mailbox server delivers to the local mailbox database copy via RPC.
Scenario 5 – Incoming mail to legacy mailbox
So the fifth scenario is very much similar to the fourth but what change happens here is there comes the fifth site having Exchange 2010 HUB / MBX server.
Similarly as mentioned above the message coming from internets delivers the message to the CAS2013 on site 3 and the process is almost same until it delivers to the mailbox transport component of mailbox server site 3 and see what’s next further.
So now the transport service instead of creating 4 copies it will now create 5 copies, now the first four copies whose mailbox is on Exchange 2013 server it will deliver same as mentioned above in scenario 4 but for fifth copy its final delivery seems to be different from other than 4 copies (DAG delivery group) that is mailbox server delivery group (Exchange 2010 HUB server).
Since the mailbox transport doesn’t connects directly to the 2010 mailbox server hence it will route the message to the 2010 HUB server on the fifth site. Then the transport service of the Exchange 2010 HUB server will deliver the email to the final delivery that is the 2010 mailbox server.
6 – Client submission to single namespace
In this scenario the user Diana has her mailbox to be located at site A mailbox server1. She is a roaming user and travels often now not it happens to be in another site B for some work and wants to send email to the internet. Let’s see how it goes.
When Diana accesses here mailbox she connects to the local site CAS server(Site B) and tries to send email, the CAS server checks the mailbox location where it belongs and since it finds the users in mailbox server1 in site A, the front end transport service of CAS on site B directly connects to the transport service on site A mailbox server1. Since it has already authenticated at site B CAS server the transport service on mailbox server1 simply sends out the email as front end proxy to its local site A CAS server(as configured in send connector) frontend transport service and from their it goes out to the internet from site A.
7 – Client submission for legacy mailbox
Ok, now again similar scenario as sixth but instead of the mailbox version 2013 it is now Exchange 2010.
When Diana accesses her mailbox she would be connecting to site B 2013 CAS server, frontend transport service will authenticates and lookup for the location of the mailbox and its version. Since the CAS FE doesn’t directly talks to the mailbox server of Exchange 2010 MBX it will then connects to the Exchange 2013 mailbox server to its local site’s transport service.
The transport service on Exchange 2013 mailbox server on site B then categorizes the message and connects to the 2010 HUB server on site B based on the AD cost and then it will deliver the email to the mailbox on site A HUB to MBX 2010.
8 – Transport high availability
Exchange 2013 replaces shadow redundancy with new feature called Safety Net.
In Exchange 2010 when the message was sent from one HUB server to relay out to the next (first) hop the shadow queue was used to generate on the source (previous hop) server but in 2013 the shadow queue is created on the first hop right from the server where the mail is generated for guaranteed redundancy.
In 2013 now DAG is the transport boundary for high availability as compared to transport dumpster which was single point of failure meaning if the shadow queue on which mail.que was generated and in the event of lossy failover and Transport dumpster on which it is configured(HUB) failed too then you could not recover email.
So now when DAG is a HA boundary any message coming into DAG group now the message is queued not only in local site shadow queue but also remote site meaning in the event of local site failure you can resubmit the email at the time of failover or manually mounting the databases. Resubmit is also possible by doing manually using PowerShell command.
So that HA queue is nothing but called safety net which was introduced in 2010 exchange online and revealed it later with Exchange 2013 as new feature.
Safety Net retains data for a set of period of time (Time bases, default is 2days), regardless of whether the message has been successfully replicated to all database copies or delivered to final destination.
FYI – Safety Net period should be at least equal or greater than your LAGGED database time to prevent data loss.
1 – Mailbox01 receives message from a server outside the transport high availability boundary
2 – Before acknowledging receipt, Mailbox01 initiates and succeeds in making the message redundant on Mailbox03’s shadow queues
3a – Transport on Mailbox01 processes message and attempts delivery via mailbox transport
3b – Mailbox transport on Mailbox01 in turn delivers the message to Store
3c – Transport on Mailbox01 queues a discard status for Mailbox03 (Shadow) and moves the message to Primary Safety Net.
4 – Mailbox03 (Shadow) periodically polls for delivery status on the primary copy of the message
5 – When Mailbox03 determines Mailbox01 has successfully processed the primary copy of the message, it moves the message to its Shadow Safety Net.
Inspired by Ross Smith’s IV presentation on Transport Architecture and thought of an interest to blog the same. You can check his presentation @TechEd Session