Develop an Exchange Compliance Strategy

Implementing an email discovery,compliance, archiving, and retention (DCAR) solution is similar to remodeling a house. You need a “blueprint” (plan) that provides detailedinstructions for the “remodeling”(design, components, and implementation steps of the DCAR solution).You also need to be able to translatethe plan into reality—as a contractorwould on a remodeling job—withinthe budget and schedule you've allotted for the project. Like a remodeling,implementing a DCAR solution mightdisrupt your current messagingscheme somewhat, but in the end itwill make your job as an Exchangeadministrator easier and add functionality to your messaging system.Fortunately, Exchange provides somebuilt-in features—message journaling, backup and restore APIs, and message and transport security—thatprovide a framework for building aDCAR solution. We'll examine thosefeatures as well as some related technologies in Exchange, such as eventsinks, protocol logs, and messagetracking, and explore how each fitsinto a DCAR strategy. And in the Web exclusive sidebar “Third-Party Products in an Exchange DCAR Solution,”we'll look atsome important DCAR functions thatyou'll need to obtain through third-party products and what to considerwhen choosing such products.

Message Journaling

You'll find a growing degree of confusion about the difference betweenarchiving and journaling. From ahigh-level point of view, you cansuccessfully argue that little distinguishes the two methods; both extract messaging data from the messagingsystem. However, you do need toknow the difference, not only toimplement your solution correctly butalso to evaluate whether third-partycomponents will meet your needs.

Archiving is the process of removing content from the messaging system for long-term storage in someother system, usually some type ofdatabase. Email messages are takenfrom user mailboxes according to criteria, such as age. Archiving technology usually provides some kind ofWeb or mailbox-based extensionmechanism that lets users continue toaccess archived content as necessary.Features generally address the discovery, archiving, and retention components of DCAR. Archiving technologyis useful for mailbox management,reducing storage requirements byconsolidating and compressing multiple copies of the same data and ensuring the preservation of corporate knowledge.

Journaling is the process of creatingor capturing copies of email messagesas they enter and traverse the messaging system, ensuring that those copiesare collected in central locations.Together, the journal copies comprisea searchable form of documentationthat administrators and auditors canuse to see the email messages that usersare sending and receiving. Journaling generally addresses the compliancecomponent of DCAR and is one ofthe three common mechanisms formoving messaging data into compliance and policy solutions. Journalingusually doesn't provide any directbenefits to end users, but it can be avital part of a complete DCAR solution.

Although Exchange has no built-in archiving functionality, it hasincluded basic journaling capabilitiessince Exchange Server 5.5 Service Pack 1 (SP1). Over the years, Microsoft has increased journaling functionality in the various Exchangereleases, service packs, and occasional hotfixes. Today, Exchangeincludes three types of journaling:

All three types work on the same basicprinciple: Almost every email messagethat enters the Exchange organizationis examined to see whether it's boundfor a recipient configured for journaling. If it is, the first Exchange Servercategorizer through which it passescreates another copy of the email message (in a process called bifurcation)that's delivered to a specified journalmailbox or public folder. The onlymessages exempted from journalingare system messages such as ActiveDirectory (AD) replication messages,public folder replication messages,and journal messages.

Note: Although you can specify apublic folder as the journal destination, Microsoft recommends that youspecify a mailbox. Journal messagesdelivered to public folders can't bestamped with the full range of datawith which email messages deliveredto a mailbox can be stamped.Although you have some control overwhich recipients care configured forjournaling, you should be aware thatyour ability to perform this configuration isn't very granular in any currentversion of Exchange. For ExchangeServer 2003 and Exchange 2000Server, journaling is enabled on aper–message-store basis. All mailboxes in enabled message-store databases are journaled, and all journalmessages that mailboxes generate inthat database are sent to the samejournal mailbox (although you canconfigure separate journal mailboxesfor each message-store database).

In Exchange 5.5, you can enablejournaling for an entire organization or on a per-site or per-server basis. Beaware that Exchange will capture andcopy only email messages that aretransmitted. If someone edits a message in-mailbox, the change won't becaptured. I know of at least one lawsuit that involved lawyers being blind-sided because they weren't aware thatemail messages in their organizationhad been changed to cover up evidence of wrongdoing. Opposingcounsel produced records of the original, unaltered messages. I'll reviewthe three types of journaling relative tothe goal of implementing a DCARsolution.

Simple Journaling

Simple journaling has existed inExchange since Exchange 5.5 SP1.When simple journaling is enabled,the first Exchange categorizer to handle a given email message parses theP2 header—the header informationcontained within the actual messagethat determines whether the relevantmailboxes are in databases with journaling enabled. For email messagessent within the organization that useMessaging API (MAPI), remote procedure call over HTTP Secure (RPC overHTTPS), Microsoft Outlook WebAccess (OWA), or another form ofHTTP access, this server is thesender's mailbox server. Otherwise,the bridgehead server receives themessage through SMTP or theExchange Message Transfer Agent(MTA) service. Journal copies of theemail message are then sent to allrelevant journal mailboxes. You control simple journaling through theMailbox Store Properties dialog box,as Figure 1 shows.

