Date Published:. File Size:. System Requirements Supported Operating System. Install Instructions Click the Download button on this page to start the download, or choose a different language from the drop-down list and click Go. By default, the history depth for EdgeTransport.
Description : Monitors the number of messages in the Submission queue. Typically, message enter the Submission queue from Receive connectors. For more information, see Mail flow and the transport pipeline. A large number of messages in the Submission queue indicates the categorizer is having difficulty processing messages.
When the Submission queue is under pressure, the Exchange throttles incoming connections by delaying acknowledgement of incoming messages. If the pressure condition continues, Exchange gradually increases the tarpitting delay.
After the Submission queue utilization returns to the low level, Exchange reduces the acknowledgment delay and eases back into normal operation. By default, Exchange delays message acknowledgments for 10 seconds when under Submission queue pressure. If the resource pressure continues, the delay is increased in 5-second increments up to 55 seconds.
Exchange keeps a history of Submission queue utilization. If the Submission queue utilization doesn't go down to the low level for a specific number of polling intervals, known as the history depth , Exchange stops the tarpitting delay and rejects incoming messages until the Submission utilization goes back to the low level. By default, the history depth for the Submission queue is in polling intervals. Description : Monitors the percentage of memory that's used by all processes on the Exchange server.
This doesn't include virtual memory in the paging file. When the server reaches the high level of memory utilization, message dehydration occurs. Message dehydration removes unnecessary elements of queued messages that are cached in memory.
Typically, complete messages are cached in memory for increased performance. Removal of the MIME content from these cached messages reduces the amount of memory that's used at the expense of higher latency, because the messages are now read directly from the message queue database.
By default, message dehydration is enabled. Description : Monitors the percentage of total drive space that's consumed by all files on the drive that holds the message queue database transaction logs.
To change the default location, see Change the location of the queue database. This key controls the total allowed size of all uncommitted transaction logs that exist on the hard drive. The value of this key is used in the formula that calculates high utilization. If you customize this value, the formula becomes:. On Mailbox servers, this includes the message queue database, and the sender reputation database. On Edge Transport servers, this includes the message queue database, the sender reputation database, and the IP filter database that's used by the Connection Filtering agent.
Description : Monitors the percentage of total drive space that's consumed by all files on the drive that's used for content conversion. Description : Monitors the number of uncommitted transactions for the message queue database that exist in memory.
This feature is known as shadow redundancy. The transport service makes redundant copies of all delivered messages. This feature is known as Safety Net. In Exchange Server, transport high availability is more than a best effort for message redundancy, because redundancy doesn't depend on supported features of the sending mail server.
Therefore, you can say that Exchange Server attempts to guarantee message redundancy by keeping multiple copies of messages during and after delivery. For more information, see Transport high availability. The Client Access services on Exchange Mailbox servers are responsible for accepting all forms of client connections.
The Client Access frontend services proxy these connections to the backend services on the destination Mailbox server the local server or a remote Mailbox server that holds the active copy of the user's mailbox. Clients don't directly connect to the backend services. This communication is shown in the following diagram.
The protocol that's used by a client determines the protocol that's used to proxy the request to the backend services on the destination Mailbox server. In Exchange , telephony requests are different than other client connections. Instead of proxying the request, the Mailbox server redirects the request to the Mailbox server that holds the active copy of the user's mailbox. Server role consolidation : In Exchange or earlier, you could install the Client Access server role and the Mailbox server role on separate computers.
In Exchange or later, the Client Access server role is automatically installed as part of the Mailbox server role, and the Client Access server role isn't available as a separate installation option. This change reflects the philosophy of Exchange server role co-location that's been a recommended best practice since Exchange For information about how to configure mail flow in a new Exchange or Exchange organization, see Configure mail flow and client access. Front End Transport service on Mailbox servers : This service acts as a stateless proxy for all inbound and optionally outbound external SMTP traffic for the Exchange Server organization.
The Front End Transport service doesn't inspect message content, doesn't communicate with the Mailbox Transport service, and doesn't queue any messages locally. Transport service on Mailbox servers : This service is virtually identical to the Hub Transport server role in Exchange Server The Transport service handles all SMTP mail flow for the organization, performs message categorization, and performs message content inspection.
Unlike Exchange , the Transport service never communicates directly with mailbox databases. That task is now handled by the Mailbox Transport service. The Transport service routes messages among the Mailbox Transport service, the Transport service, the Front End Transport service, and depending on your configuration the Transport service on Edge Transport servers.
The Transport service on Mailbox servers is described in more detail later in this topic. Mailbox Transport service on Mailbox servers : This service consists of two separate services:. Mailbox Transport Submission service : This service connects to the local mailbox database using an Exchange remote procedure call RPC to retrieve messages.
The Mailbox Transport Submission service has access to the same routing topology information as the Transport service. The Mailbox Transport service doesn't communicate with the Front End Transport service, the Mailbox Transport service, or mailbox databases on other Mailbox servers.
It also doesn't queue any messages locally. Transport service on Edge Transport servers : This service is very similar to the Transport service on Mailbox servers. If you have an Edge Transport server installed in the perimeter network, all mail coming from the Internet or going to the Internet flows through the Transport service Edge Transport server.
This service is described in more detail later in this topic. The following diagram shows the relationships among the components in the Exchange transport pipeline. Although the diagrams in this topic show the components on a single Exchange server, communication also occurs between those components on different Exchange servers.
0コメント