none
EXCHANGE 2013: How to trust other servers?

    Question

  • Hi,

    we have Exchange Server 2013 in our infrastructure. In the past I worked with Exchange but not with the version 2013.

    Actuall, our issue is related to SCOM, but also to Exchange. Unfortunately we cannot send any e-mail more using an authenticated user account (in SCOM called "Run As" account) from SCOM server.

    Which error we exactly get, they are also defined in the following article:

    http://thoughtsonopsmgr.blogspot.de/2012/05/scomom12-notification-errors-failed-to.html

    My question is for Exchange experts:

    How can I check whether Exchange servers trust to SCOM servers? And how can I do it?

    Best Regards

    Birdal

    Wednesday, January 10, 2018 2:44 PM

Answers

  • Hi,

    I found the issue source and solved it now. I investigated on Exchange site. As I checked maiflow logs, I saw that SCOM emails will be handled by the receiver "Client Proxy <ServerName>"- This connector "accepts authenticated client connections that are proxied from the Front End Transport service", and use the TCP port 465, which I also set, as Exchange team told me, on the SCOM site.

    That did not work and SCOM logged always the errors as I described n´in my previous post.

    There is also another receiver named "Client Frontend <ServerName>" which "accepts connections from authenticated SMTP clients", and use TCP port 587.

    I changed the port from TCP 465 to 587. Bingo! It worked.

    I know now that I must study also Exchange, and SQL, and CommVault, etc. if I administer our SCOM environment :-).

    But, it is still not clear for me why the other 2 SMTP channels worked although they had got the port 465?! Before the ports, as Exchange team suggested, are changed to port 465, these both channels used the port 587. Is it possible that SCOM "cached" the port 587 for a while on these both SMTP channels?! I can't imagine that.

    Sources:

    Receive Connectors

    Receive connector authentication mechanisms

    Exchange 2013 Mail Flow

    Best Regards

    Birdal
    • Marked as answer by _Birdal Tuesday, January 16, 2018 3:49 PM
    Tuesday, January 16, 2018 3:49 PM

All replies

  • Hi,

    we have Exchange Server 2013 in our infrastructure. In the past I worked with Exchange but not with the version 2013.

    Actuall, our issue is related to SCOM, but also to Exchange. Unfortunately we cannot send any e-mail more using an authenticated user account (in SCOM called "Run As" account) from SCOM server.

    Which error we exactly get, they are also defined in the following article:

    http://thoughtsonopsmgr.blogspot.de/2012/05/scomom12-notification-errors-failed-to.html

    My question is for Exchange experts:

    How can I check whether Exchange servers trust to SCOM servers? And how can I do it?

    Best Regards

    Birdal

    Do they really need to "trust" them? Why not simply send the alerts to server as you would any message from a process that exists outside of Exchange?

    Wednesday, January 10, 2018 2:53 PM
  • Hi,

    That is not my point.

    My question is "How can I check whether Exchange servers trust to SCOM servers? And how can I do it?"

    Best Regards

    Birdal

    Wednesday, January 10, 2018 4:07 PM
  • Hi,

    That is not my point.

    My question is "How can I check whether Exchange servers trust to SCOM servers? And how can I do it?"

    Best Regards

    Birdal

    Define "trust". And I ask again, what's the business reason?

    If you to ensure that only those servers can send to Exchange, consider creating a new receive connector and scope the IP remote ranges to those SCOM servers. I'm not seeing the need to authenticate to Exchange unless there is some requirement that I am missing.

    Wednesday, January 10, 2018 4:14 PM
  • Hi Andy,

    I have sent the article above. We get alsio the same errors.

    SCOM Run As account must send emails to the mail-enabled groups.

    But SCOM gets these errors (in article) if any email should be sent.Best Regards

    Birdal

    Thursday, January 11, 2018 1:24 PM
  • Hi Andy,

    I have sent the article above. We get alsio the same errors.

    SCOM Run As account must send emails to the mail-enabled groups.

    But SCOM gets these errors (in article) if any email should be sent.Best Regards

    Birdal

    If you control those SCOM servers, then another option to avoid actually authenticating the connection but Exchange will treat the connection as authenticated is to create a new receive connector and set as externally authenticated

    Example:

    http://no-one-uses-email-anymore.com/safe-senders-spoofing-and-office-365-they-really-can-be-friends/

    Thursday, January 11, 2018 7:49 PM
  • Hi,

    I found the issue source and solved it now. I investigated on Exchange site. As I checked maiflow logs, I saw that SCOM emails will be handled by the receiver "Client Proxy <ServerName>"- This connector "accepts authenticated client connections that are proxied from the Front End Transport service", and use the TCP port 465, which I also set, as Exchange team told me, on the SCOM site.

    That did not work and SCOM logged always the errors as I described n´in my previous post.

    There is also another receiver named "Client Frontend <ServerName>" which "accepts connections from authenticated SMTP clients", and use TCP port 587.

    I changed the port from TCP 465 to 587. Bingo! It worked.

    I know now that I must study also Exchange, and SQL, and CommVault, etc. if I administer our SCOM environment :-).

    But, it is still not clear for me why the other 2 SMTP channels worked although they had got the port 465?! Before the ports, as Exchange team suggested, are changed to port 465, these both channels used the port 587. Is it possible that SCOM "cached" the port 587 for a while on these both SMTP channels?! I can't imagine that.

    Sources:

    Receive Connectors

    Receive connector authentication mechanisms

    Exchange 2013 Mail Flow

    Best Regards

    Birdal
    • Marked as answer by _Birdal Tuesday, January 16, 2018 3:49 PM
    Tuesday, January 16, 2018 3:49 PM