Forum Discussion

walter-wodzien's avatar
walter-wodzien
Brass Contributor
Oct 15, 2024

new Exchange 2019 node tries to connect to Exchange 2016 on port 2525 when using SMTP relay

We had a pair of Exchange 2016 servers that are only used for SMTP relay and user management, one server in each geographic datacenter. We just added Exchange 2019 to the environment, one node in each data center. When I shut down Exchange 2016 in one datacenter and try to perform SMTP relay through Exchange 2019, E2019 tries to talk to E2016 over port 2525 before it accepts mail for delivery, creating a 10+ second delay. When E2019 is down, E2016 does not exhibit similar behavior and fires the message right away with no delay. Not sure why this happens, but I want to remove this dependency of E2019 on reaching out to E2016. Here is the message I see on E2019 (192.168.1.20 is E2016), I can also observe this communication in Wireshark.
 
Failed to connect. Winsock error code: 10060, Win32 error code: 10060, Destination domain: internalproxy, Error Message: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.1.20:2525.
  • figured this out, turns out E2016 does not care much about the shadow copy while E2019 aggressively pursues it 🙂  after disabling shadow copy E2019 sends the message right away, one can actually see this in action by looking at the message tracking log (HAREDIRECT).  more info on the feature here: Shadow redundancy in Exchange Server | Microsoft Learn

  • figured this out, turns out E2016 does not care much about the shadow copy while E2019 aggressively pursues it 🙂  after disabling shadow copy E2019 sends the message right away, one can actually see this in action by looking at the message tracking log (HAREDIRECT).  more info on the feature here: Shadow redundancy in Exchange Server | Microsoft Learn

Resources