"In-depth Exchange 2013"10 Transport service Brief

In front of the content, we have a more in-depth introduction of the EXCHANGE2013 Client access role involved in the many details. In the following chapters, I'll talk to you about the transfer service in Exchange 2013, which is a whole lot more and more theoretical, so let's start with a brief and then split one.

In previous releases, The hub Transport (Hub Transport) role was introduced by Exchange2007 as the delivery hub for all message information, and any messages sent or received would inevitably pass through at least one Ex2010 and Ex2007 Hub Transport role In Exchange2013, any messages sent or received are bound to pass through the transport component on the MBX. This inevitability means that exchange can implement these features:

1. All messages will be filtered and processed by the transport rules, and the transport rules can set filtering rules for both inbound and outbound two-direction messages.

2, all the mail transmission path through the MBX server will have a log, that is, tracking logs, this feature in troubleshooting mail flow problems are often first taken into account.

3. MBX will save a temporary copy of the message that is currently being transmitted until the downstream server returns a confirmation message that the message was delivered. If a problem occurs in the normal message transfer path that causes the message to not be delivered immediately, MBX will attempt to send a temporary copy with a different message path.

4, the message will only reach the MBX server with the mailbox active database copy

5, within the organization, between the organization, the organization outside the mail flow can be monitored and managed.

As a messaging administrator, there are important considerations for Exchange transport systems:

1. Configure the default connector to meet the requirements in your organization.

2. High availability of message transfer paths

3. Necessary measures to meet compliance

4. Configure custom receive connectors for other SMTP clients within the environment, such as mail applications, scanner copiers, or other messaging systems

5, sudden abnormal situation need to quickly locate and efficiency processing

6, collect monitoring and reporting data, to be able to provide reports at any time.

Brief introduction of transport pipelines

Microsoft in many documents, whether for Exchange developers, or administrators, often use a word, called transport Pipeline. This concept is split into two parts in the Exchange real-world architecture, and looks like it's outlined. The figure shows that CAs and MBX are logically responsible for the different transmission modules respectively.

650) this.width=650; "title=" clip_image001 "style=" Border-top:0px;border-right:0px;border-bottom:0px;border-left : 0px; "border=" 0 "alt=" clip_image001 "src=" http://s3.51cto.com/wyfs02/M02/6F/6C/ Wkiom1wbk97hcmo3aad5qicqrfu392.jpg "height=" 484 "/>

Describe the inbound mail flow from this abstract diagram:

1. Inbound mail flow arrives at the Receive connector,

2. FET (MSExchangeFrontEndTransport.exe front end transfer) service to proxy the mail to the transport service on MBX

3, Transport (MSExchangeTransport.exe) service receive agent connection. Microsoft says the transport service in Ex2013 is almost identical to the Hub Transport service in earlier versions of Exchange, meaning the service is responsible for sorting messages, routing messages, applying transport rules, and inspecting and modifying headers and content (rendering messages).

4. The transport service initiates an SMTP connection to the mailbox Transport delivery Service (MSExchangeDelivery.exe) on MBX (note that this is not HTTP or RPC but an HTTP connection), which receives a transport connection, accepts inbound mail, and then uses the RPC connection to place the message To the information store. So throughout the process, the mailbox Transport delivery Service acts as an adapter between the RPC storage service and the SMTP traffic; the transport and FET services cannot directly connect to the store. Mailbox transport delivery and mailbox transport submission service using RPC to communicate with the store is the only place in the Exchange2013 where RPC services are used. The transport communication between the other internal servers is using SMTP.

Outbound mail traffic is basically the opposite of inbound traffic, when a user sends a new message, the client first stores the message in a specific folder: The Microsoft Outlook cache mode client exists in the sent message, Outlook online mode (or Outlook In the Outbox for MAC OS X, or in a draft of Outlook Web app. The Mail Transfer Submission Service (MSExchangeSubmission.exe) on MBX then takes the messages from these folders via RPC, sends them to the transport service, and then drops them to the Send connector.

There are exceptions to this process, such as some sort of mail application or the Mail manager's own mailing of the mail to the sorting or replay directory in MBX, which we'll explain in detail later in this article.

About mail flow I've also translated a post on TechNet blog:

http://sodaxu.blog.51cto.com/8850288/1651613

Brief description of Message routing

The implementation of message routing in Ex2013 is different from previous versions. In Exchange2010, the ad site is the primary boundary for message routing, and Exchange5.5 mail routing works similarly. In Exchange2000 and Exchange2003, mail routing relies on the concept of routing groups and routing group connectors to work. Exchange 2013 continues to use the ad site as part of the message routing scope, and the other part is the DAG group. A standalone MBX server (that is, mbx that is not joined to the DAG group) takes the ad site as the routing boundary, and the MBX server joined to the DAG Group takes a DAG relationship as the routing boundary. This change also has a direct effect on the changes of other components of Exchange2013 in a certain sense. Of course, there is still a need for robust connections between DAG members, especially for cross-site Dags.

On a standalone MBX, inbound mail is, of course, dropped directly into the database that owns the mailbox, and in the DAG, the inbound message is dropped to the active copy of the database that owns the mailbox (which is more appropriate for the active copy). So the routing component must provide a way for the sending server to identify which mbx the mailbox Transport delivery service can accept the message. This requirement is met by a component called Active Manager, which provides a table that lists which database's active replicas correspond to the MBX server.

On the other hand, the DAG itself can provide an elastic extension of the transport service, for example, if you deploy a cross-site Dag, any of the DAG members can handle the message, without the need for additional configuration.

The routing of a message is primarily the responsibility of the sorter component in the Trransport service, which determines the next-hop address of the message (the next destination) and then delivers the message to the queue of the corresponding destination. Queues include both local mail flow, which SMTP sends to the MBX mailbox delivery transport service, and possibly external mail flow, to other mail servers.

In fact, Exchannge2013 consists of three destination types: Mailbox database, mail Connector, distribution group expansion server (distribution group expansion). Each message will be delivered to one of these three destinations.

These three destinations are refined into drop groups (delivery Group) in exchange. For a more detailed description of the delivery group, I'll talk to you later in the article.

So far, for the transport services component on Exchange 2013, we should have a general understanding of the subsequent articles to specifically describe the components in detail; Please look forward to it.

This article is from the "Castamere Rainy season" blog, be sure to keep this source http://sodaxu.blog.51cto.com/8850288/1671741

"In-depth Exchange 2013"10 Transport service Brief