Understanding Exchange Journaling Issues

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Because business communications are affected by growing government regulations, such as the Sarbanes-Oxley Act of 2002 (SOX), many organizations have had to increase their use of journaling for electronic data.

To address this need, Microsoft Exchange Server 5.5 and later versions of Exchange include some form of message journaling.

In its most basic form, journaling is the act of making a copy of every message that moves through a particular server, and then sending those copies to a separate mailbox for storage. The types of journaling that are available depend on the version of Exchange that is used.

Overview of Exchange Server 2003 SP1 Journaling

Starting with Microsoft Exchange Server 2003 Service Pack 1 (SP1), message journaling can use one of the following three formats:

• Message-only Journaling: Sends a copy of the original e-mail message together with the P2 header information to the journal mailbox. This does not include BCC information or members of a distribution group after the group is expanded.

• BCC Journaling: Similar to message-only journaling except that it also captures BCC information.

• Envelope Journaling: Captures all envelope (P1) header information. This includes BCC recipients and expanded distribution group membership. A journal report is sent to the journal mailbox together with the original message, as an attachment.

Enabling Journaling

Journaling is enabled on the database of the user mailboxes that you want to journal. To enable journaling, configure a journal recipient to store the journaled messages, and then set the msExchMessageJournalRecipient attribute of the mailbox store.

To set the msExchMessageJournalRecipient attribute, follow these steps:

1. Start the Active Directory Service Interfaces (ADSI) Edit tool. To do this, click Start, click Run, type adsiedit.msc, and then click OK.

2. Expand the following path under the Configuration container:

   • CN=Configuration [<domainController>.contoso.com]

   • CN=Services

   • CN=Microsoft Exchange

   • CN=<OrganizationName>

   • CN=Administrative Groups

   • CN=<AdministrativeGroupName>

   • CN=Servers

   • CN=<ServerName>

   • CN=InformationStore

   • CN=<StorageGroupName>

3. In the details pane, right-click CN=Mailbox Store (<ServerName>), and then click Properties.

4. On the Attribute Editor tab, click msExchMessageJournalRecipient in the Attributes list, and then click Edit.

5. In the Value box, type the distinguished name (DN) of the journal recipient mailbox that you want to use, and then click OK. For example, type CN=Journal User,OU=ServiceAccts,DC=contoso,DC=com.

6. Click OK to close the CN=Mailbox Store (<ServerName>) Properties dialog box, and then exit the ADSI Edit tool.

After you set this attribute, all messages sent to users and received from users on the store are journaled to the journal recipient that you specified. Depending on the type of journaling enabled, the journal recipient receives a copy of the original message or a journal report.

Envelope Journaling

Envelope journaling is enabled by setting the heuristics attribute on the msExchOrganizationContainer object to 512.

You can set this attribute manually or by using the Exejcfg utility. To set the heuristics attribute manually, follow these steps:

1. Start the ADSI Edit tool. To do this, click Start, click Run, type adsiedit.msc, and then click OK.

2. Expand the following path under the Configuration container:

   • CN=Configuration [<domainController>.contoso.com]

   • CN=Services

   • CN=Microsoft Exchange

   • CN=<OrganizationName>

3. In the navigation pane, right-click CN=<OrganizationName>, and then click Properties.

4. On the Attribute Editor tab, click heuristics in the Attributes list, and then click Edit.

5. In the Value box, type 512, and then click OK.

1. Click OK to close the CN=<OrganizationName> Properties dialog box, and then exit the ADSI Edit tool.

To use the Exejcfg tool to set the heuristics attribute, follow these steps:

1. Download the Exejcfg.exe tool from the following location:
   Microsoft Exchange Server Email Journaling Advanced Configuration

2. Extract the Exejcfg.exe tool, and then run the following command to set the heuristics attribute:

   exejcfg -e
   

Envelope journaling generates a journal report together with an attached e-mail message. The report contains a list of the recipients who are specified in the To, CC, and BCC fields. Additionally, the report contains the members of expanded distribution groups (local to the organization).

