locked
Transport rules do not execute when passing through multiple Exchange organisations RRS feed

  • Question

  • I'm seeing an issue where transport rules do not execute for certain emails.

    The setup has an Exchange 2016 in a hybrid relationship with Office 365, with a legacy Exchange 2007 system.  All Internet bound emails from the Exchange 2007 system goes out via the Exchange 2016 servers, from there to Edge Transport servers and on to Office 365.

    I've created a number of transport rules using a variety of criteria, including a rule that applies to all emails without any filtering at all.  An email that originates from the 2016 system has the rules applied without error.  However it would appear that emails originating from a service that uses Exchange 2007 to send its emails, completely bypass the 2016 based transport rules!

    I suspect that some form of header is being set on the 2007 system that the 2016 system takes as - transport rules have already been run, don't run them again.  But I'm unclear what that header might be, or how I can prevent this behaviour - or what the cause is, if my guess is wrong!

    Thanks!

    Mike

    Thursday, December 6, 2018 10:08 AM

All replies

  • Do you mean that Exchange 2016 is running with Exchange 2007 in coexistence and office 365?

    If yes, then it is not supported. Exchange 2016 doesn't support coexistence with Exchange 2007 or earlier version.

    Thursday, December 6, 2018 11:33 AM
  • No - there is a separate Exchange 2007 system in a separate forest.  They are totally independent systems, other than the 2016 system acts as the gateway for Internet email, and they have connectors between the two systems. I'm aware that 2007 is well out of support, but the issue of 2016 not firing transport rules is where the issue sits.  It is just understanding what can cause that behaviour....
    Thursday, December 6, 2018 11:44 AM
  • You can do a message tracking on Both Exchange and check for Event data in tracking logs. Event data can be helpful to rule id and what action was taken. After that you can check for rule id by running get-transportrule -identity and rule ID.

    https://practical365.com/exchange-server/tell-transport-rule-applied-email-message/

    If you want to check headers then you can enable pipeline tracing and check for headers for particular email.

    https://docs.microsoft.com/en-us/exchange/configure-pipeline-tracing-exchange-2013-help

    Thursday, December 6, 2018 11:54 AM
  • Thanks - when I did a message trace there didn't appear to be any rule hits at all.  I'll try and get a comparison to an email that did hit the transport rules for comparison.

    The transport pipeline tracing looks interesting to pick up the headers.  Is there anything that documents all the Exchange headers, especially internal headers?

    Thursday, December 6, 2018 12:06 PM
  • You can see basic headers information here:-

    https://support.office.com/en-us/article/view-internet-message-headers-cd039382-dc6e-4264-ac74-c048563d212c

    But headers may have additional values based on agents you are using in transport pipeline.

    For e.g. Spam, rules.

    Thursday, December 6, 2018 12:12 PM
  • Thanks - sadly these are all pretty much standard headers.  I'm really interested in headers used by Exchange for internal functions.  Specifically what makes transport rules fire only once, and stops them firing on every transport server they pass through.... as I suspect that could be where the issue sits.

    Thursday, December 6, 2018 12:20 PM
  • Yeah. Event data field in tracking logs can tell that.

    Is it possible to tell what criteria you are using on transport rules?

    Thursday, December 6, 2018 12:27 PM
  • I have rules configure with a variety of options, subject matching, sending matching, I've even created a rule set to apply to all messages, but even that doesn't get applied to these emails.

    The specific rule I created was apply to all messages, with the action to set the header.  I then had a rule in O365 to trap emails based upon the lack of the header.  It only trapped these problematic emails.

    I also created a rule to match the specific subject.  When a user of the 2016 system sends an email I get a copy of their email.  When the 2007 system originated email is sent the email never gets copied to me, however the email does get trapped by a similar rule in O365.

    This is why I'm pretty certain that this is some header being set in the 2007 system that is preventing the 2016 transport rules from executing.

    Thursday, December 6, 2018 12:43 PM
  • Hi,

    Are there any rules applied on Exchange 2007 may cause this issue?
    What about sending emails from Exchange 2007 to Exchange 2016? Can rules on Exchange 2016 be applied?

    Try to run the following command to check rules on all servers:

    Get-TransportRule|fl priority,name,description

    Could you provide more rules setting information or any screenshots about running results of the command above? 
    We need more details to make sure what factors may cause the issue. Please don’t forget to cover your personal information.

    Additionally, since Exchange 2007 is not supported for a long time, it’s hard to test and there may be some unpredictable vulnerabilities and problems.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, December 7, 2018 10:31 AM
  • I don't have any access to the legacy system unfortunately.  It is run by a different part of the organisation and is segmented off.  All I can do is monitor for emails coming from that legacy platform.  I appreciate that this isn't ideal, but it is all I have to work with.

    I'll see if I can find a way to get emails sent from the legacy system to 2016 users and see if the transport rules fire for them.

    Again - given that this is specifically the 2016 system not firing the rules, in many respects whatever the 2007 system does isn't relevant.  There shouldn't be any action an external system could take that bypasses all the rules of Exchange 2016! 

    Unfortunately I've got very little access to the systems at the moment (working on a different customer account for the next week or so).  Once I'm back I'll try and do further testing.

    Really what I hoped for is that someone would know the specific scenarios around how Exchange decides if the transport rules should execute or not... and any associated message headers that may be causing the problem... as I can't think of another reason that Exchange 2016 wouldn't fire its transport rules on an email it is transporting.

    Friday, December 7, 2018 11:54 AM
  • I don't have any access to the legacy system unfortunately.  It is run by a different part of the organisation and is segmented off.  All I can do is monitor for emails coming from that legacy platform.  I appreciate that this isn't ideal, but it is all I have to work with.

    I'll see if I can find a way to get emails sent from the legacy system to 2016 users and see if the transport rules fire for them.

    Again - given that this is specifically the 2016 system not firing the rules, in many respects whatever the 2007 system does isn't relevant.  There shouldn't be any action an external system could take that bypasses all the rules of Exchange 2016! 

    Unfortunately I've got very little access to the systems at the moment (working on a different customer account for the next week or so).  Once I'm back I'll try and do further testing.

    Really what I hoped for is that someone would know the specific scenarios around how Exchange decides if the transport rules should execute or not... and any associated message headers that may be causing the problem... as I can't think of another reason that Exchange 2016 wouldn't fire its transport rules on an email it is transporting.

    so the 2007 sourced messages just relay off the 2016 servers? Not sure I would expect transport rules to be applied in that scenario since the Front End transport is stateless.

    Friday, December 7, 2018 12:41 PM
  • so the 2007 sourced messages just relay off the 2016 servers? Not sure I would expect transport rules to be applied in that scenario since the Front End transport is stateless.

    Yes 2016 is purely used as a relay.  Surely any emails passing through the Exchange 2016 platform would have the transport rules applied?  There is certainly nothing that would lead me to believe that emails must originate from Outlook connections to have transport rules applied.  I don't have a system to hand to test with this very moment, but if I recall when I've had systems sending emails via SMTP the transport rules have applied.   I'll see what I can do to test, but I've been pulled on to another customer for a week or so, which means I'm struggling to get back to test it all.

    Tuesday, December 11, 2018 10:59 AM
  • so the 2007 sourced messages just relay off the 2016 servers? Not sure I would expect transport rules to be applied in that scenario since the Front End transport is stateless.

    Yes 2016 is purely used as a relay.  Surely any emails passing through the Exchange 2016 platform would have the transport rules applied?  There is certainly nothing that would lead me to believe that emails must originate from Outlook connections to have transport rules applied.  I don't have a system to hand to test with this very moment, but if I recall when I've had systems sending emails via SMTP the transport rules have applied.   I'll see what I can do to test, but I've been pulled on to another customer for a week or so, which means I'm struggling to get back to test it all.

    They dont have to be from outlook, but they do have to get processed by categorizer and mailbox transport service. If messages from that same 2007 server are sent to an 2016 mailbox, then the rules are applied, yes?

    And this is not an Edge Server correct?

     
    Tuesday, December 11, 2018 11:11 AM
  • so the 2007 sourced messages just relay off the 2016 servers? Not sure I would expect transport rules to be applied in that scenario since the Front End transport is stateless.

    Yes 2016 is purely used as a relay.  Surely any emails passing through the Exchange 2016 platform would have the transport rules applied?  There is certainly nothing that would lead me to believe that emails must originate from Outlook connections to have transport rules applied.  I don't have a system to hand to test with this very moment, but if I recall when I've had systems sending emails via SMTP the transport rules have applied.   I'll see what I can do to test, but I've been pulled on to another customer for a week or so, which means I'm struggling to get back to test it all.

    They dont have to be from outlook, but they do have to get processed by categorizer and mailbox transport service. If messages from that same 2007 server are sent to an 2016 mailbox, then the rules are applied, yes?

    And this is not an Edge Server correct?

     

    Not an edge server (although there are some in the environment).  The legacy Exchange system sends emails to one of the Exchange mailbox servers, which then sends to another for I suspect shadow redundancy, then that forwards it to the edge transport servers.  

    I've checked and the rules are not firing for emails going to mailboxes either.  As an example I have a transport rule set based upon subject.  It adds me as a BCC to those emails.  Email gets sent to an internal user from the legacy Exchange system, email doesn't trigger the rule.  When the user forwards that same email, the rule is triggered and I'm copied in to the email as a BCC.


    Tuesday, December 11, 2018 3:40 PM
  • so the 2007 sourced messages just relay off the 2016 servers? Not sure I would expect transport rules to be applied in that scenario since the Front End transport is stateless.

    Yes 2016 is purely used as a relay.  Surely any emails passing through the Exchange 2016 platform would have the transport rules applied?  There is certainly nothing that would lead me to believe that emails must originate from Outlook connections to have transport rules applied.  I don't have a system to hand to test with this very moment, but if I recall when I've had systems sending emails via SMTP the transport rules have applied.   I'll see what I can do to test, but I've been pulled on to another customer for a week or so, which means I'm struggling to get back to test it all.

    They dont have to be from outlook, but they do have to get processed by categorizer and mailbox transport service. If messages from that same 2007 server are sent to an 2016 mailbox, then the rules are applied, yes?

    And this is not an Edge Server correct?

     

    Not an edge server (although there are some in the environment).  The legacy Exchange system sends emails to one of the Exchange mailbox servers, which then sends to another for I suspect shadow redundancy, then that forwards it to the edge transport servers.  

    I've checked and the rules are not firing for emails going to mailboxes either.  As an example I have a transport rule set based upon subject.  It adds me as a BCC to those emails.  Email gets sent to an internal user from the legacy Exchange system, email doesn't trigger the rule.  When the user forwards that same email, the rule is triggered and I'm copied in to the email as a BCC.


    OK, *thats* unexpected considering these are 2 diff orgs. hmmm. Id sure love to see those headers and rule. lol
    Tuesday, December 11, 2018 7:07 PM
  • Hi,

    What about emails from other servers? Will they bypass the rules in Exchange 2016 as well?

    Please provide more details about the rule you set.
    Try to use ExRCA Tool to analyze those message headers, check if you can get some information from it.

    Regards,

    Lydia Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, December 14, 2018 11:17 AM