Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS


One of the common things that OWA users notice about Exchange 2013 is that outgoing messages sometimes appear to get “stuck” in the Drafts folder. Not only do messages seem to linger in Drafts, no trace of the outbound messages ever shows up in the Outbox. Or so it seems, but really it’s an urban myth.

Exchange 2013 boasts a new architecture. The hub transport server role is no more and its processing has been subsumed into the mailbox server role. In turn, as the TechNet description of the Exchange 2013 mail flow makes clear, the Mailbox Transport service and the Transport service work together to process messages sent by clients.

Exchange 2013 Mail Flow (source: TechNet)

Exchange 2013 Mail Flow (source: TechNet)

But how does the Drafts folder come into the picture? Well, OWA clients automatically capture copies of messages as they are being composed and store them in the Drafts folder. 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.

Messages stay in the Drafts folder until they are successfully sent by being processed by the transport service. At this point, items are moved into the Sent Items folder. OWA 2013 behaves in the same way as OWA 2010 – nothing has changed in the way that messages are held in the Drafts folder until dispatch. What might account for user descriptions of items being “stuck” is when a problem occurs somewhere in the transport pipeline that prevents outbound messages being processed.

For instance, items will remain in the Drafts folder if the Store cannot pass them to the transport system. If the transport service is not running on any available server or the mailbox transport service is not running on the mailbox server that hosts the active database for the user’s mailbox, items will stay in the Drafts folder until the services come online and Exchange is able to process outbound items.

Now, the normal state of events is that all of the Exchange services are running along quite happily on the server. Certainly, if a service fails or is not running for some reason, it’s likely that the administrator will notice that this is the case and fix the problem. What else would stop transport being able to process outbound messages and force the Store to keep them in the Drafts folder?

Checking DNS Lookup properties for a server with EAC

Checking DNS Lookup properties for a server with EAC

Incorrect DNS binding to server NICs is one of the likely culprits. Unless the Exchange 2013 servers know how to route messages, the items stay where they are. Like any email server, Exchange makes heavy use of DNS, so it’s logical that if DNS is not configured properly, then messages are not going to be transported to either internal or external destinations. If users report “stuck” messages, you might just want to take a look at server properties with EAC to 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.

If the server properties reveal that DNS lookups are going walkabout, you’ve just found the problem. On the other hand, if the DNS configuration is correct, you might have to talk to Microsoft Support to see why transport isn’t working as expected. I hear rumblings that Microsoft has improved the way that Exchange interacts with DNS in Exchange 2013 CU1 but we shall have to wait for that release to verify if this is correct.

Outlook processes outbound messages differently because it does use the Outbox folder. Remember that Outlook can be a client for many different versions of Exchange and other email servers. Where OWA keeps messages in the Drafts folder, Outlook continues to do what it has done for years and moves outbound items through the Outbox en route to Sent Items. When messages are stuck in the Outbox, it’s probably due to another factor such as messages being too large for the server to accept. In effect, items in Outlook’s Outbox folder have the same status as items in OWA’s Drafts folder – both are candidates to become outbound items that will be processed by the transport service.

Messages don’t get stuck in the Drafts folder without good reason. It’s not as if Exchange wants to keep messages there. After all, it is an email server after all… and email servers that don’t send messages would not be much good!

Follow Tony @12Knocksinna

About these ads

About Tony Redmond

Exchange MVP, author, and rugby referee
This entry was posted in Exchange 2013 and tagged , , , , , , , , , . Bookmark the permalink.

