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.”-

https://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.

When referring to content conversion what I am talking about is the decision to send a message encapsulated in TNEF vs. HTML/Plaintext when sending outgoing messages.

Now I see there is some confusion as to when Exchange/Outlook will decide to send in TNEF as opposed to keeping a message in its native HTML and/or plain text format. It is the hope of this blog post to clear up some of that confusion.

First a bit of background-

In Exchange 2007/2010 (and Exchange 2003 as well) there are essentially three places where these content conversion choices can be influenced-

1. Remote Domains object (Internet message Formats in Exchange 2003)

2. Contact object

3. The outlook message properties

Here they are-

Remote Domain

Contact

Message properties (as viewed via MFCMAPI)

The above is also the order of precedence as well.

In other words all things being equal the settings on the Remote Domain will override the settings on the contact which will override the settings on the message property.

Now the above also happens to list the default values which are shown below again but via the shell this time-

Remote Domain

Contact

So based on the above we see that the default settings are set to, well, default.

What that means is they are not set so we need to go down one step further and see what the message properties are.

Now this is where some confusion lies. By default Outlook (all versions 2003 to 2010) will set the PR_SEND_RICH_INFO property of a message to TRUE if it can resolve an object in the address book. So if we are sending to a contact that is in the GAL (or OAB) and all the other settings are default the message will go out encapsulated in TNEF (with the corresponding Winmail.dat attachment).

To override this behavior we set the contact “UseMapiRichTextFormat” to NEVER or the remote domain “TNEFEnabled” to FALSE. Then we can block TNEF from leaving the org no matter what the client message properties are set to.

Now I need to mention that the above is a change from Exchange 2003 behavior. In Exchange 2003 when you create a mail contact in ADUC you will see that the mAPIRecipeint property (which corresponds to the UseMapiRichTextFormat in Exchange 2007/2010) is set to FALSE.

As you recall from the above discussion what this means is that outlook will be blocked from sending TNEF encapsulated messages to that particular contact.

So to summarize, in Exchange 2007/2010 when you create a contact in EMC/EMS the TNEF settings will be unset. In other words it will default to the client. As we know the client (outlook) will set the PR_SEND_RICH_INFO MAPI property to TRUE since it can resolve the contact in the address book.

With Exchange 2003 when you create a contact with ADUC the settings governing TNEF will be set to FALSE thus not allowing TNEF out of the org for that contact.

Note the above settings do not apply to one-off addresses. For these outlook will never set PR_SEND_RICH_INFO to TRUE and thus will always send HTML/Plaintext.

A Final Note About TNEF-

TNEF is used interchangeably a lot with Rich Text Format but they are NOT the same thing. And a lot of our own our documentation is guilty of this as well but they are really two separate concepts.

TNEF or transport neutral encapsulation format is a MIME complaint container for encapsulating messages in transport. This will be a multipart/mixed message with a Winmail.dat attachment.

These messages can be HTML or plain text or rich text. The point being that there does not have to be rich text format messages in this TNEF container. In fact if you get a TNEF parser and pop open a typical default outlook message where TNEF is allowed out of the ORG you will see no RTF within the Winmail.dat.

Rich Text Format is a MSFT proprietary message format that is used to display things like voting buttons etc. RTF needs to use TNEF as a MIME compliant transport.

So the take away is RTF needs to travel contained in TNEF but TNEF does not need to contain RTF.

Get it?

Thanks for reading.

Ok it’s not really ‘hidden’ but based on what it does I’m surprised it hasn’t gotten more publicity.

If you recall our journaling recommendations for mixed Exchange 2003 and Exchange 2007/2010 deployments we required you to put the journal recipient mailbox on an Exchange 2003 database.

You can read about that here- https://blogs.technet.com/b/exchange/archive/2009/06/01/3407615.aspx

From the section ‘Location of Journaling Mailbox’ I explained why the journal mailbox needs to be on a 2003 server.

Well starting with Exchange 2007 sp3 RU1 and Exchange 2010 sp1 all that has changed!

If you run a Get-TransportConfig from an Exchange server at one of those levels you will see a new property called ‘LegacyJournalingMigrationEnabled’.

By default this is set to ‘False’.

Set it to ‘$True’ and you will now be able to locate the journal recipient mailbox on an Exchange 2007 sp3 RU1/Exchange 2010 sp1 database in an org that has Exchange 2003 servers.

There is no restart required as transport will pick the change up as soon as the first message passes through.

Note that while the journal report will be in the new Exchange 2007/2010 format it will NOT have the extended fields.

What this means is if a journaled sender BCCs a recipient the report will not indicate that but rather just show the recipient listed in the report.

Below is an example of a journal report of an Exchange 2003 sender who sent a message with Harpo.Marx on the TO: field and Zeppo.Marx on the BCC:-

You can read more about Journal reports here-

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

Happy journaling!

You may be familiar with the Test-Message cmdlet. If not check out this link here-

https://technet.microsoft.com/en-us/library/dd298101(EXCHG.140).aspx

Basically this cmdlet is useful for testing inbox rules. However rather than talking about the above link let’s discuss the newer and improved Test-Message that ships with SP1 and show some cool uses for this unsung little cmdlet.

First off we added some new switches which for some reason have not been documented on TechNet yet.

So without further ado here are all the switches for the SP1 version-

