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-

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.

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- http://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-

http://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-

http://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-

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

Or more from the shameless self-promotion dept.-

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

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

Whether read receipts, delivery receipts, moderation requests/acceptances, OOF messages, and admin audit messages are journaled depends are certain factors.

These factors are

1. Which database is being journaled.

2. Recipient or sender being journaled.

3. Which version of exchange (2003 or 2007/2010).

4.  Which type of report- DR,OOF,RR,etc.

Below is a guideline on what to expect from a journaling perspective-

Read Receipts and OOF messages-

These messages are generated by the recipient mailbox (the mailbox which is being requested for a read receipts or the mailbox setup for OOF).

Thus as can be expected if the recipient and/or sender is journaled then we will have a journal report for these types of messages.

 Delivery Receipts/Reports-

Delivery receipts are generated by the receiving server and depending on the version of exchange will come from the postmaster address or the special Microsoft Exchange Recipient account.

In Exchange 2003 the account used to install Exchange (typically the administrator) will be stamped with a secondary proxy of “postmaster@authoritativedomain”. It is this account that is used to send delivery receipts. Thus if the sender (requestor) of a delivery receipt request is not journaled and the administrator account is also on a non-journaled DB, a journal report for a delivery receipt will not be created. Either the sender or the administrator account (postmaster) must be enabled for journaling.

 In Exchange 2007/2010 this has changed as delivery receipts come from the special Microsoft Exchange Recipient account. This is a special account with no mailbox and as such cannot be journaled. Thus if the sender of a delivery receipt request is not journaled a journal report of a delivery receipt will not be present on Exchange 2007/2010.

On how to create a maibox for this special account see this article-http://technet.microsoft.com/en-us/library/bb430759.aspx

Moderation Requests/Acceptances-

Moderation messages are special messages sent to a designated group moderator for approval to send messages to that group. This is a feature specific to Exchange 2010.

The initial moderation request to send to a DL is generated by the special Arbitration mailbox and sent to the moderator.

Thus if the Arbitration mailbox and moderator are not a journaled database a journal report will not be generated. At least one of the above two need to be journaled for a journal record of the initial request.

A moderation approval message is sent from the moderator to the Arbitration mailbox so the above applies for these types of message as well.

You can read more about moderation here-

http://technet.microsoft.com/en-us/library/dd297936.aspx

Admin Audit Messages-

Admin Audit mailbox is used for auditing cmdlets in Exchange 2010.

In the RTM version of 2010 you can specify an audit mailbox. In sp1 you cannot and the arbritation mailbox is used. This cannot be changed.

Either version admin audit messages are NEVER journaled regardless of the account being audited.

This is “by design”.

You can read more about admin auditing here-

RTM- http://technet.microsoft.com/en-us/library/dd335052(EXCHG.140).aspx

SP1- http://technet.microsoft.com/en-us/library/dd335052.aspx

Finally while we are on the subject of what is journaled and what is not let me pause here to mention that journaling to a DL (i.e. using a distribution group as a journal recipient) is not supported for Exchange 2003.

A while back I wrote a kb on the topic which you can read here- http://support.microsoft.com/kb/2458386

However with the move of store driver and content conversion from store to transport in Exchange 2007/2010 this is now possible in those versions of Exchange.

Hope this was helpful to you compliance minded readers.

Till next time.

So you may have an issue where you want to extract many (>1000) messages from your Exchange 2010 queue(s).

This could be because you want to play them in later via the replay folder after some outage or other scenario that may have caused transport to have issues (yes even in Exchange 2010 we sometimes have issues with mail flow, rare as they may be). You may not want to just mount the mail.que and have all these emails start being delivered right after some outage. It might be a better idea to stagger them in rather than let the flood gates open.

Either way you Bing “Export-Message” and find your way here- http://technet.microsoft.com/en-us/library/aa997214.aspx.

You soon realize that the example offered there does not seem to entirely work as expected in your environment (i.e. no messages get exported out to eml’s).

Well we are getting the TechNet article fixed but until then let me show you how to get all these messages out to eml files for suitable replay later.

First we will need to suspend the queue you would like to export the messages out from by issuing a Suspend-Queue –Id <Name_of_Queue> (you won’t need to suspend the poison queue as it is already in a suspended state).

As a side note I’d like to say here that if your messages are in the submission queue AND you are running exchange 2010 or exchange 2007 sp3 you are in luck. We finally allow you to export/remove/suspend messages in this queue. This was something that was impossible in earlier versions of Exchange 2007.

Ok back to our queue which should now be suspended.

Next we want to suspend the messages in this queue. Since there are more than 1000 we need to issue a Get-Queue –Id <Name_of_Suspended_Queue |Get-Message -ResultSize Unlimited |Suspend-Message.

We want the –ResultSize Unlimited since by default we will only retrieve the first 1000 messages.

Now this is where our article forgets to mention a few things.

First off we want to get all our messages from the queue we just suspended and put that result into an array like here-

$array = @(Get-Message -Queue unreachable -ResultSize unlimited)

Now we want to loop through that and send it to Export-Message and then send it to AssembleMessage (since we are on Exchange 2010 and using remote PowerShell now we need to pipe it to the AssembleMessage function because we don’t have direct access to the file system).

Also Export-Message wants you to declare the file name you are exporting the message to. This works for a single message but obviously for anything more than that it poses a problem. So we set a counter and increment it by 1 for each message and use that number as the file name.

Your next one liner will look like this-

$array | ForEach-Object {$i++;Export-Message $_.Identity | AssembleMessage -Path ("c:\exportfolder\"+ $i +".eml")}

So in the end you will get a bunch of .eml files in c:\exportfolder\ with names like 1.eml, 2.eml, 3.eml, and so on and so forth that you can then put into the Replay folder of your hub server when you are ready to let loose the backed up mail.