Journal reports are transferred among Exchange 2003 servers by using the EXCH50 binary large object (BLOB). This BLOB is a proprietary extension to ESMTP. Specifically, journal reports are transferred in a PR_CONTENT_IDENTIFIER property that is set to ExJournalData.

Exchange Server 2007 Journaling Overview

Exchange 2007 journaling differs slightly from the process in earlier versions of Exchange. Exchange 2007 uses only envelope journaling. Additionally, Exchange 2007 supports the following two types of envelope journaling:

• Standard journaling: This is the same as the implementation of envelope journaling in Exchange 2003.

• Premium journaling: This allows for more granularity and flexibility in journaling. Premium journaling lets an administrator perform journaling based on distribution group membership, or on a per-recipient or per-sender basis.

Regardless of which type of journaling is used, Exchange 2007 creates the same journal report and starts journaling by using the journal agent that runs on the Hub Transport server. For more information, see White Paper: Exchange 2007 Transport Journaling.

The main difference between journaling in Exchange 2003 and in Exchange 2007 is where the journal report is created.

In Exchange 2003, the journal report is created in the store on the server that hosts the journal recipient mailbox. Although the initial settings and metadata for the journal report are created on the sending server, the actual journal report is not formed until it reaches the journal recipient messaging database. This is the main reason why you should not journal directly to a contact in Exchange 2003. Instead, you should send the journal report to an Exchange mailbox, and then configure a server-side Outlook rule to forward the journal report to the contact.

In Exchange 2007, the store driver (together with the content conversion functionality) is moved to the Hub Transport server role. Therefore, journal reports are fully created in the transport component. The reports do not require additional conversion. This lets an administrator journal directly to a contact.

Unlike earlier versions of Exchange, Exchange 2007 does not use the EXCH50 BLOB to propagate journal information. Instead, Exchange 2007 uses X-Header information to propagate journal information. Specifically, Exchange 2007 uses the "X-Microsoft-Exchange-ProcessedByJournaling" header to signify that a message has been processed by the journal agent. Unless the recipient list changes, the message does not have to be journaled again. This helps avoid duplicate journaling entries. Additionally, Exchange 2007 adds the "X-MS-Exchange-Organization-Journal-Report" header to identify a message as a journal report. This header prevents the journal report from being journaled.

In Exchange 2007, all journaling is processed by the journal agent on the Hub Transport server. The journal agent is triggered during OnSubmitted and OnRouted events in the transport pipeline. This behavior helps guarantee message fidelity. For example, if another agent modifies the recipient list or causes the distribution list to be expanded, or if you have an alternative recipient set, the changes are captured in the journal report.

Exchange 2007 SP1

Exchange 2007 SP1 includes a new flag for journaled messages. This is the MustDeliver flag. It appears as follows in the X-Headers.

X-MS-Exchange-Organization-Transport-Properties: MustDeliver=True;

This flag indicates that Exchange must not generate a non-delivery report (NDR) for a journal report. If the journal recipient mailbox is unavailable, or if some other issue prevents delivery of the journal report, the journal message remains in the submission queue in a retry state until Exchange can deliver the message or until an administrator removes the message manually.

Known Issues That Affect Mixed Exchange 2003 and Exchange 2007 Journaling

The following sections describe journaling issues that you may experience in Exchange 2007 or in Exchange 2003.

Missing journal reports

Exchange 2003 creates the full journal report in the same store as that of the journal recipient mailbox. However, Exchange 2007 creates a fully-formed journal report in the transport component. This report is created when the journal agent is triggered on the server that is running the Hub Transport role.

Because of these differences, the following kinds of messages will not contain a journal report if a journal mailbox is put on an Exchange 2007 server:

• Messages that originate from an Exchange 2003 server

• Messages that have an Exchange 2003 server as the first point of entry from the Internet into an organization

In these cases, the journal mailbox will contain only a copy of the original message without a journal report, and the following information will be missing:

• BCC recipients

• Expanded distribution group membership

• Header data

Therefore, we recommend that you locate the journal mailbox on an Exchange 2003 server in a mixed mode organization.

Duplicate Journal Reports When Messages Originate from Exchange 2007

