We were experiencing this intermittently for some users but not others. I had read somewhere about having Outlook open caused this problem but it did not seem to match our circumstances as user who had Outlook open on their desktop were still able to send via OWA. However, I finally hit on the problem/solution, at least in our case. Some of our users use a terminal server to access CRM integrated Outlook and typically leave their sessions logged in with Outlook open. On our terminal server Outlook will not run in Cached mode.... This appears to be the key to our troubles. Any user with an Outlook session running in Online mode could not send. As soon as Outlook was closed, they were now able to send using OWA or their Mobile Device..
I am not sure why outlook running in cached mode is not affected and onlin mode is but to throw awild guess out there it might have something to do with online modes persistant connections locking some portion of the exchange 2007 transport mechanism...
Not sure if this helps anyone, but we've been experiencing a similar issue, where anyone who tried to send an email, internally or externally, just ended up with the email stuck in the Drafts folder, and it never reached the intended recipient. After reading sfhank's post previously I did some checking, and found that we only had 1.9GB free space on the C drive.
As I'm currently just in the process of evaluating Exchange 2007 on a Virtual server, it was a simple job to shut it down, and add a second 8gb virtual disk. Once rebooted I initialised the new disk and quick formatted it, then opened the Exchange console and changed the database paths for both the first and second storage groups to the new D: drive, and edited the edgetransport.exe.config file so the queue database & logs point to D: also, as sfhank suggested, (I don't know if I needed to change the mailbox database paths also, but it seemed a good idea anyway).
Once I restarted the Exchange Transport service all emails left the drafts folder, and magically appeared in the recipients mailbox!
As I said, not sure if this is helpful to people, but it seemed like a similar issue, so might be relevant to some!
I have been having similar problems. I am testing in a lab and the issue does appear to be related to back pressure. I will post more later this afternoon for any interested.
< Message edited by dsims1999 -- 30.Aug.2007 4:15:07 PM >
I moved my Databases to a different drive and cleared out about 6 Gigabytes of space. After I stopped and restarted the services the Draft Folder Cleared out and normal mail began to flow.
Is it possible that intermitent problems occur due to size fluctuation in the DBs?
Did you move your Queue database, or Mailbox/Storage group database?
I think you only have to move the queue database path to a drive with more than 4gb (Although its never a good idea to have the mailbox database on a drive with less than 4GB anyway).
For me, everything started working after I edited the edgetransport.exe.config file and change the path for both the queue database & queue database logging:
is everyone here running server 2k3x64sp2? Sounds like one of the many bugs in sp2 evident on some server hardware (example: all my IBM 340 series boxes run it no problem, by my HP Proliant DL580s choke up and die). Proliant DL580 with SP1 so far has no such issues, I have seen it a lot more on sp2 boxes. hmmmm.....
2435 02CC511D Data.Storage Storage Storage.Message.Send. 2436 029DC843 Data.Storage Storage RecipientTable::ModifyParticipants. 2437 0 Data.Storage Storage ReplyForwardCommon::DecodeMessageStatus. The message status data has been corrupted. Status count = 1. Value = . 2438 02CC511D Data.Storage Storage Item::Save. HashCode = 46944541 .. 2456 0 StoreDriver MailSubmissionService PFD EMS 22427 SubmitMail for mailbox 2aa73f88-8e65-49a5-a660-142dbf0e9ab0 at entry 135840 2457 0 StoreDriver MapiSubmit PFD ESD 27547 Processing Rpc SubmitMessage for event Event 135840, mailbox 2aa73f88-8e65-49a5-a660-142dbf0e9ab0, mdb 6ff07da6-0bc8-47e9-8838-42b8ffb91ab0 2458 0 StoreDriver MapiSubmit PFD ESD 23451 Submitting event Event 135840, mailbox 2aa73f88-8e65-49a5-a660-142dbf0e9ab0, mdb 6ff07da6-0bc8-47e9-8838-42b8ffb91ab0 2459 0 StoreDriver MapiSubmit PFD ESD 17307 Opening mailbox 2aa73f88-8e65-49a5-a660-142dbf0e9ab0 on 6ff07da6-0bc8-47e9-8838-42b8ffb91ab0,SERVER.INTERAL . 2479 00D2A58F Data.Storage Dispose MailboxStoreObject::Constructor. Hashcode = 13804943. 2480 0 StoreDriver MapiSubmit Bind to message item . 2485 0 StoreDriver MapiSubmit Notification recieved for a message that wasn't submitted
Unfortunelty they didnt know how to fix it!! In the end i abandoned the case and built up a second exhcange 2007 to only have the same issue. Win2k3 64Bit with SP2.
For heavens sake is there a fix for this?
Well at least it works with outlook closed of the TS .
I had the same issue with my install of Ex2007 on VMWare. In OWA: Sent messages would not be sent and go to the Drafts folder. Outlook: Sent messages would not be sent and go to the Outbox folder.
I took that advice above (even though I had over 2 GB of space on the System/Exchange drive) When I created an 8 GB drive and installed Ex2007 on that drive I could send!
I know that this is an old post, but this comes up alot in google, so i thought I would add what worked for me as well..
Like everyone else here, I'm evaluating Exchange 2007 in VMWare and I made the mistake of only making a 10gb primary disk, so if I sent a message from Outlook it would get stuck in the outbox, and if I sent a message from OWA, it would get stuck in the Draft folder..
In the end I followed the suggestion by bjblackmore plus from another forum somewhere else on the net...
1) Since I only had 2.3gb left on the C Drive, I created a D drive and gave it 20gb (maybe overkill but who cares)
2) Moved both the Mail Store and the Public Folder Store to the Newly created D Drive (I created D:\Mail Store and D:\Folder Store)
3) Opened Up edgetransport.exe.config and changed the Queue Database and Queue Log file to also point to the D drive (I created D:\Queue)
4) By this point the Mail was still stuck for me, so I read somewhere else from some MS MVP guy to change the edgetransport service from the Network Account to the Local System account and Voila, the mail started to flow
For most, by step 3 you should be good to go, but for me, I needed step 4 dont ask me why. Also, every time I made a change to the mail store or transport service, I restarted the service.
I hope this helps someone else out because I know it took me a while to figure it out. Thanks to bjblackmore and others for setting me in the right path
Also our issue was when a users was in TS and running the CRM client it locked out access to Exchange (only when sending emails from webmail and AS) IF the user just simply closed there outlook session in TS then it would work. In our case it was the CRM client.
I had the same problem recently on Exchange 2k7 with emails stuck in the drafts folder from OWA. I noticed this in the application log:
The Microsoft Exchange Mail Submission Service is currently unable to contact any Hub Transport servers in the local Active Directory site. The servers may be too busy to accept new connections at this time.
Restarted the submission service and everything works fine now.