Parameter	Description
Recipients	The Recipients parameter specifies the list of e-mail addresses to be used as recipients for the test message if an .eml or .msg file isn't specified.
Confirm	The Confirm switch causes the command to pause processing and requires you to acknowledge what the command will do before processing continues. You don't have to specify a value with the Confirm switch.
DeliverMessage	The DeliverMessage switch specifies that the message should be delivered to its final destination. If you don't specify this switch, the message that's resubmitted isn't delivered to its recipients. Only troubleshooting data is generated and sent to the specified recipient.
MessageFileData	The MessageFileData parameter specifies file data retrieved from an .eml OR .msg file using the Get-Content cmdlet.
Sender	The Sender parameter specifies the SMTP address to be used as the message sender for the test message if an .eml or .msg file isn't specified.
SendReportTo	The SendReportTo parameter specifies the e-mail address to which the final report is sent.
Arbitration	This switch retrieves a report for all messages in the arbitration mailbox used for moderation. If this switch is used you then specify the arbitration mailbox email with the -recipients parameter
InboxRules	This switch retrieves a report for all rules within the mailbox that you specify with –recipients parameter. It will provide useful diagnostic info for which rules fired or did not.
WhatIf	The WhatIf switch instructs the command to simulate the actions that it would take on the object. By using the WhatIf switch, you can view what changes would occur without having to apply any of those changes. You don't have to specify a value with the WhatIf switch.

If you recall the RTM version you will notice 2 new switches have been added-

-Arbitration and –InboxRules.

The –Arbitration switch creates diagnostic info on the initiation messages in the arbitration mailbox and their various statuses. As you may recall the arbitration mailbox is used for the new moderated messaging framework introduced in Exchange 2010.

To run these tests you would run the following one liner-

For –Recipients you will need to specify the arbitration mailbox. To get this value just run ‘Get-Mailbox –Arbitration |FL Name’. You should get an output that is similar to the one below-

Name : SystemMailbox{1f05a927-2941-4ce4-8c27-852e25e0abc8}

Name : SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}

Name : FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042

The above are the Arbitration, Discovery and Federated mailboxes respectively.

The last two will always have the same value but for the arbitration mailbox the last 4 sets of guids will be unique to your environment. More can be found here-https://technet.microsoft.com/en-us/library/bb201680.aspx

In summary the previous one liner will send a report to the mailbox that you specified with –SendReportTo as such-

The fields above are pretty self-explanatory but I will elaborate on some below-

‘Initiation Message’ is the unique ID that is assigned to the arbitration message.

‘Moderated Recipient Address’ is the name of the moderated account (in the above example it is a DL called Expand1).

‘Moderators’ is a list of moderators.

The ‘Moderators (total; not delivered; away)’ tell us how many moderators there were and how many generated NDRs (not delivered) or OOF messages (away). In the above example we have 1 moderator and no NDRs or OOF messages sent from the moderator address.

The ‘Decision maker’ field displays which moderator ultimately approved/disapproved the message with the corresponding status and time in addition to the time the moderation request message will be expired.

Finally the attached ‘formattedDetails.txt’ is just the raw data that you see in the report.

The –InboxRules switch creates a similar report but one evaluating which inbox rules did or did not fire.

You would run it like so-

The report generated will look like this-

First we see that the hidden Junk mail rule skipped this message due to the fact that it is an internal email and thus automatically will get an SCL of -1.

Then we a rule called ‘zeppo marx’ has evaluated to true. This rule moves all messages coming from zeppo marx to a folder called ‘Personal’-

You will also see if the mailbox has OOF auto replies enabled as well-

Attached to the report you will also find ‘Mailbox-Rules.xml’ which is a dump of all the rules in that particular mailbox in xml format as well as ‘Automatic- Reply-History.xml’ which is a dump of all the recipients that had an OOF message fire.

Now in addition to the above one of the other cool new features of the SP1 test-Message cmdlet is the ability to send a native MAPI .MSG message in addition to .EML.-

In the above we sent a ‘test.msg’ pre-created message to zmarx@wingtiptoys

Ok that’s all for now.

Thanks for reading.

So this is a quick post but worth mentioning as these cases seem to crop up every once in a while.

The error in the title usually occurs after creating a second receive connector dedicated for an app relay or some other anonymous type access.

So lets walk through the steps that usually get us here.-

You create a second connector for relay aptly titled “app relay” here-

Then check off anonymous since our app is not authenticating to Exchange (note since we want this app to not only submit mail to this connector but also relay off it to other destinations we would need to grant the anonymous security principle the ms-Exch-SMTP-Accept-Any-Recipient extended right on this connector as well. Another less preferred method is to select Externally Secured as a Authentication type but both get us into the same issue.).

Finally we add the remote IP range for our app.

Now it is the last two steps that get us into trouble.  Exchange needs to have Exchange Server Authentication selected in order to send internal intra org mail flow. However for our relay to work we don’t need this set nor is it by default.

However the real aspect to remember here is when receiving email from a remote host Exchange will always use the more SPECIFICALLY scoped receive connector based on the remote IP range.

So all things being equal if we have two receive connectors and one has an remote IP range as such-

And the other is-

And we receive an incoming SMTP connection from a host with say an IP of 192.168.62.10 we will ALWAYS us the second connector. This is regardless of the authentication type or permissions groups defined on the connector itself

Now if our internal Exchange servers happen to fall within the 192.168.62.0 subnet then we will use the App Relay receive connector and since it does not have Exchange Servers defined as a permissions group and/or Exchange Server Authentication selected we get the error that is the title of this post.

The take away here is when creating a dedicated receive connector for app relay or some other purpose ensure that the remote IP range defined on the connector does not include any internal Exchange servers.

Blog I penned on how to block read receipts (or try) in Exchange 2007 and 2010

https://msexchangeteam.com/archive/2011/02/23/458262.aspx