Exchange 2007 indicates a journal report that is in transit by using the X-Microsoft-Exchange-ProcessedByJournaling organization X-Header. Exchange 2007 performs the following action to provide interoperability with Exchange 2003: When an Exchange 2007 Hub transport server determines that the next hop is an Exchange 2003 server, Exchange 2007 promotes the X-Header to an EXCH50 BLOB that Exchange 2003 servers can interpret.

Consider the following scenario that may occur when a journal message passes through two or more Hub Transport servers on the way to an Exchange 2003 journal mailbox.

• When Hub Transport Server A determines that the next hop is an Exchange 2007 Hub Transport server, Server A does not create an EXCH50 BLOB for the journal message.

• When the message arrives at Hub Transport Server B, Server B recognizes the X-Microsoft-Exchange-ProcessedByJournaling X-Header. Because the recipient list has not changed, the journal agent is not triggered and the message is passed on to the Exchange 2003 server.

• Because Exchange 2003 does not recognize the X-Microsoft-Exchange-ProcessedByJournaling X-Header, Exchange 2003 handles the e-mail message as a message that requires journaling.

In this scenario, a duplicate journal report is created.

To work around this issue, you can set the MailboxServersSubmissionOverrideList attribute on the mailbox server. To do this, configure the attribute to point to the Exchange 2007 bridgehead server that is on the routing group connector to the Exchange 2003 part of the organization.

Exchange 2003 Journal Reports Remain in the Submission Queue (Fixed in Update Rollup 7)

When an Exchange 2003 message is journaled, the P2 header is the same as the original sender of the message. This behavior has changed in Exchange 2007. In Exchange 2007, the P2 header of the journal report is set to "Microsoft Exchange on behalf of (the original sender)". Additionally, Microsoft Exchange is considered a privileged sender. This status lets it bypass size limits and connector restrictions. However, because the Exchange 2003 journal report originates from the original message sender, the report does not enjoy the same privileges as those enjoyed by an Exchange 2007 journal report.

When a journal message is sent from Exchange 2003 to Exchange 2007, the message undergoes content conversion from Summary Transport Neutral Encapsulation Format (S-TNEF) to TNEF format. TNEF is Base64-encoded. It creates a message that is 33 percent larger than the original message. This behavior occurs for the journal message and not for the original message.

If the newly-encoded journal message exceeds the organizational message size limits, the following behavior occurs:

• The message arrives on the Exchange 2007 server, and is immediately queued for delivery.

• Because the message exceeds the organizational message size limits, it is not delivered.

• Because the message is a journal message, it does not generate an NDR.

• The e-mail message remains in the submission queue until it is manually removed by an administrator.

  Note

  This issue has been fixed in Exchange 2007 Update Rollup 7.

Missing Headers in the Original Message of an Exchange 2007 Journal Report

When a message originates from Exchange 2007 and is journaled to an Exchange 2003 mailbox, the original message that is attached to the journal message may be missing its P2 header information.

Because the headers are present in the journal report e-mail message, this issue may not be significant. Additionally, when you access the journaled message by using IMAP or POP3, the MIME headers are visible.

Microsoft Exchange Sender Lock Down

The following Exchange 2007 journaling white paper recommends that you restrict the journal mailbox to accept messages only from the privileged Microsoft Exchange sender:

White Paper: Exchange 2007 Transport Journaling

If you use this guidance in a mixed Exchange 2003 and Exchange 2007 organization, Exchange 2003 journal reports remain stuck in the submission queue. This behavior occurs because Exchange 2003 sets the P2 header of the journal report to be the same as that of the original sender.

General Exchange Journaling Considerations

The following issues apply to both pure Exchange 2007 environments and mixed Exchange 2003 and Exchange 2007 journaling environments.

Setting JournalingReportNDRTo Does Not Work (Fixed in Update Rollup 8)

Event ID 9213 may be logged from the MSExchangeTransport component. This event includes the following description.

A non-expirable message with the internal message ID <#######> could not be categorized. This message may be a journal report or other system message. The message will remain in the queue until administrative action is taken to resolve the error. Other messages may also have encountered this error. To further diagnose the error, use the Queue Viewer or the Mail Flow Troubleshooter.

