Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Exchange Server 2010 : Managing Connectivity with Hub Transport Servers - Message Routing in the Organization

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
1/28/2014 12:39:47 AM

Let's start with a review of how Exchange 2010 delivers messages in a single Exchange organization. While similar to Exchange Server 2007, the message-routing architecture is sufficiently different from earlier versions of Exchange 2000/2003 (which is the version from which more administrators are moving to Exchange Server 2010) that it deserves additional mention.

You should understand a few important points about the basics of Exchange 2010 message routing:

  • All messages must go through the Hub Transport server role.

  • The Active Directory site architecture is used as a boundary for message routing.

  • All Active Directory sites that contain a Mailbox server must also have a Hub Transport server and a Client Access server.

One of the nice features of Exchange Server 2010 is that as long as your Active Directory site architecture has been properly configured, you will not need to worry about message-routing architecture design.

1. Basics of Exchange Message Routing

In earlier versions of Exchange, the message-routing architecture was based on a structure that was defined by the administrator. For example, in Exchange 2000/2003, the message-routing architecture was defined by a collection of servers separated by full-time and reasonably good available bandwidth. This collection of servers is called a routing group. Prior to Exchange 2000, all servers were grouped together into a single collection of servers called a site.

In Exchange 2000/2003, the administrator could define the routing groups and move servers between routing groups based on their message-routing requirements. Messages were then delivered between routing groups using some type of connector. The most common connector for routing groups is a connector called the routing group connector (RGC), which uses RPC or SMTP to deliver messages.

Exchange Server 2007 changed this by relying on the Active Directory site architecture rather than requiring administrators to create a separate routing infrastructure for their organization. Exchange Server 2010 builds on this major architectural change and continues to rely on Active Directory sites for message routing. Figure 1 shows a simple Active Directory site topology that consists of three Active Directory sites.

In Figure 1, each Active Directory site has a Mailbox server and a Hub Transport server. The Hub Transport server will always attempt a direct delivery of a message to a Hub Transport server in a remote Active Directory site even if that remote Active Directory site does not have an Active Directory site link directly to it. If you are still running any Exchange 2003 servers, though, they retain their routing group architecture and have routing group connectors to the Exchange 2010 Hub Transport servers.

Figure 1. Sample Active Directory site infrastructure

Customizing Routing

For some companies, the default site routing mechanism is not adequate.

Earlier, we briefly described a major architectural change for Exchange Server 2007 that was also adopted by Exchange Server 2010. This change is direct point-to-point connection (notwithstanding the underlining network infrastructure) for email delivery, which basically summarizes the desire of an Exchange server to deliver a message to its final destination site. If that delivery is not successful, a Hub Transport server will try to contact another Hub Transport for queuing and later delivery.

By default, Exchange Server 2010 Hub Transport servers always attempt to directly deliver a message to a remote Hub Transport server (in another Active Directory site). This feature ensures the quickest and most direct delivery of email messages to remote sites. The Hub Transport server ignores the Active Directory site link costs (and possibly your underlying network topology) and performs direct delivery. Note that Active Directory site link costs are relevant if the final destination is unavailable, and then the next site along the least cost route is contacted for email queuing. The servers in that site will then attempt to redeliver the message to the final destination based on its configured intervals.

We recently consulted for a company that required all email be delivered through a "hub" site. This is still possible by modifying the behavior of the Hub Transport delivery mechanism using the Set-AdSite Exchange Management Shell cmdlet. To make this functionality work, we followed these steps:

  1. Enable the hub site functionality using a command similar to this:

    Set-AdSite SiteName -HubSiteEnable $True

  2. Ensure that the Active Directory site link costs truly represent a "least cost" route from the remote sites to the hub site. Why? Well, the override feature of a hub site only works if that hub site is within the least cost path, as defined by the Active Directory Site Link costs. If the Hub Site is not within the least cost path and you don't want to disrupt your Active Directory replication topology, you can also create an Exchange-specific site link cost. The Exchange-specific site link cost is set by using a shell command such as this one:

    Set-AdSiteLink -Identity SiteLinkName -ExchangeCost CostValue

Luckily, the environment that we were working with already had the hub site within its least cost path, so that second command was not necessary. After the modifications were made, the Exchange routing topology resembled the underlying network infrastructure of routers and WAN links.

So Microsoft recommends that you implement hub site routing only if your network topology requires it, such as when you have a firewall between all the remote sites.


The Hub Transport server role is at the center of the message-routing architecture for messages being delivered internally as well as messages leaving the organization. All messages are processed by the Hub Transport server role regardless of whether they are being delivered locally or remotely. Figure 2 shows an example of the Hub Transport server sitting at the center of the message delivery universe.

