Introducing the New Exchange 2007 Transport Architecture

In all versions of Exchange from 4.0 through 2003, the message store was an integral part of the message routing and transport architecture. This is in large part because of its use of the MAPI protocol, in which the client's main point of contact with the messaging system is the MAPI session to their mailbox server. This store-centric architecture made it possible for Exchange to perform certain tasks very quickly and efficiently, but it also made it more difficult to consistently do the types of tasks necessary to meet regulatory requirements. The new role-based architecture in Exchange 2007 is a direct answer to many of these difficulties.

To illustrate the problem, take the typically common requirement in many businesses of ensuring that messaging policies are applied to all messages in the organization. In legacy Exchange, if you send a message to another user whose mailbox is on the same server your mailbox is on, the message would never pass through a transport component. The code for the message store becomes more complex in order to deal with the necessity of having to apply policies at this level, third-party developers have to find ways to hook into this process, and the mailbox server runs more and more code that has nothing to do with the basic task a mailbox server is supposed to handle (which is storing and retrieving messages in the most efficient manner possible).

In contrast, the new distinction between transport servers (two different kinds, in fact: Hub Transport and Edge Transport) and mailbox servers permits the mailbox servers to run only the code that deals with storage and disk I/O. If a message is submitted for delivery, the mailbox server doesn't have to try to figure out exactly what to do with it; instead, it hands it off to a local HT role in the site. The HT server can figure out which policies apply, which recipients need to get a copy of it, and whether any special actions need to be taken. Every message is now handled consistently, the code is cleaner and more efficient, and third-party applications have a well-defined set of interfaces to hook into without having to account for a ton of screwy special edge cases.

Tip 

Yes, you read that correctly. Every single message you send in Exchange passes through a Hub Transport server, even when you're sending it to another mailbox in your storage database. Although this might seem inefficient at first glance, the reality is that the resulting benefits make this a great design change.

We'll cover three new capabilities in Exchange 2007 in detail in this chapter:

• Message classifications are annotations to an e-mail message that mark it as belonging to a designated category of information that Exchange and Outlook may need to treat in a special fashion. These annotations are exposed as properties of the message, allowing clients to display them visually for the users as well as permitting them to be exposed to the rules engine for automated processing. As an example, all messages with certain keywords can be classified as being confidential.

• Transport rules are server-side rules that allow you to create and apply messaging policies throughout the entire Exchange Server 2007 organization. They come in two varieties: hub transport rules, which are intended to be used for compliance enforcement and policy application activities, and edge transport rules, which are designed to help protect your organization from viruses and other external threats.

• Message journaling is the process of capturing complete copies and histories of specified messages within your organization. Journaled message reports are generated and sent to specified recipients, which can be within the Exchange organization or some external entity. Journaling may not be exciting or useful by itself, but it's one of the main ways to get messaging data into an external archival system.

You'll examine each of these technologies in more detail in this chapter.