Tuesday, November 07, 2006 9:14 PM
I have two Exchange server 2003. Each one is in a different AD but on the same subnet. They are supposed to be independent and I'd like to keep it that way. However, we started to have this issue suddenly that when Server B sends emails to Server A, the emails got queued on Server B and are not delivered until I reboot Server B (restarting Exchange services and SMTP service do not help). On Server A with diagnostic logging turned on, it says in application log Event ID 7010 "504 need to authenticate first" - ie. my Exchange server replied with 504.
The client at "10.10.10.50" sent a "xexch50" command, and the SMTP server responded with "504 Need to authenticate first ". The full command sent was "xexch50 2112 2".
I checked around and MS knowledge base has a way to turn off XEXCH50 by adding SuppressExternal=1. However, even after I added the registry entry and rebooted the server, when I do EHLO, the server still shows XEXCH50 as an option. The key issue is unlike most other posts on the net, since the mails are queued on Server B, I will not get emails on Server A unless Server B reboots.
Can anyone help on how to fix this and why SuppressExternal=1 does not work prevent Server A from offering XEXCH50?
I urgently need any helps I can get. Thanks!
Monday, November 13, 2006 8:18 AM
SurpressExternal, as you noted, only influences outbound EXEXCH50, not inbound Exch50. You can allow anonymous Exch50 to come in by following the steps at http://www.microsoft.com/technet/prodtechnol/exchange/Guides/Ex2k3DepGuide/02bd89b4-715d-4048-999b-070640e9c49e.mspx?mfr=true. But rather than do this you're better of making sure the mail between your two servers is authenticated.
If you wish to disable the Exch50 completely, you can do it by modifying the unregistering the exch50 DLL, but I wouldn't recommend doing this either.
I'd look closer at the SMTP protocol logs for your system, I don't believe XEXCH50 is your issue. Failing Exch50 does not interrupt mailflow and should cause no problems. Outbound SMTP should always continue the SMTP session after failing to issue Exch50 and will continue to submit mail (both for mail between your two servers and mail coming in externally from the internet. the ability to send / retrieve Exch50 shouldn't change with time and require a reboot, either... I'd start there for your investigation.
Is mail queued up? If so, there's a diagnostic string in the queue viewer that should help you indicate why you need to reboot a server to regain mailflow.