locked
Cannot send emails via a smart host in Exchange 2016 RRS feed

  • Question

  • Hi all,

      I've recently upgraded Exchange 2010 to 2016. All seems to be good in that clients are connected up and receiving e-mails...however, no one can send e-mails via our send connector (smart host). The configuration of the send connector is the same as the configurations I had in Exchange 2010.

    Email never reaches the smart host, and when I try and send e-mail via Outlook webmail it just gets stuck in Drafts.

    I currently have a single Exchange 2016 server in a virtual machine. Can someone help as it's driving me a bit crazy. I've been reading online and seem to heading down the DNS route? I did try setting the internal DNS lookup in Exchange to a DNS server on the network but this doesn't seem to have helped...

    Kind of stuck. Hope someone can help.

    Tuesday, September 27, 2016 6:35 PM

Answers

  • Hi,

    As you described above the message was stuck in drafts, messages stay in the Drafts folder until they are successfully sent by being processed by the transport service.

    When the user issues a sent command, the Mailbox submit agent (running within the Store driver) takes over and processes the outbound message by giving it to either the Transport service running on the same mailbox server or to the Transport server running on another mailbox server. The connection is made via SMTP.

    Make sure that DNS lookups point to the right place (a server can that resolve the lookups). You can also check with EMS by running the Get-TransportService cmdlet to retrieve the ExternalDNSServers and InternalDNSServers properties.

    It's also recommended to refer to the below similar thread and articles for troubleshooting steps:

    https://social.technet.microsoft.com/Forums/exchange/en-US/b7f0bc4e-2237-4e99-bc7f-128e87f76250/exchange-2013-cu2v2-messages-stuck-in-drafts-folder

    https://exchangekb.com/

    Please note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information. And the changes made in the above blog is not supported officially by Microsoft.

    Hope it helps.

    BR.


    Jason Chao
    TechNet Community Support


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


    • Edited by Jason.Chao Thursday, September 29, 2016 1:24 AM
    • Proposed as answer by Jason.Chao Thursday, October 6, 2016 8:37 AM
    • Marked as answer by Jason.Chao Friday, October 7, 2016 8:52 AM
    Wednesday, September 28, 2016 2:59 PM

