Exchange Transport Rules Corrupt On Installing New Exchange Server Version

Posted on Leave a commentPosted in 2013, 2016, Exchange Server, ndr, rules, transport

When you install Exchange Server into an existing Exchange organization, your existing configuration typically remains intact and associated with the previous servers and some configuration, that is global in nature, also works across both versions.

I can across a scenario where this does not work the other day. The scenario was the installation of Exchange Server 2016 CU12 as a brand new Exchange installation into an existing Exchange Server 2013 deployment. This AD forest has previously seen Exchange 2003 and Exchange 2010, but these server versions are now long gone.

The issue was that the transport rules all appeared in Exchange Server 2016 as disabled, but where all enabled in Exchange Server 2013. The Exchange Admin Center could not open the rules and an error was displayed at the bottom which when expanded showed that the RejectEnhancedStatus was invalid, along with lots of the settings of the rule – they all are missing in the right-hand side of the EAC view.

image

RejectEnhancedStatus is the error code returned when you write a rule that rejects messages with notification. In Exchange Server 2016 only 5.7.1 and 5.7.900 through 5.7.999 are allowed for the RejectMessageEnhancedStatusCode parameter, but the Exchange Server 2013 deployment at CU21 does not block the creation of other status codes. Therefore, if you have transport rules with codes other than the ones allowed in Exchange Server 2016 you get corrupted transport rules:

image

So – how to fix. Well you cannot set the RejectMessageEnhancedStatusCode to a new value in Exchange Server 2016, because this server says you also need to set the RejectMessageReasonText value as that is also an empty string and also shows that a lot of the rule properties are also empty. So you need to fix it in the older version of Exchange.

In Exchange Server 2016 running Get-TransportRule “name of rule” results in:

WARNING: The object transport rule name has been corrupted or isn’t compatible with Microsoft support requirements, and it’s in an inconsistent state. The following validation errors happened:

WARNING: Rule ‘transport rule name’ is corrupt. The specified enhanced status code ‘5.7.x’ is invalid or isn’t compatible with Transport Rule policy requirement. Valid values are 5.7.1, or a value in the range between 5.7.900 and 5.7.999. The code must contain no spaces or other characters.

Parameter name: RejectEnhancedStatus

But running the same on Exchange Server 2013 is successful:

image

Run the following Exchange Management Shell cmdlets in Exchange 2013:

Get-TransportRule “name of rule” | FL Name,RejectMessage*

This will return the configuration of the current rule regarding the RejectMessageEnhancedStatusCode (which is wrong for 2016) and the RejectMessageReasonText.

Then run the cmdlet to change the code to a supported value as shown:

image

Set-TransportRule “name of rule” -RejectMessageEnhancedStatusCode 5.7.1 –RejectMessageReasonText “copy the reason from the output of the above cmdlet”

You need to set the code to 5.7.1 and provide the text again, or Exchange will replace the text with its own text or you need to create a New-SystemMessage for the status codes .900 and above and then use that code in the transport rule.

Once the change has been made on Exchange Server 2013, and this change is written to the configuration partition of Active Directory, that change will replicate around AD. Once the change reaches the DC used by Exchange Server 2016 the error will disappear and Exchange Control Panel can be refreshed to remove the error.

image or image

Journal Alternative Mailbox and No Inbox Rules

Posted on 1 CommentPosted in 2013, compliance, exchange, exchange online, journal, journaling, mcm, mcsm, ndr, Office 365, rules, transport, transport agent

In the event of your journal mailbox going offline, any journal reports destined for these mailboxes will queue. After two days (though this time is the expiry time for messages in your Exchange organization, so may be different) the message will expire and an NDR sent to the sender of the journal report. The problem is that the journal report was not sent by anyone – the From address is <>. So no NDR is generated and the journal report is lost.

There is the JournalReportNdrTo property of TransportConfig that allows you to set who will receive these NDR’s.

Set-TransportConfig -JournalingReportNdrTo journalndr@mcmemail.co.uk

Once this value is set this mailbox should be monitored occasionally and any NDR’s opened and the containing message (the journal report) resent so that it goes back to the (now working) journal mailbox.

In Exchange 2013 this NDR mailbox is never the subject of journaling nor do any inbox rules run against this mailbox – even if this mailbox is mentioned in a journal rule of if the mailbox has inbox rules associated with it. When you set this value in your Exchange 2013 organization you get the following warning:

WARNING: Any mail to JournalingReportNdrTo mailbox will not be journaled and it will not honor transport and mailbox rules settings. It is recommended to create a dedicated mailbox for JournalingReportNdrTo setting or set it to an external address.

Or if you set it in Exchange Control Panel then the following popup appears:

image

The warning also mentions that Transport Rules do not fire for this mailbox, but that is not what I have seen – though it might be that specific transport rules do not get actioned, but others do. Inbox rules and Journal Rules are not processed.

Therefore it is very important that you do not use a standard mailbox as the target for JournalReportNdrTo, as this mailbox will have all its outbound emails missing from any journal it should be stored it (and this would be a compliance issue) and the user will get bothered that their email rules in Outlook are not working.

The problem is that this is not the case in Exchange 2010, so if you have set the JournalReportNdrTo property in the past on a mailbox, and then migrated that mailbox to 2013 you will not be warned, but you will find that upon migration to 2013 your inbox rules stop working and if you look in the journal mailbox you will not find messages send from this mailbox. Therefore create a mailbox specifically for journal NDR’s before you migrate to Exchange 2013.