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)
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
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
Thoughtsofanidlemind's Blog 
Pingback: Mail stuck in Drafts
Pingback: Stuck! | /var/log
Pingback: Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS | SME IT guy
Pingback: Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS | akrameleyan
Pingback: Manually Configuring DNS Lookups for Exchange Server 2013
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.
No idea. Outlook has always worked the way that it does… it goes back as far as Outlook 97, so maybe it’s just the way that it was deemed good at that time.
I have been working in this today all day…
And I found that it was unsyncronized time between PDC and Exchange server so I followed the Solution 1 in this post and it work.
This worked in a WS2012 R2 and Exchange server 2013 SP1 enviroment
http://ficility.net/2014/02/27/exchange-2013-sp1-problem-1-powershell-virtual-directory-malfunction-https-error-500/
Thanks a lot, you saved me hours!
Reni
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 …
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.
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.
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.
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
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.
I had just installed Exchange 2016 and my first test mail went straight to drafts. This is the only thing that worked for me. I changed the external and internal hostname to the same name as my mx record in DNS.
I’ve tries all possible ways mentioned here, still my mail flow doesn’t work..
Then file a support call with Microsoft and save yourself from the heartache of debugging software that is still supported…
Rajkumar,
Where did you make this change. Could you provide some details around this. I cant seem to find the Custom settings on my Ex ECP.
Anurag
Rajkumar, your suggestion worked.
A bit late to the party, but wanted to say thanks as this was causing me tons of headaches!
Pingback: Outbound Messages get stuck in Drafts OWA Exch 2013 | The-IT-Blog
Pingback: Exchange 2013 RTM CU2 released | Jason (Izzy) Sherry's Blog
Why the MS cannot provide a fix for this stupid behavior??
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”
Jared +1
Can’t delete items from draft.
Has anyone seen an item stay in Drafts, but the message was sent? Why? Thanks.
Pingback: Bad NIC Settings Cause Internal Messages to Queue with 451 4.4.0 DNS query failed (nonexistent domain) | Troubleshooting Exchange
Pingback: 451 4.7.0 Temporary server error. Please try again later. PRX4 | SleekExchange.Net
Just setting up a test VM with Exchange 2013 on and have hit this problem as well… and manually specifying DNS server did not help. I have the simplest setup possible – one DC and one Exchange server, and I can’t even send internal emails.
In my case it was the Microsoft Exchange Mailbox Transport Submission Service
http://ezref.info/Exchange+OWA+2013+Emails+Stuck+in+Drafts+folders.html
you’re awesome dude…thanks…
Pingback: No DNS Servers on NIC | thejesperbernle
OMG!!! You saved our embarrassment! Thank you!!!!!!!!!!!!!!!
i had a related dns problem. I had setup my exchange server in my home lab with 2 dns servers, in the network card settings. the 1st was to my dns server in the domain, and the second to my home router IP. Exchange didnt like that and couldnt route mail even with telnet to port. 25. When i removed the secondary dns entry (the one pointing to my router) and left it blank, its started working! And I *think* it has solved my autodiscover problem too !
So, thanks for sharing !!
Thanks again for this. My problem re-occured – or I should say that the symptom re-occured. I found that my Exchange server was running out of disk space! Sorted that out and it is working again now. 🙂
LOL I feel like such a dumbass. Same thing happened to me. Weird there’s no warning and flashing lights when you only have 95MB left on the drive. >_<
Time sync between exchange and AD should not be more than 5 minutes (https://support.microsoft.com/en-in/kb/979174)
I changed my DNS settings on my exchange 2016 server and solved the problem. Thanks for your article!
This is a life saver post thanks man.
Hello Friend i have a big problem i have configured Microsoft Exchange Server 2016 i am not able to send the email all emails are going in Draft Folder while sending from OWA
Please help me
Pingback: Exchange 2013 und 2016: Mails bleiben in Entwürfe hängen – Andreas' Blog
This post solved my problem. I decided to create new VM servers to host Active Directory, as I was sharing a single Hypervisor server with AD )which is not recommended). Once the new AD VMs were created, I demoted the base servers. All worked OK in teh network, except Exchange. I had configured the NICs to point to the proper AD server, but forgot to mke the changes in DNS Lookups as outlined above. Once I did that toii the first server in the DAG, all the emails started to come through. I completed the rest of the servers in the DAG, and now all works well as before.
I wasted whole day ……… should have read this article couple of hours ago.
Thanks for your help. I changed DNS settings from EAC (exactly like you showed in your article)
And re-started mailbox transport role couple of times.
Thanks 🙂
Tried everything and would like to let everyone know that this still is an issue on Exchange 2016.
What I did to resolve this was put the exchange DNS name in hosts and voila, it works.
Thanks a lot to the writer of this article and Caltwizie for this sollution
HELLO,
I HAVE A PROBLEM WITH THE SIZE OF PIECE JOINTE IN EXCHANGE 2016 THE SIZE IS LIMITED BY 25 MB, I WANT THE INCREASED; HOW SHOULD I DO
THANK YOU IN ADVANCE
You mean the maximum message size for a message?