Let's look an example. Imagine anExchange organization with fourmailbox servers, EXCH01 throughEXCH04. Each mailbox server hastwo mailbox stores, one for regularusers and one for journaling. Eachregular mailbox store is configured todeliver to the journal mailbox in thejournal mailbox store on the same server. In addition, an SMTP bridgehead server handles all incoming andoutgoing SMTP traffic.

An external email message comesinto the organization addressed tofour recipients: Adam, Barbara, Charlie, and Denise. By chance, these fourrecipients are homed on separatemailbox servers. In addition to forwarding the email message to theactual recipient mailboxes, thebridgehead forwards it to the fourjournal mailboxes, requiring extrabandwidth, disk I/O, and CPU in theprocess. That kind of traffic multipliercan cause a significant performancehit in organizations with geographically dispersed servers linked by low-bandwidth WAN connections ororganizations whose servers arealready running close to their peakperformance.

You might wonder why extrabandwidth is required, given that theSMTP stack in Exchange 2003 andExchange 2000 is supposed to sendonly one copy of a message betweenservers even when there are multiplerecipients on the destination server. Because thejournal copy of the message has extra properties stamped on it during the bifurcation process, the journal copytechnically counts as aseparate message. Be aware of this behavior when you design your solution.

Simple journaling hassome other limitations,mainly because it usesthe P2 header information. Simple journalingcan't

The Exchange 5.5 version of simplejournaling has an additional flaw: Thejournal copy captures display namesrather than actual email addresses. Inessence, you can't prove that an emailmessage actually went to a particularrecipient; you can guarantee only thatthe message was sent to a recipientwho had that specific display nameconfigured at that specific time.

Bcc Journaling

Bcc journaling is really simple journaling on steroids. No additional UI isexposed to turn on Bcc journalingfunctionality. Instead, in the HKEY_LOCAL_MACHINESystemCurrentControlSetServicesMSExchangeTransportParameters registry subkey,you need to specify JournalBCC(REG_DWORD), with a value of 0x01to enable and 0x00 to disable.

Restart the SMTP and ExchangeInformation Store services to pick upthe change. When the Exchange storedetects this registry value on startup,it enables capture of the Bcc recipientson journaled messages and recordsthis information in the journal copy ofthe captured messages.

Caution: Make sure that all yourExchange servers have the necessaryupgrades for the level of journalingyou use. If you use Bcc journaling onone server, make sure you enable it onevery server that has message journaling enabled.

