none
Outgoing e-mails are stuck in queue.

    Question

  • we are using exchange server 2013 and our exchange server receive and send email properly on local network, and receiving incoming emails from outside network but Outgoing e-mails stuck in queue with error {LED=441 4.4.1 error encountered while communicating with primary target IP Address:"421 4.4.2 connection dropped due to SocketError." attempted failover to alternate host, but that did not succeed. Either there are no alternate host.

    Also created new send connector and did telnet to port 25 and uninstall Antivirus as well.

     
    • Edited by SAS_Pak Wednesday, December 30, 2015 12:18 PM
    Wednesday, December 30, 2015 12:14 PM

Answers

  • Hi,

    If you have a smart host configured on your send connector, you need to be able to telnet on port 25 from the Exchange server to the IP of the smart host. If you don't have a smart host configured then you need to be able to telnet on port 25 from the Exchange server to public SMTP servers e.g. mx3.hotmail.com.

    If you cannot do this then check the below:

    • Outbound windows firewall configuration on Exchange
    • Any 3rd party firewall software
    • AV configuration
    • Site firewall configuration - you need to ensure that port 25 is open from Exchange to the internet
    • ISP - some ISPs block outbound port 25, especially for residential connections

    Thanks.


    Please mark as an answer if this answers your question

    Mark Gossa

    MCSE 2003, MCITP Enterprise Administrator 2008 R2, MCSA 2012 R2, MCTS Exchange 2010, MCTS SQL 2012, MCTS SharePoint 2007, VCP4, VCP5, CCNA

    Blog: http://markgossa.blogspot.com   LinkedIn:

    Posts are provided “AS IS” without warranty of any kind, either expressed or implied.

    • Marked as answer by SAS_Pak Monday, January 4, 2016 12:47 PM
    Wednesday, December 30, 2015 10:35 PM

All replies

  • Hi,

    If you have a smart host configured on your send connector, you need to be able to telnet on port 25 from the Exchange server to the IP of the smart host. If you don't have a smart host configured then you need to be able to telnet on port 25 from the Exchange server to public SMTP servers e.g. mx3.hotmail.com.

    If you cannot do this then check the below:

    • Outbound windows firewall configuration on Exchange
    • Any 3rd party firewall software
    • AV configuration
    • Site firewall configuration - you need to ensure that port 25 is open from Exchange to the internet
    • ISP - some ISPs block outbound port 25, especially for residential connections

    Thanks.


    Please mark as an answer if this answers your question

    Mark Gossa

    MCSE 2003, MCITP Enterprise Administrator 2008 R2, MCSA 2012 R2, MCTS Exchange 2010, MCTS SQL 2012, MCTS SharePoint 2007, VCP4, VCP5, CCNA

    Blog: http://markgossa.blogspot.com   LinkedIn:

    Posts are provided “AS IS” without warranty of any kind, either expressed or implied.

    • Marked as answer by SAS_Pak Monday, January 4, 2016 12:47 PM
    Wednesday, December 30, 2015 10:35 PM
  • Hi,

    In you scenario, you can use Get-Queue | FL *error* cmdlet to get the last error on any queue. Then post the results here.

    Then enable protocol logging on the send connector by following cmdlet:

    Get-SendConnector | Set-SendConnector -ProtocolLoggingLevel Verbose

    After a while, access to the path below to collect the log file:

    C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

    Access to the link below for more details about configure protocol logging:

    https://technet.microsoft.com/en-us/library/bb124531(v=exchg.150).aspx


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Thursday, December 31, 2015 9:28 AM
  • Thanks Mark

    we finally resolve the issue by trying last suggestion "ISP - some ISPs block outbound port 25". we identify the problem through Winpcap software to trace blockage of telnet, with this we identify that at ISP end our telnet failed. we share our finding with ISP then they resolve the issue.

    Monday, January 4, 2016 12:55 PM
  • Hi,

    That's good to hear. All the best.


    Please mark as an answer if this answers your question

    Mark Gossa

    MCSE 2003, MCITP Enterprise Administrator 2008 R2, MCSA 2012 R2, MCTS Exchange 2010, MCTS SQL 2012, MCTS SharePoint 2007, VCP4, VCP5, CCNA

    Blog: http://markgossa.blogspot.com   LinkedIn:

    Posts are provided “AS IS” without warranty of any kind, either expressed or implied.

    Monday, January 4, 2016 1:31 PM