This behavior occurs because Exchange 2007 SP1 adds the MUSTDELIVER property to a journal message.

When you use the Get-TransportConfig cmdlet to view the transport configuration object, the JournalingReportNDRTo property is set, as shown in the following example.

Get-TransportConfig

ClearCategories : True GenerateCopyOfDSNFor : {5.4.8, 5.4.6, 5.4.4, 5.2.4, 5.2.0, 5.1.4} InternalSMTPServers : {} JournalingReportNdrTo : Alt.Journalmbx@contoso.local

When the JournalingReportNdrTo attribute is populated by a valid e-mail address, Exchange adds the address to the return-path of a journal message. This lets Exchange send the NDR together with the journal report attached to the SMTP address if the original journal mailbox is unavailable. In versions of Exchange that are earlier than Exchange 2007 SP1 Update Rollup 8, this feature does not work. In these earlier versions of Exchange, the message remains in the submission queue. To resolve this issue, install the latest Update Rollup package for Exchange 2007.

Original Message is Not Attached to the Journal Report

When the limit for anonymous named properties is reached on an Exchange 2003 journal server, the journal report does not have the original message attached. In this scenario, a paperclip icon is visible in Outlook. However, there is no attached message.

To work around this issue, you can raise the named properties quota limit. If you reach the new maximum limit for named properties, you must create a new database and then move the journal mailbox to the new database. For more information about how to raise the named properties limit, see How to Configure Named Properties and Replica Identifier Quotas for Exchange 2007 Databases.

To reduce the probability of named property depletion issues, install the latest service pack or update rollup package for Exchange 2007.

Content Conversion Issues

Exchange 2007 journaling can journal directly to a contact. However, this functionality may create issues that are caused by content conversion. If a message fails content conversion from S-TNEF to plain text or HTML, the journal report also remains in the submission queue.

To work around this issue, you can set the JournalingReportNDRTo property on the TransportConfig object. Or, if the archival product handles TNEF, you can force the contact to use MAPI Rich Text format (set the mAPIRecipient attribute to True) to bypass content conversion.

Forwarding a copy of the journal report to an external SMTP address

You can forward a copy of the journal report to an external SMTP address. To do this, follow these steps:

1. Create an Active Directory contact to represent the external SMTP address.

2. Add the contact to the journal mailbox. For an Exchange 2007 mailbox, view the mailbox Properties dialog box. Click the Mail Flow Settings tab, and then click Delivery Options.

   Note

   If you use Outlook rules to forward journal messages, or if you modify properties in Active Directory for forward journal messages, the messages may remain in the submission queue.

Common Journaling Questions

Q: Why do I receive duplicate reports when an Exchange 2007 journaled user sends an e-mail message to a distribution group that has an Exchange 2007 expansion server set?

A: The journal agent fires on the OnSubmitted and OnRouted events. When the message traverses the first Hub Transport server (which is not the expansion server), the journal agent fires. This creates the first journal message. When the original message is forwarded to the expansion server for expansion, a second journal report is created. This behavior occurs because the distribution group expansion causes a change in the recipient list.

Q: If an Exchange 2003 or Exchange 2007 journaled user sends as a non-journaled user (by using the SendAs extended permission), why is there no journal report?

A: This is the expected behavior. The SendAs feature is an extended Active Directory permission. It is not an information store permission (such as SendOnBehalfOf). When you send as another user, you impersonate the other account. From an Exchange perspective, you are the other user. If the homeMDB attribute of the other user is not have set to a journaled store, or if the other user does not fall under any journal rule, the message is not journaled.

For More Information

For more information, see the following Exchange 2007 resources:

White Paper: Exchange 2007 Transport Journaling

https://technet.microsoft.com/en-us/library/bb738122.aspx

More Powerful Journaling in Exchange 2007

https://technet.microsoft.com/en-us/magazine/2006.12.journaling.aspx

Overview of journaling in Exchange 2007

https://msExchangeteam.com/archive/2007/06/22/444296.aspx

Understanding Journaling in a Mixed Exchange 2003 and Exchange 2010 Environment

https://technet.microsoft.com/en-us/library/aa997918.aspx