The Hub Transport server role handles categorization, rule processing, transport-level journaling, and delivery for mail that is intended for local delivery and Mailbox servers in the same Active Directory site. The Hub Transport server uses the messaging API (MAPI) and RPCs to communicate with the Mailbox server role. If a message is to be delivered to a Mailbox server in a remote Active Directory site, the Hub Transport server delivers the message via SMTP to a Hub Transport server in the remote site; the remote Hub Transport server then delivers the message to the local Mailbox server via RPC.

The Exchange Server 2010 Hub Transport server handles message categorization. The Categorizer component figures out where the message is going next. Messages arrive in the submission queue, and the Categorizer picks up the message and processes it. Here are some of the steps involved in message categorization:

  • Expand any distribution lists, if applicable, by querying the global catalog.

  • Resolve recipient addresses to determine which recipients are local, remote, or outside the organization.

  • Apply message transport rules to the message.

    Figure 2. The Hub Transport server is at the center of all message delivery.
  • Split the message into multiple parts if the message is going to both local and remote recipients; this process is called bifurcation.

  • Examine the message sender, recipients, message header, body, and attachments and apply message transport rules that apply to that message.

  • Convert the message to the appropriate message format (Summary-TNEF, MIME, or UUencode) depending on the destination of the message.

  • Determine the next "hop" for the message.

  • Place the message into appropriate local or remote delivery queue.

With a few exceptions, such as application transport rules, the Categorizer function has not changed from Exchange 2000/2003.

As messages are moved within your organization's infrastructure, they are protected with different types of encryption. The encryption used is either RPC encryption or Transport Layer Security (TLS) encryption. Figure 3 shows different paths the message may take and how it is encrypted.

As messages are transmitted via MAPI over RPC between Mailbox servers and Hub Transport servers, RPC encryption is automatically used. When a message is transmitted from one Hub Transport server to another, the Hub Transport servers transport the message using SMTP, they authenticate using Kerberos, and the data stream is encrypted using TLS. When messages are transmitted from a Hub Transport server to an Edge Transport server, SMTP is used for message transfer, mutual authentication using certificates is used for authentication, and messages are encrypted using TLS. Optionally, an organization that is sending messages to another organization also using Edge Transport services can configure authenticated connections and TLS encryption to these remote organizations.

Figure 3. Messages are encrypted during transit.

Key Things to Remember about Hub Transport Servers

There are so many things that have changed in transport settings and transport configurations in Exchange Server 2010, that I like to keep a little "Cheat sheet"; a list of changes that are very relevant for administrators of previous versions of Exchange. We usually provide this list to our students, when we teach an Exchange class, and they find it very useful.

  • Hub Transport servers never connect to other Hub transport servers in the same site.

  • Hub Transport servers always communicate over SMTP to Hub transport servers in other sites.

  • Hub Transport servers always communicate over RPC to Mailbox servers in the same site.

  • If you install multiple Hub transport servers in the same site, Mailbox servers will automatically load balance the connections between the Hub transport servers.

  • When the Mailbox server and Hub Transport server roles coexist on the same server, the Mailbox server will always attempt to use another Hub Transport server in the site, instead of the locally installed Hub Transport server.

  • Hub Transport servers encrypt all connections, by using Mutual TLS, to other Hub Transport servers in other sites.

  • Hub Transport servers handle all email messages sent between all users, even two users who have mailboxes in the same Mailbox database.

  • Client Access servers never communicate with Hub Transport servers.

Other -----------------
- Microsoft Exchange Server 2010 : Managing Connectivity with Hub Transport Servers - Transport Improvements in Exchange Server 2010
- Windows Server 2012 Administration : Configuring Sites (part 3) - Establishing Site Links, Delegating Control at the Site Level
- Windows Server 2012 Administration : Configuring Sites (part 2) - Creating a Site - Adding Domain Controllers to Sites
- Windows Server 2012 Administration : Configuring Sites (part 1) - Creating a Site - Creating Site Subnets
- Windows Server 2012 Administration : Examining Active Directory Site Administration
- Windows Server 2012 Administration : Defining the Administrative Model
- Sharepoint 2013 : Backup and Restore (part 6) - Farm Backup and Restore - Performing a Restore, Using PowerShell
- Sharepoint 2013 : Backup and Restore (part 5) - Farm Backup and Restore - Performing a Backup
- Sharepoint 2013 : Backup and Restore (part 4) - Farm Backup and Restore - Farm Backup Settings
- Sharepoint 2013 : Backup and Restore (part 3) - Unattached Content Database Data Recovery
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server