Sign in
 
HomeOnline20132010Other VersionsLibraryForumsGalleryEHLO Blog
TechCenter >
> 
> 
#550 4.4.7 QUEUE.Expired; message expired ## With LastError "A storage transient failure has occurred during content conversion." In submission Queue. (Exchange 2013)

Answered #550 4.4.7 QUEUE.Expired; message expired ## With LastError "A storage transient failure has occurred during content conversion." In submission Queue. (Exchange 2013)

  • Friday, December 21, 2012 3:54 PM
     
     
    Sign In to Vote
    1

    Greetings,

    We seem to be having a problem with some users who are attempting to send e-mails from within the organisation to an external domain. Not all users are affected, and not all outgoing e-mails have this issue.

    Some e-mails get stuck in the submission queue. This is the error message in Last Error : "A storage transient failure has occurred during content conversion."

    Days later, the internal user who send the message gets a #550 4.4.7 QUEUE.Expired; message expired ## NDR.

    We did have some initial configuration issues, but these were fixed more than a week ago :
    - The external FQDN during EHLO was set to the wrong address, now pointing to the correct one.
    - SPF record was updated with new IP adress.

    Here is some additional information on the issue :
    - Not on any blacklists - checked using dnsbl.info
    - Telnet to remote servers works from exchange server, connections are accepted and can send mail.
    - Outbound SMTP test ran using Microsoft Remote Connectivity Analyser : Passed with both External (Static) and Smarthost IP.
    - This seems to happen only with emails that have an attachment and that are transfered, but only for the affected users. 
    - If content from these e-mails is manually copied over to a new email, email is sent to destination without problem.

    Configuration information :
    - Exchange 2013 running on Windows 2012 Datacenter with all latest updates.
    - Outgoing e-mail is sent via smarthost. Only one outbound transport rule is active.
    - Using internal DNS server.
    - There is only one mailbox database.

    Thank you for taking the time to read this!

     

