1. Introducing the New Exchange 2010 Transport Architecture
In all versions of Exchange from 4.0 through 2003,
the message database 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 the user's Mailbox server. This
store-centric architecture made it possible for Exchange to perform
certain tasks quickly and efficiently, but also made it more difficult
to consistently perform certain types of tasks on all
email messages (inbound, outbound, and internal) necessary to meet
regulatory requirements. The role-based architecture in Exchange Server
2010 is a direct answer to many of these difficulties.
To illustrate the problem, take the common
requirement in many businesses of ensuring that messaging policies are
applied to all messages in the organization. In older versions of
Exchange, if you send a message to another user whose mailbox is on the
same server your mailbox is on, the message never passes through a
transport component. As a result, the code for the message store
becomes more complex in order 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 distinction in Exchange Server 2010
between transport servers (two different kinds, in fact: Hub Transport
[HT] 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 the
message off to a local HT role in the site. The HT server can determine
which policies apply, which recipients need to get a copy of it, and
whether any special actions need to be taken. All messages are now
handled consistently, the code is cleaner and more efficient, and
third-party applications have a well-defined set of interfaces to hook
into.
1. All Messages Pass Through Hub Transport
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. Mainly, and more
importantly, it ensures that every single message can be captured by
Exchange's transport components and therefore can act upon that
message.
Message Classifications
These are annotations to an email 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
These are server-side rules that allow you to
create and apply messaging policies throughout the entire Exchange
Server 2010 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 modify messages as they are sent or received from the
Internet.
Message Journaling
This 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. Note that Exchange Server 2010 also offers
archival of content through the Personal Archive functionality,
Retention tags, Retention policies and many other technologies designed
around the compliance needs of an organization.
2. Setting Up Message Classifications
At their heart, message classifications are simply
labels that are set on certain messages. These labels in turn allow
other software, such as Outlook and Outlook Web Access (OWA), to
display a visual warning for the user and, optionally, take special
action when processing the message with rules.
Message classifications have four principal properties:
The display name determines how the classification is displayed in the client user interface and is scanned by the mailbox rules engine.
The sender description
allows the client interface to tell the sender the purpose of this
classification if it isn't clear from the display name alone.
The recipient description allows the client interface to tell the recipient the purpose of this classification.
The locale is a code that defines the localized version of a classification.
Figure 1
illustrates how Outlook 2007 displays a message classification on a
message by means of the additional colored field directly above the To
line. The text of this message classification states, "R + D Internal
Only—This message may contain confidential Ithicos Solutions
confidential Research and Development information. Do not forward to
external parties without department lead approval."
For Outlook end users, this classification was
simple to add—all they needed to do was to click the Permissions button
and choose from a list of valid classifications. The same
classification labels are also included (automatically) with Outlook
Web Access.
Out of the box, Exchange Server 2010 comes with six
message classifications: A/C Privileged, Attachment Removed, Company
Confidential, Company Internal, Originator Requested, Alternate
Recipient Mail, and Partner Mail. By default, these classifications are
informational only; no associated rules enforce them, and their purpose
is simply to display text to recipients. You can modify these default
classifications, and create new ones, to suit your business needs, such
as the message classifications shown in Figure 2.
No GUI exists for creating and managing classifications; you must use
the Exchange Management Shell (EMS).
In addition to the basic classification properties, you can optionally set some other properties:
You can specify the precedence, which
determines the order that a given classification is applied to a
message if multiple classifications are set. You have nine values
(Highest, Higher, High, MediumHigh, Medium, MediumLow, Low, Lower, and
Lowest) from which to choose.
You can
specify whether a given classification should be retained on the
message if it is forwarded or replied to; some classifications, such as
Attachment Removed, would make little sense when applied to a forwarded
copy of a message or to its replies.
You
can create localized versions of message classifications if you are
working in a multilingual organization. When working with
localizations, Outlook 2007 and OWA will display the accurate
classification based on the localization settings configured on the
client.
By default, OWA supports the display and
manual selection of message classifications.
