none
Exchange 2013 message suck in mailbox queue with ready status RRS feed

  • Question

  • I have only one Exchange 2013 SP1 server and one 2012 R2 Domain controller.  The one Exchange server is a mailbox and database server.  I have no edge transport server.   We'll call my external domain mybusiness.com and the internal domain is mybusiness.net.   I have made several mailboxes by by asking Exchange to tie in to the existing domain accounts.  All addresses are mybusiness.com.  Outlook 2013 auto connects to the correct account and displays the correct email address.  

    When I try to send an email locally from user1@mybusiness.com to user2@mybusiness.com, the message goes to the outbox and no error messages are shown.  I see the message in the mailbox database queue in a ready state.  There are so many different log files and information on the net that all my search find find out the problem have turned up with nothing.  The last error is blank.  Do I even need a send connector for internal email with only one server? 

    When I receive a message from the internet, from say a gmail account, my firewall shows that it is accepted and gets sent tot the server.  For a while, those messages would also show up in the mailbox database queue in a ready state and would also not process.  Now they don't even do that.  

    When I send an outgoing message to the internet, it also goes to sent items with no error message.  I cannot find mention of it anywhere in the queues, and yet I don't receive it on the external mail server.  The outgoing send connector is set for SMTP and * domains.  It should be identical to the default send connector.

    I even tried mess with telnet which inconsistent results.  Sometimes the commands work, other times they tell me invalid domain name, command not found, bad address and then I'll put in the exact same command and it will work.  So for, I have not been able to complete the 5 commands to send the message without being kicked out for too many bad commands.


    Saturday, August 2, 2014 12:28 AM

Answers

  • Well blow me down.  The last bit was done by fixing the DNS settings on the network adapter in Windows control panel.  If it has access to a public dns server, it uses that for fielding internet email even though internal works with just the Exchange settings.  Keep in mind that my internal DNS server will forward requests to the internet so it can still resolve external domains, but it will prioritize internal A records that I put on my internal DNS server.  

    So in summary, In Exchange Admin Center -> Servers -> Your server -> DNS.  Choose custom and only pick the internal DNS server for your domain.  Also, configure the network adapter for your server to use static DNS and have the only entry being the same internal DNS server.

    • Marked as answer by mplichta Monday, August 4, 2014 3:52 AM
    Monday, August 4, 2014 3:51 AM
  • False alarm.  It was just the self signed certificate preventing Outlook from connecting.  Here's how I resolved it.

    1. Open control panel on the exchange server
    2. Search for "cert"
    3. Open the certificates control panel
    4. Expand "trusted root certificate authorities"
    5. Find the certificate for the name of your exchange server
    6. Click it and then actions->Export
    7. The defaults of DES and don't export private key are ok. 
    8. Save it to a network location your domain controller can access
    9. Logon to your domain controller or a machine capible of group policy management
    10. edit the default domain policy or other computer policy of your choosing
    11. expand computer->policies->windows settings->security->Public Key Policies->Trusted Root Certification Authorities
    12. Right click the Trusted Root Certification Authorities and import
    13. Select the exported cer file from earilier.


    • Marked as answer by mplichta Tuesday, August 5, 2014 3:58 AM
    Tuesday, August 5, 2014 3:58 AM

