Messaging Records Management (MRM 1.0) has a feature which enables you to “journal” a message that falls under a MRM policy.

Here is a screenshot of it from Exchange 2007 GUI

And while MRM 1.0 has been deprecated in Exchange 2010 and later for Retention Policies (MRM 2.0) you can still set it in the shell in that version here-

The key to note here (and purpose of this post) is that MRM journaling is different from “standard” transport envelope journaling (the kind you create a journal rule for or enable at the per-MDB level).

You can read more about transport journaling here.

In fact it’s more accurate to refer to MRM 1.0 “journaling” with its real name- AutoCopy, since this is not meant to be an actual compliance solution.

So here are the differences to be aware of-

Transport journaling is handled by the hidden (in Exchange 2010) journal agent on the hub servers.

MRM AutoCopy is handled by the Managed Folder Assistant which is a mailbox assistant on the mailbox server.

The sender/recipient addresses in an MRM AutoCopy report are in Legacy Exchange DN format while a transport journal report is SMTP.

MRM AutoCopy reports do not show results of DL expansion. Transport journal reports do.

MRM AutoCopy reports do not show BCC recipients. Transport journal reports do.

Both Transport Journaling and MRM 1.0 AutoCopy will set the X-MS-Journal-Report header.

Finally and perhaps most importantly to note- Ii you enable a mailbox for Transport envelope journaling (journal rule or per-MDB) AND that mailbox also has a MRM 1.0 AutoCopy policy applied “duplicate” reports will be generated.

I write “duplicate” in quotes since as we have read the two are very different.

See below-

Example of transport journal report-

Example of MRM 1.0 journal report-

In short Exchange Transport Journaling is a robust compliance feature.

MRM 1.0 AutoCopy is not meant to be a replacement for true Journaling and its successor and ultimate replacement Retention Policies (MRM 2.0), do not have the ability to AutoCopy.

In fact in Exchange 2013 there is no more MRM 1.0 so the AutoCopy feature has been completely removed from that version of the product.

Some Background on Shared Namespaces with Exchange 2003 and 2010.

So the nature of shared namespace has changed between exchange 2003 and exchange 2007/2010.

In exchange 2003 to share a name space like “TheHongkonCavaliers.mail.onmicrosoft.com” we need to go the recipient policy and select that address and uncheck “This Exchange Organization is responsible for all mail delivery to this address”-

After that all we need is a SMTP connector to that name space.

In exchange 2007/2010 we can be authoritative for a name space and still share it with another system as long as we have an object in the directory with that address (i.e. a contact with a target address pointing to the remote shared name space).

So this-

Works if this is present tin AD-

ISSUE-

When the HCW runs it creates an authoritative accepted domain for the routing address (TENANT.mail.onmicrosoft.com)-

Exchange 2003 version-

It also upgrades the email address policy this address is a member of to OPATH-

Which in turn makes it uneditable in Exchange 2003-

So when we send an email from an Exchange 2003 mailbox to a migrated cloud mailbox we get this-

WORKAROUND-

Since the Recipient Policy has been upgraded to OPATH we cannot make any changes on Exchange 2003 to make it unauthoritative so we have to go to the Exchange 2010 side and make the accepted domain for the routing name space Internal Relay-

So you may have seen DEFER or FAIL eventids in your tracking logs and wondered why they are there.

If we look on our documentation on TechNet here we see-

Event name	Description
DEFER	Message delivery was delayed.
FAIL	Message delivery failed.

Pretty self-explanatory, right?

Now sometimes you may see these eventids even though a message was not deferred/delayed or failed delivery.

Well there is another reason that would cause these events logged.

The first event id we will talk about is the DEFER.

When we run Get-MessageTrackingLog we see a DEFER eventid with a source of AGENT below.

Expanded below we see the SourceContext is Transport Rule Agent

So let’s go look at our transport rules-

Here we see we have a transport rule that adds a recipient to the TO: field.

Now when we have a transport rule that adds or removes a recipient from a message header we will log a DEFER eventid in message tracking logs. This is known as a “zero defer” since the message is not really deferred but just pushed back to the submission stage of categorization so we can re-resolve the new recipient. In other words the event is more “cosmetic” since there is no delay we just need to re-categorize the message in the transport pipeline with the new recipient added/removed.

As we can see below the message was not deferred at all-

Now what about FAIL eventid?

As we can see in the above message tracking log we log a FAIL eventid from SourceContext Transport Rule Agent. So let’s go back to our rules and see what they are doing-

Here we have a redirect rule. Now as opposed to adding/removing recipients a redirect rule silently drops the original recipient and redirects a message to the added recipient. This will cause us to log a FAIL eventid since we actually failed in delivering to the original recipient (due to redirection) and a DEFER since we are adding a new recipient and putting the message back to the submission portion of the transport pipeline.

As we can see the message was successfully delivered.

Hope this helped clear up some confusion on these two eventids.

Until next time.

I’d say good read but I wrote it and that would be  just wrong.

So instead let me just say “one more from the shameless self-promotion dept.”-

http://blogs.technet.com/b/exchange/archive/2011/07/08/accepted-domains-safe-senders-list-and-you.aspx

You may have noticed a discrepancy between the output of Get-AdPermission in Exchange 2007 and Exchange 2010. Specifically the differences are in the way extended rights are displayed (or rather not displayed in the case of 2010).

Below is an example of the output from Get-ReceiveConnector WINGTIP-E2K10\anon |Get-ADPermission -User 'NT AUTHORITY\ANONYMOUS LOGON' |fl from Exchange 2010-

Same cmdlet run from Exchange 2007

Note that in the Exchange 2007 output we list the actual extended rights the security principal has been granted (i.e. ms-Exch-SMTP-Accept-Any-Recipient, etc.) whereas in the Exchange 2010 output we just show {ExtendedRight}.

This ‘quirk’ is due to a missing script block in ‘exchange.format.ps1xml’ file in the bin directory.

This file is loaded every time you click the Exchange PS shortcut and is used to show the default output for a specific object type as well as which properties to display.

To see all the extended rights in Exchange 2010 you have to run the same cmdlet but with the “*” wildcard.

Below you can now see all the extended rights that Exchange 2007 showed-

Till next time.

Thanks for reading.