Microsoft included support for Bccjournaling in the original release ofExchange 2003, but the feature stillsuffered from the DL-expansion problem. Exchange 2003 SP1 added support for DL expansion. If you haveExchange 2000 servers in your organization, you can add both capabilitiesby ensuring that you upgrade yourservers to Exchange 2000 SP3 and addthe hotfix described in the Microsoftarticle “Bcc information is lost forjournaled messages in Exchange2000” (http://support.microsoft.com/?kbid=810999). No upgrades or hotfixes can give you Bcc journaling functionality in Exchange 5.5.

Envelope Journaling

Microsoft introduced envelope journaling (aka advanced journaling) inExchange 2003 SP1. It's designed toaddress the limitations of simple journaling and Bcc journaling by using theP1 header data. Like Bcc journaling,envelope journaling was retrofitted toExchange 2000 servers; they must run Exchange 2000 SP3 plus the post–SP3Update Rollup. (For more informationabout the rollup package, see theMicrosoft article “An update rollup isavailable to enable the Envelope Journaling feature in Exchange 2000Server” at http://support.microsoft.com/?kbid=834634.) Again, noupdates for Exchange 5.5 provide thisfunctionality.

In many respects, envelope journaling works much like simple journaling; it's still invoked by the firstcategorizer to handle a message andstill configured on a per-store basis.The big difference is that whereassimple journaling looks at the P2headers, envelope journaling looks atthe P1 headers. The latter approachprovides several benefits over simplejournaling or Bcc journaling. Envelopejournaling

Instead of sending a bifurcatedcopy of the original email message tothe journal mailbox, envelope journaling creates a separate journalreport message. It then makes anexact copy of the original message asan attachment to the journal reportmessage. This approach preserves theoriginal message exactly as it wassent; it contains original headers, DLsare intact, and Bcc recipient information isn't displayed in the originalmessage while still being available inthe journal report message.

It sounds great, but the downside isthat envelope journaling frequentlyresults in multiple copies of the journal report message (and attached originalmessage) being delivered to the journal mailbox. This behavior is anexpected consequence of using the P1headers. The server that performs theoriginal categorizer might not have allthe information it needs to completelyidentify all message recipients. It generates an incomplete journal reportmessage with the best information ithas, then forwards copies to otherservers for them to process. The stepsof the process follow:

The result? You now have multiplecopies of the journal report (and theoriginal, attached email message) inthe journal mailbox. All these copiescontain different subsets of the finalmessage recipients. They're all keyedfrom the same message ID, whichmeans that whenever you audit message delivery, you must examine allrelated journal-report messages.

If your organization is dispersedover multiple sites linked by low-bandwidth WAN connections, envelope journaling can have a significanteffect. The following steps show youhow to set up envelope journaling ina way that mitigates potential negativeeffects:

At this point, you don't need torestart services. As your AD replicationtakes place, your Exchange servers willpick up the changed configurationvalue and switch over to the newbehavior.

Backup and Restore APIs

If you're like many of your fellowExchange administrators, yourbackup and restore plans for yourExchange organization are often amajor driver of current operationalprocedures. It might not seem thatyour backup and restore process isdirectly related to DCAR, but if youstop and think for a moment, you'llrealize that it is. Here are a handful ofways in which DCAR and backups arerelated:

If you use (or intend to use) someform of message journaling, you'llneed to modify your backup andrestore plans. Journaling mailboxesaccumulate a large amount of trafficquickly, which can affect your backupand restore windows. If you followrecommended practices and establish your Exchange journaling mailboxes in separate message stores,you'll need to back up those stores.

Whatever form of backup andrestore you use, you must ensure thatit actually supports Exchange. Takinga backup of the database files directlyfrom the file system (including severalsnapshot solutions that storage vendors offer) is a bad idea for several reasons. Not only is it extremely difficultfor a solution that uses this approachto ensure that your databases arebacked up in a consistent state, sucha solution does nothing to address thegrowth of your Exchange databasetransaction logs. A proper Exchange-aware backup uses established APIs toperform the necessary log truncationafter a successful backup of the store,which shortens restoration time(fewer transactions must replay afterthe files have been restored) and helpsconserve disk space.

If you need a snapshot-basedbackup strategy and you run Exchange2003 on Windows Server 2003, youmight be able to take advantage ofMicrosoft Volume Shadow Copy Service(VSS)–based backups. By using VSS,the Windows OS provides a tested andsupported snapshot capability, lettingcompatible backup systems take theirbackup against a consistent shadowcopy of the database.

Sometimes, designing a complicated backup solution for Exchangeisn't the best answer. If WindowsBackup (aka NTBackup) is goodenough for Microsoft's productionservers, it's probably good enough foryours. You can use NTBackup to create an on-disk backup of yourExchange databases, then use yourenterprise backup software to transfer those files to other media. A disk-to-disk strategy removes your relianceon slower, less reliable technologies,and, in turn, helps your backup andrestore process run more quickly.

Don't gamble with your backups.Actively test your backup and restoreplans by using duplicates of your production hardware and software sothat you know you can restore yourdata when it counts. Ensure that yourbackup methodology is Exchangeaware and that Microsoft supports it.And don't forget that Exchange 2003features—namely the Recovery Storage Group (RSG)—can make yourrestoration processes run much moresmoothly.

Message and TransportSecurity

Message security encompasses twomain areas: message encryption (usingcryptography to protect the actualmessage from inspection by unauthorized parties) and transport encryption(using cryptography to protect discrete connections between components of the messaging system).

Message encryption. Messagesecurity has clear implications foryour DCAR solution. In particular,you need to consider the followingquestions:

Exchange 2003 and Exchange 2000come with strong support forS/MIME; the Exchange 2003 versionof OWA extends this support to OWAusers. However, the practical considerations of deploying and managingthe requisite PKI, dealing with thecontent-inspection challenges, andarchiving keys tend to make the use ofS/MIME unattractive for most organizations unless they're required to useit (e.g., government Exchange deployments).

Transport encryption. Transportencryption, on the other hand, is easywith Exchange and Windows andtends to mesh well with any third-party components of your DCAR solution. Exchange 2000 and later nativelysupport Secure Sockets Layer (SSL)and Transport Layer Security (TLS) fora variety of protocols; Windows 2000and later provide built-in IPsec functionality. Don't rely on MAPI encryption to protect connections betweenOutlook and Exchange; either deployIPsec policies or upgrade to MicrosoftOffice Outlook 2003 and Exchange2003 so that you can use RPC overHTTPS.

In my experience, Microsoft Internet Security and Acceleration (ISA)Server 2004 is one of the best investments you can make to help providea higher level of message securitybetween the Internet and your Exchange organization. Placing an ISAserver in your demilitarized zone(DMZ) means never having to exposeyour Exchange servers directly toincoming Internet traffic and greatlysimplifies your firewall configuration.Plus, ISA permits SSL bridging, sothat you can perform protocol-awareproxying and filtering of SMTP andHTTP connections while still providing transport encryption for everyconnection.

Related Technologies

A variety of other Exchange technologies and features aren't directly relatedto DCAR but still provide useful hooksinto your Exchange organization ormake deployment and troubleshooting easier to perform:

Completing the Solution

As you've seen, you can useExchange's built-in journaling, alongwith Exchange 2003's support for VSSand message and transport encryption plus related features such as message tracking, as the foundation ofyour Exchange recovery and compliance solution. However, Exchangedoesn't provide certain other essentialDCAR functions, such as archivingand PST management. To completeyour Exchange DCAR solution, you'llwant to look into third-party productsthat can provide these capabilities.

This article is adapted from EmailDiscovery and Compliance, Chapter5: Implementation, Part 2—Hardwareand Software (Windows IT Pro eBooks, 2006).