Are you using Journaling in a mixed Exchange 2007 and Exchange 2003 environment? If yes, here are some mixed environment considerations you should be aware of.
A Brief Overview of Journaling
Exchange 2003 shipped with 3 different types of journaling:
- Message-only Journaling: Sends just a copy of the email to the journal mailbox with all the P2 header information. This does not include BCC information, or members of a distribution group after the group is expanded.
- BCC Journaling: Similar to message-only journaling, but captures BCC information as well.
- Envelope Journaling: Captures all envelope (P1) header info, including BCC recipients, and expanded distribution group membership. A journal report is sent to the journal mailbox with the original message attached.
Regardless of the journaling method used, you would need to enable an entire mailbox database for journaling, resulting in mail to and from all mailboxes on the database being journaled.
Exchange 2003 servers transmit journaling metadata between them in a special binary large object (BLOB) using the XEXCH50 extension during an SMTP conversation.
Journaling in Exchange 2007
In Exchange 2007, message-only journaling and Bcc journaling are no longer supported because they do not capture all the information necessary in today’s compliance-focused environments. The only option is envelope journaling. Journaling comes in 2 flavors:
- Standard Journaling: Also known as per-Mailbox Database (per-MDB) journaling.
- Premium Journaling: Allows you to use Journal rules for more granular journaling.
Both Standard and Premium Journaling are performed in transport by the Journal agent. In deployments where you use 3rd-party archival solutions, you can journal directly to an external (to the Exchange organization) SMTP address using a Contact. This allows you to deliver journal reports directly to the 3rd-party archival solution, rather than having to store them in an Exchange mailbox first and setting up Outlook rules to forward them.
The EXCH50 SMTP extension has also been deprecated in favor of X-headers.
When a message is journaled, the X-Ms-Exchange-Organization-Processed-By-Journaling header is added to it to avoid duplication of journal reports by other Hub Transport servers which may handle the message. Journal reports are stamped with the X-Ms-Exchange-Organization-Journal-Report header, to identify them as such, thus allowing them to bypass message size limits.
However, these improvements come with some special considerations for such environments.
Location of Journaling Mailbox
In mixed environments, you must locate the journaling mailbox (the mailbox to which Journal reports are delivered, specified in the msExchMessageJournalRecipient attribute of the mailbox database) on an Exchange 2003 server. If the journaling mailbox is located on an Exchange 2007 server, email sent from Exchange 2003 users will not contain the journal report but rather only a copy of the original email message.
Why does this happen? When the sending Exchange 2003 server sees that either the recipient or the sender(s) has the journal recipient attribute populated for their mailbox database, it creates a pre-journal report. This is really just the beginning of the journal report (the metadata if you will). The actual creation of the journal report occurs on the Exchange server with the journal mailbox.
Due to the differences in the location of content conversion drivers in Exchange 2003 and Exchange 2007 (recall we moved the store driver to transport in exchange 2007 and due our conversion there or in Categorizer), Exchange 2007 Hub Transport expects a fully formed journal report. When we see the Exch50 blob with the exjournaldata info, we know the message has already been journaled and send it off to the journal mailbox as is.
To avoid this issue we recommend customers place their journal recipient mailbox on an Exchange 2003 server or utilize Journal rules.
Duplication of Journal Reports
If an Exchange 2007 mailbox sends an email to an Exchange 2003 mailbox and that email traverses 2 or more Hub Transport servers to get to the Exchange 2003 routing group, a duplicate journal report will be generated.
Recall from earlier that Exchange 2003 reads journaling information about an email such as journal recipient location from the Exch50 blob. Although in Exchange 2007 we no longer use this blob, we still create it for backward compatibility with Exchange 2003.
So consider when an email is submitted to a Hub Transport server, the journal agent fires and creates the journal report. However, since this HT sees that there is another Exchange 2007 HT in the routing path, it does not create the Exch50 blob. When the last hop HT gets the email, it sees that the next hop is to the legacy Exchange 2003 routing group, and creates the Exch50 blob. However, since the email has already been journaled (as evidenced by the x-header), the Exch50 blob does not contain the journal recipient list for Exchange 2003 to process, resulting in another journal report being created by the Exchange 2003 server.
If due to space considerations, duplicate journal reports are not desirable, you can use the –SubmissionServerOverrideList of the Set-MailboxServer cmdlet to force your mailbox server to use the Exchange 2007 server specified as the Bridgehead on the Routing Group Connector.
Journal Reports Stuck in Submission Queue
Another issue we have been seeing in mixed environments is journal reports sent from Exchange 2003 stuck in the submission queue on Exchange 2007 Hub Transport servers. This issue is currently bugged and there should be a fix out for it soon.
The reason? During S/TNEF to Base64 conversion, the size of a journal report message increases by the standard 33%. This may cause the journal report to exceed your organization’s message size limits. However, since this is a journal report, we will never NDR it and it will stay in the submission queue.
This is also a result of the different way in which Exchange 2003 sends out the journal report. In Exchange 2003, the journal report P2 FROM: header has the address of the original sender of the email, whereas in Exchange 2007 the journal report originates from “Microsoft Exchange“, which is a privileged sender and thus bypasses message size limits.
Duplication of Journal reports when an expansion server is specified
This is not really a mixed mode journaling issue, but rather something to be aware of and a good example of how the Journaling agent fires in Exchange 2007.
You create an Exchange2007 journal rule for a distribution group which has an Exchange 2007 Hub Transport server configured as the expansion server. When a user who is a member of the distribution group sends a message, it gets picked up by the submission service on a Hub Transport server in the same AD site as the Mailbox server. The Journaling agent on that server sees that the sender is a member of a journaled distribution group, and fires, creating a journal report. It then sees that the distribution group has another Hub Transport server configured as the expansion server, and forwards the message to that server for the distribution group to be expanded. The expansion server expands the distribution group, and the Journal agent fires again, creating another journal report for that message.
This is by design.
The Journaling agent fires on the OnSubmitted and OnRouted events in the transport pipeline. This ensures that if a transport agent or some other event (such as a distribution group expansion) modifies the envelope headers, these changes are captured in the journal report as well, maintaining compliance.
In conclusion, the changes in Journaling in Exchange 2007 bring with it many advantages over its predecessor, but like any move forward, co-existing with the past brings with it some special considerations.
Microsoft
