Implementing an email discovery,
compliance, archiving, and retention (DCAR) solution is similar to remodeling a house. You need a “blueprint” (plan) that provides detailed
instructions for the “remodeling”
(design, components, and implementation steps of the DCAR solution).
You also need to be able to translate
the plan into reality—as a contractor
would on a remodeling job—within
the budget and schedule you've allotted for the project. Like a remodeling,
implementing a DCAR solution might
disrupt your current messaging
scheme somewhat, but in the end it
will make your job as an Exchange
administrator easier and add functionality to your messaging system.
Fortunately, Exchange provides some
built-in features—message journaling, backup and restore APIs, and message and transport security—that
provide a framework for building a
DCAR solution. We'll examine those
features as well as some related technologies in Exchange, such as event
sinks, protocol logs, and message
tracking, and explore how each fits
into a DCAR strategy. And in the Web exclusive sidebar “Third-Party Products in an Exchange DCAR Solution,”
we'll look at
some important DCAR functions that
you'll need to obtain through third-party products and what to consider
when choosing such products.
Message Journaling
You'll find a growing degree of confusion about the difference between
archiving and journaling. From a
high-level point of view, you can
successfully argue that little distinguishes the two methods; both extract messaging data from the messaging
system. However, you do need to
know the difference, not only to
implement your solution correctly but
also to evaluate whether third-party
components will meet your needs.
Archiving is the process of removing content from the messaging system for long-term storage in some
other system, usually some type of
database. Email messages are taken
from user mailboxes according to criteria, such as age. Archiving technology usually provides some kind of
Web or mailbox-based extension
mechanism that lets users continue to
access archived content as necessary.
Features generally address the discovery, archiving, and retention components of DCAR. Archiving technology
is useful for mailbox management,
reducing storage requirements by
consolidating and compressing multiple copies of the same data and ensuring the preservation of corporate knowledge.
Journaling is the process of creating
or capturing copies of email messages
as they enter and traverse the messaging system, ensuring that those copies
are collected in central locations.
Together, the journal copies comprise
a searchable form of documentation
that administrators and auditors can
use to see the email messages that users
are sending and receiving. Journaling generally addresses the compliance
component of DCAR and is one of
the three common mechanisms for
moving messaging data into compliance and policy solutions. Journaling
usually doesn't provide any direct
benefits to end users, but it can be a
vital part of a complete DCAR solution.
Although Exchange has no built-in archiving functionality, it has
included basic journaling capabilities
since Exchange Server 5.5 Service Pack 1 (SP1). Over the years, Microsoft has increased journaling functionality in the various Exchange
releases, service packs, and occasional hotfixes. Today, Exchange
includes three types of journaling:
- simple journaling (also known as
message-only journaling)
- blind carbon copy (Bcc) journaling
- envelope journaling
All three types work on the same basic
principle: Almost every email message
that enters the Exchange organization
is examined to see whether it's bound
for a recipient configured for journaling. If it is, the first Exchange Server
categorizer through which it passes
creates another copy of the email message (in a process called bifurcation)
that's delivered to a specified journal
mailbox or public folder. The only
messages exempted from journaling
are system messages such as Active
Directory (AD) replication messages,
public folder replication messages,
and journal messages.
Note: Although you can specify a
public folder as the journal destination, Microsoft recommends that you
specify a mailbox. Journal messages
delivered to public folders can't be
stamped with the full range of data
with which email messages delivered
to a mailbox can be stamped.
Although you have some control over
which recipients care configured for
journaling, you should be aware that
your ability to perform this configuration isn't very granular in any current
version of Exchange. For Exchange
Server 2003 and Exchange 2000
Server, journaling is enabled on a
per–message-store basis. All mailboxes in enabled message-store databases are journaled, and all journal
messages that mailboxes generate in
that database are sent to the same
journal mailbox (although you can
configure separate journal mailboxes
for each message-store database).
In Exchange 5.5, you can enable
journaling for an entire organization or on a per-site or per-server basis. Be
aware that Exchange will capture and
copy only email messages that are
transmitted. If someone edits a message in-mailbox, the change won't be
captured. I know of at least one lawsuit that involved lawyers being blind-sided because they weren't aware that
email messages in their organization
had been changed to cover up evidence of wrongdoing. Opposing
counsel produced records of the original, unaltered messages. I'll review
the three types of journaling relative to
the goal of implementing a DCAR
solution.
Simple Journaling
Simple journaling has existed in
Exchange since Exchange 5.5 SP1.
When simple journaling is enabled,
the first Exchange categorizer to handle a given email message parses the
P2 header—the header information
contained within the actual message
that determines whether the relevant
mailboxes are in databases with journaling enabled. For email messages
sent within the organization that use
Messaging API (MAPI), remote procedure call over HTTP Secure (RPC over
HTTPS), Microsoft Outlook Web
Access (OWA), or another form of
HTTP access, this server is the
sender's mailbox server. Otherwise,
the bridgehead server receives the
message through SMTP or the
Exchange Message Transfer Agent
(MTA) service. Journal copies of the
email message are then sent to all
relevant journal mailboxes. You control simple journaling through the
Mailbox Store Properties dialog box,
as Figure 1 shows.
Let's look an example. Imagine an
Exchange organization with four
mailbox servers, EXCH01 through
EXCH04. Each mailbox server has
two mailbox stores, one for regular
users and one for journaling. Each
regular mailbox store is configured to
deliver to the journal mailbox in the
journal mailbox store on the same server. In addition, an SMTP bridgehead server handles all incoming and
outgoing SMTP traffic.
An external email message comes
into the organization addressed to
four recipients: Adam, Barbara, Charlie, and Denise. By chance, these four
recipients are homed on separate
mailbox servers. In addition to forwarding the email message to the
actual recipient mailboxes, the
bridgehead forwards it to the four
journal mailboxes, requiring extra
bandwidth, disk I/O, and CPU in the
process. That kind of traffic multiplier
can cause a significant performance
hit in organizations with geographically dispersed servers linked by low-bandwidth WAN connections or
organizations whose servers are
already running close to their peak
performance.
You might wonder why extra
bandwidth is required, given that the
SMTP stack in Exchange 2003 and
Exchange 2000 is supposed to send
only one copy of a message between
servers even when there are multiple
recipients on the destination server. Because the
journal copy of the message has extra properties stamped on it during the bifurcation process, the journal copy
technically counts as aseparate message. Be aware of this behavior when you design your solution.
Simple journaling has
some other limitations,
mainly because it uses
the P2 header information. Simple journaling
can't
- capture Bcc recipients. This limitation reduces
or eliminates journaling's usefulness; you
can't accurately track
email message
recipients.
- capture the results of any address
rewriting you might have
configured in your organization.
- uniformly expand distribution list
(DL) membership. This limitation
could leave you with a journaled
email message that contains the
DL name instead of the list of
members. How do you go about
proving the list's membership at
the time the email message passed
through the system? What if the list
constantly has members added
and removed? And consider how
this limitation can affect a large
organization with a complicated
AD replication topology.
The Exchange 5.5 version of simple
journaling has an additional flaw: The
journal copy captures display names
rather than actual email addresses. In
essence, you can't prove that an email
message actually went to a particular
recipient; you can guarantee only that
the message was sent to a recipient
who had that specific display name
configured at that specific time.
Previous
Register
