Hello again and welcome back to the third part of our journey to Exchange 2013. In the previous two posts (part 1, part 2) we covered preparing and installing Exchange 2013, as well as some news with the Client Access Server role and some design considerations. Now in this part we will try to cover some key aspects of transport in the new Exchange.
Hub Transport Role
As you already know, there is no Hub Transport server role in Exchange 2013, the transport pipeline has been split into three services, one of which is running on the CAS, the other two on the MBX role.
Front End Transport service
This service is running on the CAS role, like all other CAS services, it is nothing more than a stateless (but smart) proxy for inbound and outbound SMTP connections. Neither message queuing, nor message filtering happens here. The front end transport service talks to the transport service on the MBX server role.
Transport service
This service runs on the Mailbox server role, like the hub transport role in Exchange 2010, this service performs message queuing, inspection, categorization and so on. Very much NOT like in Exchange 2010, though, this service never talks to a mailbox database. This service routes messages between the front end transport service, the transport service and the mailbox transport service.
Mailbox Transport service
This service runs on the Mailbox server role, too. It receives messages via SMTP from the transport service and connects via RPC to the mailbox database to deliver the message. It also connects to mailbox databases via RPC to retrieve messages and forward them to the transport service, again using SMTP.
This shows one thing very clearly, through the use of SMTP, Exchange 2013 is able to break the close relationship between server roles that existed in previous versions. The front end transport role in CAS does no longer use RPC, an thus, could be running a different software version than the mailbox server, communication between mailbox servers, specifically between the mailbox transport service and the transport service, also uses SMTP and has no requirement to be on the same software version.
I used Wireshark to capture an incoming mail proxied through the CAS:
The Client (10.1.1.10) connects to the CAS (10.1.1.21) using TCP 25, all SMTP messages are exchanged between those two nodes. Note, that the CAS does only send the “250 Queued Mail for delivery” after connecting to the transport service on the Mailbox Server (10.1.1.25), since the Front End Transport service does not queue mails locally, this “smart proxy” functionality ensures that the message gets stored in the mailbox servers queue, before sending an OK to the client. The connection between CAS and MBX uses TCP 2525 and is encrypted using TLS, this is why Wireshark is not able to encode it as SMTP.
There is whole section on Transport on TechNet: http://technet.microsoft.com/en-us/library/aa996349.aspx
Migration Send and Receive connectors
Now that we know (a little bit) how transport works in Exchange 2013, we can start to include Exchange 2013 servers to the send connectors and configure the appropriate receive connectors.
To add Exchange 2013 servers as sources to the existing send connectors, use the Exchange Admin Center and navigate to “mail flow, send connectors”. Then select the send connector to edit and add the new source server under “scoping”
We could also use PowerShell to add additional SourceTransportServers to the connector, be aware though, that the existing servers have to be included in the command.
Set-SendConnector –Id ToInternet –SourceTransportServers ex14,ex15
Another interesting flag sits under the “general” node of the send connector’s properties: Proxy though client access server”
So what’s that all about? If this flag is checked, outbound mails are not sent directly by the mailbox server’s transport role, but are proxied through a Client Access Server. This could be interesting if only a subset of Exchange Servers (CAS) were allowed to connect to the internet via SMTP. With multi role servers, which are recommended for many environments, this flag will have no effect.
Ok, so now we have got our outbound mail flow configured, what about incoming mails? Receive connectors are per-server settings, so we have to check the configuration of existing connectors and configure the new server accordingly.
Get-ReceiveConnector –Server ex14 | ft Identity,Enabled,Bindings,RemoteIpRanges
This command shows all receive connectors on the 2010 server, along with the Ports used and the remote IP addresses that are allowed to use this connector. Obviously, if there are custom AD permissions or authentication methods defined, those have to be configured on the new server, too.
Nice, now we have got client access and transport covered, the next post will finally include moving some mailboxes to the new Exchange server.
so long,
tom