All replies

  • Hi

    Can you start some troubleshooting such as:-

    Get-Queue | Get-Message | fl

    Get-Queue

    Get-TransportService | Get-Queue

    In some cases outbound mail flow depends on DNS & firewall access. This can also be checked. Suppose to check that MX records can be resolved in DNS by the Exchange server use the Resolve-DnsName PowerShell.

    Resolve-DnsName yahoo.com -Type Mx

    you can check the connectivity of your Exchange with telnet

    Install-WindowsFeature -Telnet-Client

    Now check the outbound smtp by telnet

    shakir@Ubuntu-SH:~$ telnet smtp.gmail.com 25
    Trying 64.233.184.109...
    Connected to gmail-smtp-msa.l.google.com.
    Escape character is '^]'.
    220 smtp.gmail.com ESMTP n28sm4640150wmi.2 - gsmtp

    if you do not see the 220 response and smtp banner you may need to check outbound smtp connectivity

    issue, or you need to check ur firewall.

    if you still not able to resolve the issue, you need to enable protocol logging on your send connector

    >Set-SendConnector "Your Connector Name" -ProtocolLoggingLevel Verbose

    now you need to check the logs at

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

    You can also check the Event Logs to find out the issue.

    check all necessary services are up and running.

    what is your smart host device, you can also review the configuration of that device

    Hope all these will help you to troubleshoot the issue, if still you face the same issue write back here.

    Kindly click "Mark as Answer" on the post that helps you, this can be beneficial to other community members reading this thread.

    Regards.

    H.shakir



    • Edited by H Shakir Tuesday, September 27, 2016 7:31 PM
    Tuesday, September 27, 2016 7:28 PM
  • Did you update the send connector to use the new server as a source? That is what allows the new server to use the send connector.

    Otherwise, check Queue Viewer and see what errors exist for the outbound queues. That will give an idea as to what's happening.

    You could also verify that the relay host is configured properly to accept messages from the new server. It might require authentication or be configured to accept messages on from specific IP addresses.


    Byron Wright (http://byronwright.blogspot.ca)

    Tuesday, September 27, 2016 8:17 PM
  • Thanks for your response. How do I configure the relay host?

    And yep I've set the source server in Scoping for the send connector to the new Exchange server. Funny enough when I had the old Exchange 2010 server and the new Exchange 2016 server in the send connector I was sending e-mail. But I've now decommissioned the old Exchange 2010 server.

    It was working at 6am this morning, just before I decommissioned the Exchange 2010 server (and it was no longer in the source server for the send connector). I don't know if that helps diagnose the issue?

    Jon



    • Edited by Jbennett8787 Tuesday, September 27, 2016 8:59 PM
    Tuesday, September 27, 2016 8:56 PM
  • Sorry to ask a dumb question, but are you sure you're using a relay host? A relay host is an SMTP server that sits between your Exchange and the Internet.

    If so, what type of relay host is it?


    Byron Wright (http://byronwright.blogspot.ca)

    Tuesday, September 27, 2016 8:58 PM
  • Thank you, I will try all of this.
    Tuesday, September 27, 2016 8:59 PM
  • Hi,

      I'm using a smart host. I previously in Exchange 2010 configured the send connector with this smart host (smtp.smarthostname.com) and basic authentication. That's how it used to work and how I sent out email.

    I also have the firewall configured for SMTP to the smart host. It was previously configured to the Exchange 2010 server. All I changed was the IP address in the firewall for SMTP services to now go to the new Exchange 2016 server. In terms of receiving it's fine, just the sending.

    Tuesday, September 27, 2016 9:03 PM
  • If it only stopped after Exchange 2010 was removed, then it seems that Exchange 2010 must have still been sending out the mail. If you have an external email address that you sent to during that time, you could verify from the mail headers.

    At this point, check queue viewer on the Exchange 2016 server and see what the error is.


    Byron Wright (http://byronwright.blogspot.ca)

    Tuesday, September 27, 2016 9:08 PM
  • By Smart Host, do you mean an antispam service hosted on the Internet? If so you'll need to log in there and see if there are any restrictions on how mail is sent through it.

    The new Exchange 2016 server may be sending from a different internet IP address than the Exchange 2010 server was. Depending on how NAT was/is configured.


    Byron Wright (http://byronwright.blogspot.ca)

    • Proposed as answer by PK Sarangi Wednesday, September 28, 2016 5:46 AM
    Tuesday, September 27, 2016 9:10 PM
  • I think that was the case. But it's really strange as to what's going on. Everything seemed to be good to go for the migration. I moved over all the mailboxes and configured the firewall and send/receive connectors. As far as I could see it was all working via Exchange 2016, but it seems like the sending aspect may not have been.

    Unfortunately I've now decommissioned the Exchange 2010 box believing everything was working perfectly well. The send connector looks the same to me as it did in Exchange 2010, the only difference being it's now using Exchange 2016 server as the source server. I can only think there must be some additional configuration in Exchange 2016 that I didn't need to set in Exchange 2010 (or it was already set by default?). Should I be changing the internal and external DNS lookups for the server in the exchange admin centre?....or just leave it set to all network adapters? I don't remember configuring anything like this in Exchange 2010.

    I will check out the queue viewer.

    Tuesday, September 27, 2016 9:13 PM
  • I will check the test emails I sent out at 6am this morning. This was the last point Exchange 2010 and 2016 coexisted...
    Tuesday, September 27, 2016 9:15 PM
  • Yeah, antispam service hosted on the internet. I've been on the phone to them today and they are suggesting I use smtp.smarthost.com as I did before, and they confirmed the basic authentication login details. It should be the same public IP address I used before, only have one static IP address, and they send email to me via that IP address I provided to them a while ago (that aspect still works).

    Thanks for your responses. Hope I can get to the bottom of this soon as it's stopping users sending email :-(

    Tuesday, September 27, 2016 9:19 PM
  • Just had a look at the message header from this morning when I sent the last message externally and it worked. RHINOEX2 is the new server.

    This was when both the old and new (RHINOEX2) was in coexistence. I've changed some of the details below to hide the domains and IP addresses.

    Received: from email.mydomain.co.uk ([22.22.22.22]) by messagestream.com with the MessageStream Outbound Distribution System; Tue, 27 Sep 2016 06:22:13 +0100
    Received: from RHINOEX2.INTERNALDOMAIN.LOCAL (192.168.1.9) by
     RHINOEX2.INTERNALDOMAIN.LOCAL (192.168.1.9) with Microsoft SMTP Server (TLS) id
     15.1.225.42; Tue, 27 Sep 2016 06:21:32 +0100
    Received: from RHINOEX2.INTERNALDOMAIN.LOCAL ([fe80::ccb6:16c0:d64:6117]) by
     RHINOEX2.INTERNALDOMAIN.LOCAL ([fe80::ccb6:16c0:d64:6117%12]) with mapi id
     15.01.0225.041; Tue, 27 Sep 2016 06:21:32 +0100

    Tuesday, September 27, 2016 9:28 PM
  • Yes, that certainly looks like it was properly routing directly from RHINOEX2 to messagestream.

    The other thing that changed at this point is the firewall when you changed the inbound SMTP. Perhaps that needs to be verified.

    You can try telnetting (use Putty - it's better than the Windows Telnet client and doesn't require an install) to port 25 on messagestream server. That will let you see if you have basic connectivity out from the host.

    You could also try restarting Exchange services or the whole Exchange 2016 server just in case, but at this point, I'd also evaluate the firewall and see if it's blocking since you made the changes.


    Byron Wright (http://byronwright.blogspot.ca)

    Tuesday, September 27, 2016 10:34 PM
  • Thanks. I will try that and report back. Should I Telnet smtp.messagestream.com 25 from the Exchange server? I guess that would tell me if it can communicate with it? I will double check firewall when I get to work tomorrow. I was fairly certain I changed it over correctly but there is a possibility it could be wrong. That was my initial thought because it all seems okay in the send connector? Is there anything I may need to change in the receive connectors or is that not relevant. I thought they was for incoming email only but reading online It seems like others have had a similar issue and made configuration changes to receive connectors and DNS lookup in Exchange. It was definitely working when the old Exchange 2010 server was online. I did read somewhere that some people have found their send connector only worked after introducing a second Exchange 2016 server to the environment (which I guess was similar to my environment when it was working, albeit with Exchange 2010). Not sure how true that is but initially I just want one server working before configuring DAGs etc so i know it can operate standalone.
    Tuesday, September 27, 2016 11:37 PM
  • So I don't go off on a tangent should I leave the receive connectors as they are? I'm receiving emails from messagestream so I'm assuming they are good and not relevant to my problem (some solutions I've read online have sent me down that path a bit even though I don't know why). If so that leaves me with the firewall and the send connector, and if the firewall is configured correctly and I have the correct settings for send connector then surely it should work. That's how it worked in Exchange 2010 and the only difference is I've changed the firewall to point smtp (and https for owa, auto discover etc etc) from the old Exchange 2010 to the new Exchange 2016, and added the new Exchange server as a source server to the send connector. It seems like a fairly basic configuration to get right...

    • Edited by Jbennett8787 Tuesday, September 27, 2016 11:50 PM
    Tuesday, September 27, 2016 11:47 PM
  • Yes, if mail is coming in, the receive connectors are fine.

    If you reused the same send connector and just changed the source, the send connector should be fine. Which really leaves the firewall. It's likely one of those two based on your description.

    Depending on the firewall NAT configuration can be tricky. So, it may be NAT rules and not just firewall rules. Or firewall rules if the NAT is correct.

    For telnetting out, you'll want to do that from the Exchange server to verify connectivity from that server.


    Byron Wright (http://byronwright.blogspot.ca)

    Wednesday, September 28, 2016 12:05 AM
  • Thanks very much for you responses it's helping a lot. Will be in work soon to look into this further. It seems logical. The send connector I assume would have worked prior to taking Exchange 2010 offline because it was listed as a source server in the send connector along with Exchange 2016. So although I had migrated over it was still able to send out. But then saying that the message header suggests RHINOEX2 (new Exchange 2016)
    • Edited by Jbennett8787 Wednesday, September 28, 2016 4:43 AM
    Wednesday, September 28, 2016 4:41 AM
  • Hi. I tried putty to telnet to messagestream from the Exchange 2016 server and got the following response:

    220 mes-pc-out-179

    Thanks.

    Wednesday, September 28, 2016 5:36 AM
  • Hi,

    I think you better discuss with the Smarthost provider, and tell them your exchange server is changed. They will check their logs and configure your new server details. I have similar experience before, and the Smarthost provider will added the new server into their firewall. Even you are using same public static IP, but the exchange server name changed. Smarthost provider accept mails from specific server and not limited to IP (this will prevent spamming from other system using same IP).

    Thanks

    Prabodha

    Wednesday, September 28, 2016 5:57 AM
  • I now have an update on the situation. I decided to build a second Exchange 2016 server with the intention of moving everything across. However, as a result of doing this and adding it to the domain, clients can now send and receive e-mails. I'm very confused.

    I added the additional Exchange 2016 server to source servers in the send connector. Looking at the message headers now I get the following:

    Received: from dgp.mydomain.co.uk ([81.142.xxx.xx]) by mes-kc-out-178.messagestream.com with the MessageStream Outbound Distribution System; Wed, 28 Sep 2016 10:31:37 +0100

    Received: from RHINOEX2.DOMAIN.LOCAL (192.168.1.9) by
     RHINOEX1.DOMAIN.LOCAL (192.168.1.5) with Microsoft SMTP Server (TLS) id
     15.1.225.42; Wed, 28 Sep 2016 10:30:54 +0100
    Received: from RHINOEX2.DOMAIN.LOCAL ([::1]) by RHINOEX2.DOMAIN.LOCAL
     ([::1]) with mapi id 15.01.0225.041; Wed, 28 Sep 2016 10:30:54 +0100

    As you can see, it looks as if the new server (RHINOEX1) is doing some of the work. If I turn it off then messages are stuck in drafts like they are before, but when it's on the messages are sent successfully.

    It's very confusing. Also my clients are now complaining about not having a certificate for RHINOEX1 so it's as if they are trying to connect to that rather than RHINOEX2 (which is already configured to use our external domain and certificate for autodiscover, owa etc, hence it doesn't complain about the certificate).




    • Edited by Jbennett8787 Wednesday, September 28, 2016 10:11 AM
    Wednesday, September 28, 2016 9:44 AM
  • Just to confirm, I'm definitely able to send out email when the second new Exchange 2016 server (rhinoex1) is online (and added as a source server to the send connector). As soon as I turn the new Exchange 2016 server off I am unable to send e-mails again, they get stuck in drafts (even though the send connector has the other exchange server in it).

    The router/firewall is configured to point to the first Exchange server (rhinoex2) for SMTP services, and it seems as if when sending out emails it is going through rhinoex1 and then on to rhinoex2 (see previous message for email header). But I really don't understand why it is doing this...

    I also notice that when the new exchange server (rhinoex1) is online that domain connected clients are presented with a certificate warning for rhinoex1. When rhinoex1 is off I don't get this, but I assume it's then pointing to rhinoex2 which is already configured for our external domain for autodiscover/owa etc and uses a certificate.



    • Edited by Jbennett8787 Wednesday, September 28, 2016 12:32 PM
    Wednesday, September 28, 2016 12:30 PM
  • So, based on the test with Putty, it looks like RhinoEx2 has connectivity to outside via SMTP. Given then RhinoEx1 works fine with the same send connector, I think we can confirm it's not the send connector configuration.

    When RhinoEx1 is off and RhinoEx2 is on, what is the error in Queue viewer when RhinoEx2 can't send. That might help us find out where the communication error is.

    Also, turn on logging for the Send Connector and that log might help too. Then we can see the SMTP commands going back and forth.


    Byron Wright (http://byronwright.blogspot.ca)

    Wednesday, September 28, 2016 1:44 PM
  • The certificate warning for rhinoex1 will be when clients are using that server for autodiscover. To avoid that, you can set the autodiscover URL on that server to $null or set it to be the same as the other server.

    This link shows how to set it to $null: http://byronwright.blogspot.ca/2012/08/prevent-autodiscovery-from-using-pre.html


    Byron Wright (http://byronwright.blogspot.ca)

    Wednesday, September 28, 2016 1:45 PM
  • Hi,

    As you described above the message was stuck in drafts, messages stay in the Drafts folder until they are successfully sent by being processed by the transport service.

    When the user issues a sent command, the Mailbox submit agent (running within the Store driver) takes over and processes the outbound message by giving it to either the Transport service running on the same mailbox server or to the Transport server running on another mailbox server. The connection is made via SMTP.

    Make sure that DNS lookups point to the right place (a server can that resolve the lookups). You can also check with EMS by running the Get-TransportService cmdlet to retrieve the ExternalDNSServers and InternalDNSServers properties.

    It's also recommended to refer to the below similar thread and articles for troubleshooting steps:

    https://social.technet.microsoft.com/Forums/exchange/en-US/b7f0bc4e-2237-4e99-bc7f-128e87f76250/exchange-2013-cu2v2-messages-stuck-in-drafts-folder

    https://exchangekb.com/

    Please note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information. And the changes made in the above blog is not supported officially by Microsoft.

    Hope it helps.

    BR.


    Jason Chao
    TechNet Community Support


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


    • Edited by Jason.Chao Thursday, September 29, 2016 1:24 AM
    • Proposed as answer by Jason.Chao Thursday, October 6, 2016 8:37 AM
    • Marked as answer by Jason.Chao Friday, October 7, 2016 8:52 AM
    Wednesday, September 28, 2016 2:59 PM