All Replies

  • Monday, December 24, 2012 2:26 AM
    Moderator
     
     
    Sign In to Vote
    0

    Hi

    This problem occurs because the email message in the queue expired. In this situation, the sending server tries to relay or deliver the email message. However, the action is not completed before the message expiration time occurs.

    Please have a look on this KB

    http://support.microsoft.com/kb/2625264?wa=wsignin1.0

    Also, you can have a try restart the Transport Agent.

    Hope it will help

    Merry Christmas

    If you have any feedback on our support, please click here

    Zi Feng
    TechNet Community Support

     
  • Monday, December 24, 2012 4:02 PM
     
     
    Sign In to Vote
    0

    I am experiencing the same issue, messages intermittently stuck in submission queue.  The ONLY difference is that I am running Exchange 2010 SP2 on Server 2012 Standard.

    All other conditions are the same, I too initially had incorrect EHLO response . I am using Barracuda appliance as Smart Host. Tested though smarthost and direct dns submission. Protocol logging on the send and receive connectors did not capture any relevant data.

    I opened a ticket with Microsoft on 12/21/12. We were unable to resolve the issue on Friday. My issue is being escalated and will continue to troubleshoot this week.

     
  • Monday, December 24, 2012 7:14 PM
     
     
    Sign In to Vote
    0

    Thank you for your reply Zi Feng,

    Unfortunately, I don't think the link you provided applies in this case.

    The messages that are bouncing back these NDRs have 1-5 recipients at most. Size is well under the message size and attachment size limits of both our exchange server and smarthost. As for the message header size, it would be hard to check, but this error also happens on messages just received that are not part of a long conversation of messages, and are replied to for the first time. Also, we do not use FOPE in our environment. I've noticed that Exchange 2013 does have some e-mail security features similar to FOPE, but they are all disabled at this time.

    What really strikes me is that when the content and attachment of the messages is copied into a new e-mail and sent to the same recipients on the external domain (Hotmail being one of them), the e-mail does not get stuck in the submission queue.

    Could there be some kind of corruption within the mailbox itself, or the mailbox database?

    Once I get some time, I will try and create a new mailbox database and move one of the affected user's mailbox into it, see if I get any errors or change in behavior.

    Darrell, I am "glad" to see I am not the only person having this issue. Let me know how things pan out with your Microsoft ticket. I was planning on opening one after the holidays if I was unable to remedy the issue.

    I'll report back when I have additional information.

    Happy Holdiays!

     
  • Monday, December 24, 2012 7:15 PM
     
     
    Sign In to Vote
    0

    Darrell, I am "glad" to see I am not the only person having this issue. Let me know how things pan out with your Microsoft ticket. I was planning on opening one after the holidays if I was unable to remedy the issue.

    See my reply to Zi above yours for a bit more information.

    Happy Holdiays!

     
  • Wednesday, December 26, 2012 6:09 AM
    Moderator
     
     
    Sign In to Vote
    0

    Hi Darrell

    Any result after escalation？

    Cheers

    If you have any feedback on our support, please clickhere

    Zi Feng
    TechNet Community Support

     
  • Monday, January 07, 2013 4:46 PM
     
     
    Sign In to Vote
    0
    I've got users on an SBS 2011 box getting the same error.  So Exchange 2010 on Windows 2008R2 basically.  Any updates?
     
  • Monday, January 07, 2013 5:11 PM
     
     Answered Has Code
    Sign In to Vote
    2

    Hello All,

    I have an interesting update that may help some of you.

    After new years, I was left with little choice but to open a ticket at Microsoft to resolve this issue. After a few days of testing and looking at the issue, this is what came up.

    It seems Microsoft disables Rich Text Format e-mails to external domains. You can enable it by running the following command in powershell :

    Get-RemoteDomain | Set-RemoteDomain -TNEFEnabled $true

    Followed by a restart of the msexchangetransport service.

    Under Exchange 2007-2010, it may be possible to use the MMC to enable it as well.

    I've been having some problems with email formats in Exchange 2013 since installation. Some scanned PDFs from our photocopiers are arriving inline with no attachements...


     
  • Monday, January 07, 2013 8:20 PM
     
     
    Sign In to Vote
    0

    Hello,

    We had the same problem with exchange 2013. This is the answer !!

    Afther applying the command the mail que and restarting the service, the mail was sending out !!!

    Thanks for sharing this !!

    Greetings

    Chris

     
  • Friday, January 11, 2013 9:06 PM
     
     
    Sign In to Vote
    0

    Since the modification to our server using the solution provided by this ticket, we have been experiencing issues with attachments sent to external domains.

    They seem to be getting attachments inline (described as "computer code" by my users) and some have a winmail.dat file instead of the actual attachment.

    This seems to have something to do with rich text formats being enable by the fix provided to me by microsoft.

    Anyone else experiencing this?

     
  • Sunday, January 13, 2013 9:51 AM
     
     
    Sign In to Vote
    0
    Yes indead we have the same problem. Recievers complains about winmail.dat in the mail. Makes it unreadable.
     
  • Sunday, January 13, 2013 10:16 PM
     
     
    Sign In to Vote
    0
    On Fri, 11 Jan 2013 21:06:46 +0000, Ipigi wrote:
     
    >
    >
    >Since the modification to our server using the solution provided by this ticket, we have been experiencing issues with attachments sent to external domains.
    >
    >They seem to be getting attachments inline (described as "computer code" by my users) and some have a winmail.dat file instead of the actual attachment.
    >
    >This seems to have something to do with rich text formats being enable by the fix provided to me by microsoft.
    >
    >Anyone else experiencing this?
     
    Lots of sites have this problem. Stop sending messages in RTF. The
    problem is that the receiving domain doesn't understand how to deal
    with the contents of the winmail.dat file. They can ignore it and just
    show the recipient the message text without the fancy formatrting, but
    they're treating the contents of the file as if it's the "real"
    message and displaying that instead. It really isn't your server
    that's the problem, it's the receiving server.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
     
  • Monday, January 14, 2013 4:46 PM
     
     
    Sign In to Vote
    0

    Agreed Rich,

    The issue is that my users aren't sending e-mails as RTF, they transfer e-mails they recieve from external domains back to an external domain. Could it be that the external senders are sending in RTF and my server is not converting them to HTML/Plain?

    Ideally, I would love to get rid of RTF and disable TNEF.

    Ultimately, both problems are a symptom of a larger issue. Transferred messages are being sent as RTF for some reason, initially causing the stalling of message in the submission queue. Enabling TNEF "fixed" that, but not the root cause.

    I've read that it's possible to force contacts to use a specific formatting type. Would it be possible to set this using group policy and force outlook to always send in HTML, even if the original message is in a different format?

     
  • Tuesday, January 15, 2013 12:55 AM
     
     
    Sign In to Vote
    0
    On Mon, 14 Jan 2013 16:46:09 +0000, Ipigi wrote:
     
    >
    >
    >Agreed Rich,
    >
    >The issue is that my users aren't sending e-mails as RTF, they transfer e-mails they recieve from external domains back to an external domain. Could it be that the external senders are sending in RTF and my server is not converting them to HTML/Plain?
    >
    >Ideally, I would love to get rid of RTF and disable TNEF.
    >
    >Ultimately, both problems are a symptom of a larger issue. Transferred messages are being sent as RTF for some reason, initially causing the stalling of message in the submission queue. Enabling TNEF "fixed" that, but not the root cause.
    >
    >I've read that it's possible to force contacts to use a specific formatting type. Would it be possible to set this using group policy and force outlook to always send in HTML, even if the original message is in a different format?
     
    You'll have to explain what those people are doing. Saying "they
    transfer e-mails they recieve from external domains back to an
    external domain" provides no details.
     
    You can certainly change the format in which Outlook composes
    messages, but "transfering" messages isn't "composing" them.
     
    http://anandthearchitect.wordpress.com/2011/05/09/exchange-2010-winmail-dat-attachment-to-internal-applications/
    http://www.slipstick.com/problems/outlook-is-sending-winmail-dat-attachments/
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
     
  • Wednesday, January 16, 2013 3:31 PM
     
     
    Sign In to Vote
    0

    Sorry, I often get some terms mixed up when I explain things as our users use the French version of outlook.

    E-mails are not transferred, but forwarded manually from their outlook. Message format in outlook is set to HTML and not Rich Text when they foward the e-mail.

    When forwarded internally, this is in the internet headers :

    Content-Type: application/ms-tnef; name="winmail.dat"
    Content-Transfer-Encoding: binary

    It really seems to me that Exchange is not converting RTF to Plain Text. The first link you provided states in it's final paragraph that Exchange should be doing this conversion.

    If I disabled TNEF as that link suggests, offending messages will get stuck in the submission queue again.

    I thank you for your help so far. This is not an issue I've had with any previous installations/migrations of Exchange that I have done.

    Please let me know if you need any additional information.

     
  • Thursday, January 17, 2013 5:09 PM
     
     
    Sign In to Vote
    0
    On Wed, 16 Jan 2013 15:31:14 +0000, Ipigi wrote:
     
    >Sorry, I often get some terms mixed up when I explain things as our users use the French version of outlook.
    >
    >E-mails are not transferred, but forwarded manually from their outlook. Message format in outlook is set to HTML and not Rich Text when they foward the e-mail.
     
    Do they forward the message as an attachment?
     
    >When forwarded internally, this is in the internet headers :
    >
    >Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary
     
    Within your organization I'm prety sure that messages will use TNEF.
    What does the message contain at the external recipient's side?
     
    >It really seems to me that Exchange is not converting RTF to Plain Text. The first link you provided states in it's final paragraph that Exchange should be doing this conversion.
     
    If you can, try creating a mail-enabed Contact for one of the external
    recipients and set the message format on that.
     
    >If I disabled TNEF as that link suggests, offending messages will get stuck in the submission queue again.
    >
    >I thank you for your help so far. This is not an issue I've had with any previous installations/migrations of Exchange that I have done.
    >
    >Please let me know if you need any additional information.
     
    Have you tried UNsetting TNEF on the remote domain?
     
    Set-RemoteDomain Default -TNEFEnabled $null
     
    That should leave it up to the client to determine the format. It's
    probably not what you're after, but see it makes a difference in the
    format.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     
    --- Rich Matheisen MCSE+I, Exchange MVP
     
  • Friday, January 25, 2013 10:01 AM
     
     
    Sign In to Vote
    1

    Hi All ,

    Afther a while of testing I think the command should be :

    Get-RemoteDomain | Set-RemoteDomain -TNEFEnabled $False

    If you look into the exchange server standard settings its $null. This means outlook determine the format (RTF or HTML)  If you say $True then the transport agent puts the mail if it is in RTF  into TNEF causing some recievers to recieve winmail.dat mails.

    I have change the settings to $False -> I always want RTF converted to HTML. I have no complaints anymore of winmail.dat and the mail isn't stuck into the mailques. You can even see in the headers that the exchange agent coverted the mail from RTF to HTML.

    Greetings
    Chris

     
  • Thursday, February 21, 2013 11:56 AM
     
     
    Sign In to Vote
    1

    Hello All,

    We have seen this issue also, so far we have two new Exchange 2013 Standard installations for two separate companies.

    After about 2 weeks from when the Exchange servers are put in production, all of a sudden random e-mails are stuck in a retry state under the Submission queue with the error "A storage transient failure has occurred during content conversion."

    Tried a few different things to figure out why this is happening including deleting and recreating all queues, swapping between smarthost and MX sending.

    So far after changing TNEF to True, then False and then back to Null (default) we haven't seen the issue re-occur on our first site.

    Now we wait and hope this issue doesn't come back...

    Regards,

    Lyndon.

     
  • Thursday, February 28, 2013 9:25 AM
     
     
    Sign In to Vote
    0
    We're seeing the same issue, Outlook 2010 and 2013 running with Exchange 2013 on Windows Server 2012. Ipigi's workaround stopped the issue, but I would prefer to run with -TNEFEnabled set to $null, this bug needs to be fixed.
     
  • Thursday, March 21, 2013 11:45 AM
     
     
    Sign In to Vote
    0

    This has also allowed me to work around the situation but really exchange should do the conversion correctly in the first place.

    my install is a fresh exchange 2013 and sever 2012 install.

    this will be bug number 8 for me.

     
  • Wednesday, April 03, 2013 2:21 AM
     
     
    Sign In to Vote
    0
    Anyone implemented CU1 yet? Have you noticed whether this issue has been fixed?
     
  • Friday, April 05, 2013 5:06 PM
     
     
    Sign In to Vote
    0
    Looking good so far...
     
  • Friday, April 12, 2013 6:12 PM
     
     
    Sign In to Vote
    0
    CU1 seems to have resolved this issue for me.