21 Responses to Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS

  1. Pingback: Mail stuck in Drafts

  2. Pingback: Stuck! | /var/log

  3. Pingback: Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS | SME IT guy

  4. Pingback: Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS | akrameleyan

  5. Pingback: Manually Configuring DNS Lookups for Exchange Server 2013

  6. Tony, any idea why OWA does not use the Outbox folder like Outlook does? Seems like a conflagration of the purpose of the Drafts folder.

  7. Reni says:

    Thanks a lot, you saved me hours!
    Reni

  8. Andrew says:

    Why won’t Microsoft just simply licence Domino from IBM as a back-end and simply write nice Outlook connector ? Replication and HA is something that has worked and working great in Domino since late 90′s … Tony I think that Exchange 2013 will be the Last Exchange Ever …

  9. Excellent write-up. Well written and explored on the current situation.

    Please be aware that there really is a glitch of some-sort within Exch 2013 though, in regards to messages being “stuck in drafts”. Bouncing around many forums, and numerous lab builds myself – there is an issue that creates the circumstances in mail-flow.

    On every single installation / that I’ve done of Exch 2013 in multiple labs, when set as a single mailbox server, messages have never been able to leave the “drafts” folder. Not a single instance where it worked correctly. Messages leaving a mailbox, destined to the exact same server do not route, let alone use any send-connector to leave the organization.

    Now, take it to the next step, and install a second mailbox server. The very second that services finish installing, and AD replication (if using multiple sites) settles down, mail-flow on the first server starts working absolutely flawlessly. Whatever changes are done to AD from the second mailbox server being installed in regards to mailflow, it completely resolves the issues of the first server holding onto the messages.

    I haven’t been able to pin-point what these changes are, but it is definite, and very deliberate. Every single lab build I’ve gone through (upwards of 10-15) – the mailflow all resulted in the exact same issue. First mail server unable to route mail anywhere, and any and all messages stuck in drafts. Second mail server added to the org (in a very indeterminate time reference, some labs immediately installing the second server, some waiting days)… Once the second server is added, mailflow on the first starts working.

    I have found many forums that users experimenting with Exch 2013 have had the exact same conclusions as me on this… It’d be nice to see what was causing it, and make the adjustments after only a single server installation.

    *This mailflow problem is apparent, even in CU1 which was just released a little bit ago.

    • Declan says:

      I recall from previous versions of Exchange that the logic built into the product has evolved with regard to hub transport.

      With Exchange 2007 if you installed HT on the MBX server then the MBX server would only talk to itself for the HT role, which became a single point of failure, so with 2010 the opposite logic was enforced, if multiple HT servers are detected, Exchange 2010 MBX role will by preference talk to any other HT server but itself, in order to ensure redundancy of the transport role.

      I wonder if what’s happening with the second Exchange 2013 server is just this, there is a local DNS related transport issue that prevents the three step transport from working, but once a second transport server is detected in the organisation, via AD as you suggest, then the transport topology is altered, and the two Exchange servers now start to transport via each other.

      The specifics of how or why an Exchange server can resolve other server names but not it’s own name is still a bit of a mystery, in my own experience the DNS issue was on the Hyper-V host, strange as that may sound, and a host NIC DNS change to resolve from AD kicked things back into play.

      Typically the DNS client resolver will query it’s local host name as part of the name resolution process to check you’re not actually looking for yourself, but somewhere in the Exchange 2013 transport process at least one DNS query seems to be handed over to the host OS, which then fails to resolve.

      If this query is for the same guest that originates the query, mail gets stuck in draft.

      If the query is for another guest, such as the second Exchange server, mail starts to flow.

      • usslindstrom says:

        Apologies in not returning to this thread sooner – some work / life things got in the way and I hadn’t been able to revisit this issue for some time.

        I honestly think you may be onto something here. After poking some more into it, it may be the mix of having both the CAS and mailbox server role installed (which includes the transport service). In the case of a single server, the logs would indicate that you’re right on the suggestion that they use the secondary server to “load balance” between the hub transport role.

        In my digging around, message logs indicate that even though SMTP traffic was destined to a mailbox on Server A – when it’s in receipt of the traffic, there’s a transport log entry that shows the message being submitted to Server B right before delivery. The delivery log clearly had an entry that involved the receive connector IP of Server B on each of the messages.

        Another issue that appears to be somewhat of the problem, mentioned in the beginning of my post here, is that if you change any of the default receive connectors – there could be an instance that you “black-hole” your mail.

        When the CAS and Mailbox role are installed on your servers, the receive connector immediately gets updated to use Port 2525 instead of just port 25. This may have been part of my issue as well – as in the testing I was doing earlier – I believe I was definitely messing around with creating / deleting different receive connectors. Some sites identified this problem, and would convert the hub transport receive connectors to front-end transport receive connectors – and would likewise have limited success in mail flow after that point.

        This site actually has another really decent write-up on some of the particular problems:
        http://blogs.technet.com/b/rischwen/archive/2013/03/13/exchange-2013-mail-flow-demystified-hopefully.aspx

        I hadn’t had time to reinstall a full lab to test the theories out again – and with MS’ WONDERFUL idea of killing TechNet, chances on doing just this are definitely dwindling (Stupid MS).

        In any case – I’m chalking the mail-flow issues as multiple parts. The DNS issue that everyone seems to get working mail-movement, load-balancing between Hub Transport servers, and when mixing CAS & Mailbox roles on the same server how it inadvertently begins listening on port 2525 instead of just 25.

  10. Rajkumar says:

    I have single Exchange 2013, When I sent a test email for the first time from OWA, it ends up in drafts folders. Instead of adding the Second Exchange 2013 server, I changed the Internal DNS lookup settings(Custom Settings) to point to the IP address of my DNS server and I restarted the MSExchangeTransport service. Mail flow works fine now.

    @usslindstrom@yahoo.com, Can you please try that once on test lab

    • Carlos Negroni says:

      Thank you Rajkumar for your advice. I installed Exchange 2013 in a Virtual Machine but mails got stuck in the Draft folder so I changed the DNS information in ‘DNS Lookup’ settings and it worked.

  11. Pingback: Outbound Messages get stuck in Drafts OWA Exch 2013 | The-IT-Blog

  12. Pingback: Exchange 2013 RTM CU2 released | Jason (Izzy) Sherry's Blog

  13. Renato Pereira says:

    Why the MS cannot provide a fix for this stupid behavior??

  14. Jared says:

    I had the same experience as Rajkumar in the previous replies\posts. Mail flow was good to go. There was another odd issue: test messages sent from OWA the previous day, remained in the OWA drafts folder and we were unable to delete them. these messages not found in the queue, these messages not showing in outlook client. not in offline mode or cached mode. restarted submission transport and delivery transport and iisreset, no change. the issue also described in comments of this post: http://community.spiceworks.com/topic/309145-exchange-2013-messages-stuck-in-drafts ” If you have a lot of mail stuck in the drafts, it may stay stuck….I have 18 drafts that won’t go away, but all new mail sends and receives just fine. Since I’m the only one that tested, I don’t care that I see these “old” drafts. Annoying I can’t delete them though”

  15. SP13 says:

    Jared +1
    Can’t delete items from draft.

  16. Ed says:

    Has anyone seen an item stay in Drafts, but the message was sent? Why? Thanks.

  17. Pingback: Bad NIC Settings Cause Internal Messages to Queue with 451 4.4.0 DNS query failed (nonexistent domain) | Troubleshooting Exchange

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s