All replies

  • I rebuilt the Exchange server from scratch.  Had to use ADSIedit to remove domain entries so that it would reinstall.  Same issue as before.  

    I'm currently investigating DNS issues being that the email domain is different from the server's domain.  I imagine internal email trying to leave the router and then re-enter immediately getting stuck.   IPV6 has been one of the worst experiences of networking configuration that I've ever had to do.  

    It turns out that outgoing email was working before and is working again now.  It's just incoming and internal that are a problem.

     
    Saturday, August 2, 2014 8:04 PM
  • I've had to set the MX record back to Yahoo so business can function while I mess with this problem.  I'm just trying to get internal email to flow.  I'm still not sure if I need a smart connector or any send connector period for intenal mail on a single server.  I ended up creating two internal mx records for the main domain and the mail domain and then telling Exchange to use that server specifically.  Still researching, but not sure where to turn next.  It's like trying to get the server to acknowledge it's own hand exists.  
    Sunday, August 3, 2014 10:53 PM
  • The log with the error was this one.  

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

    Since my logon domain is not publicly routable, I had to remove all public DNS servers and only put my internal DNS server in the list.  It was sending internal email using the logon domain rather than the public email domain.  

    OWA and Outlook both say the correct public email domain, but the internal routing is all by logon domain, despite changing the default.

    Sunday, August 3, 2014 11:59 PM
  • We are so close. outgoing and internal mail works with the following config. 
    my domain controller runs DNS and has the following domains configured and host records

    mysite.net  - internal logon domain.  Not publicly accessible
    • dc1.mysite.net  - 10.0.2.10
    • exch1.mysite.net - 10.0.2.12
    • mx record for mysite.com
    mysite.com - external email and website domain.  Hosted by Yahoo
    • made authortative forward lookup zone on mysite.net dc1
    • mx record for mysite.com points to exch1.mysite.net
    • Not sure if this is going to block domain computers from accessing the real website or not.  


    Yahoo.com - hosts mysite.com
    • webmail.mysite.com points to public ip address of router for mysite.net
    • mx record for mysite.com points to webmail.mysite.com
    • mysite.com has some other ip address for the yahoo websterver
    • www.mysite.com also has the other ilp address for the yahoo webserver

    The above setup works for sending internal email as well as outgoing internet email.  But when I receive internet email, the log drops it saying "Message or connection acked with status Fail and response 554 5.4.4 SMTPSEND.DNS.NonExistentDomain".  The trouble is, it doesn't say what domain it's trying to find.  The recipient says mplichta@mysite.com but I don't know where it's doing it's dns lookup.  I would assume the same config insider servers->dns would apply to internal mail as well as external mail received.
    • Edited by mplichta Monday, August 4, 2014 3:32 AM
    Monday, August 4, 2014 3:21 AM
  • Well blow me down.  The last bit was done by fixing the DNS settings on the network adapter in Windows control panel.  If it has access to a public dns server, it uses that for fielding internet email even though internal works with just the Exchange settings.  Keep in mind that my internal DNS server will forward requests to the internet so it can still resolve external domains, but it will prioritize internal A records that I put on my internal DNS server.  

    So in summary, In Exchange Admin Center -> Servers -> Your server -> DNS.  Choose custom and only pick the internal DNS server for your domain.  Also, configure the network adapter for your server to use static DNS and have the only entry being the same internal DNS server.

    • Marked as answer by mplichta Monday, August 4, 2014 3:52 AM
    Monday, August 4, 2014 3:51 AM
  • It seems as the the manual ADSIEdits used to manually uninstall Exchange , or perhaps the above DNS config are causing Autodiscover to fail for Outlook.  Both internal and external Outlook 2013 clients are unable to connect to the server.  I'll post back when I have more information.  


    Monday, August 4, 2014 4:44 PM
  • False alarm.  It was just the self signed certificate preventing Outlook from connecting.  Here's how I resolved it.

    1. Open control panel on the exchange server
    2. Search for "cert"
    3. Open the certificates control panel
    4. Expand "trusted root certificate authorities"
    5. Find the certificate for the name of your exchange server
    6. Click it and then actions->Export
    7. The defaults of DES and don't export private key are ok. 
    8. Save it to a network location your domain controller can access
    9. Logon to your domain controller or a machine capible of group policy management
    10. edit the default domain policy or other computer policy of your choosing
    11. expand computer->policies->windows settings->security->Public Key Policies->Trusted Root Certification Authorities
    12. Right click the Trusted Root Certification Authorities and import
    13. Select the exported cer file from earilier.


    • Marked as answer by mplichta Tuesday, August 5, 2014 3:58 AM
    Tuesday, August 5, 2014 3:58 AM
  • Hi,

    Thanks for your generous sharing.

     

    Thanks

    Mavis


    Mavis Huang
    TechNet Community Support

    Wednesday, August 6, 2014 11:36 AM
    Moderator
  • thanks buddy....perfectly worked for me.
    Tuesday, September 19, 2017 1:53 PM
  • mplichta - THANK YOU for posting this!!  This was driving me nuts for a while, but you saved the day for me! :)
    Friday, July 19, 2019 2:39 PM