none
Your mail <source>:56534-><target>:25 is dropped for Out of Resource Error 2000

    Question

  • I'm getting this error from time to time on certain messages coming in to my Exchange 2013 server.  I've been searching but haven't been able to find any reference to this error message.  It doesn't look like an Exchange error code, they're usually the three numbers but I've discussed it with the people who filter our mail for spam and it looks like the message is being successfully delivered to my server, only to disappear somewhere inside my system.  I can send the message internally and send it outbound but when I try to send it inbound from an external source I get the same error.  The message has a 17MB Excel file attachment but I've set the limits on my connectors a good bit higher than that.  I've tried sending other files, even larger ones and they are transmitted OK.  I know the message has been received by people on other mail servers OK.

    Has anyone here seen this one?


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Monday, September 19, 2016 7:54 PM

All replies

  • Is that text in an NDR message?  Do you have something between the Exchange 2013 server and the Internet that might be generating this error?  Please post the entire NDR and don't obfuscate it.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!


    Tuesday, September 20, 2016 12:29 AM
    Moderator
  • There's no error message such as I would recognise as coming from Exchange.  I can send the email with the Excel attachment to other users on the server and I can send it out to my personal email.  If I try to send it back to my work address all I get is an email with that phrase in it using the IP addresses of the mail servers at either end.  I tried another email with a different attachment of a similar size and that was OK.

    Example:

    REDACTED

    So somehow despite their system being confident it delivered the message, it wasn't delivered.  As I say, the error doesn't look like an Exchange error to me.  The only failure I see is that HAREDIRECTFAIL and I could be wrong but from what I've been reading that's not really a problem, it happens because I have one mail server.

    Any useful suggestions gratefully received. 


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.


    • Edited by Marcus Aurelius Thursday, December 13, 2018 10:00 PM This hasn't provided any useful solution for me.
    Tuesday, September 20, 2016 6:56 AM
  • The error looks like it's being generated by m2.mailwallremote.com.  What is that?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, September 20, 2016 6:16 PM
    Moderator
  • Thank you.  I thought that might be it, given how unfamiliar the error is.  Exchange always does those 1.2.3 ones. Mailwallremote is the spam filter people.  They said their log showed they sent the message.  Can you explain why you think it's them causing the error?


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Tuesday, September 20, 2016 6:25 PM
  • I'm saying that because I've never seen that message in over 20 years of doing Exchange consulting, administration and peer support.  I could be wrong, but I suspect something is corrupting your message before it gets to Exchange.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, September 21, 2016 12:31 AM
    Moderator
  • It's nice to know you agree with me.  I'll feel better about going to argue with them now.  :)

    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Wednesday, September 21, 2016 6:32 AM
  • The discussion continues...  They claim it's not their fault of course.  Can I get a more detailed version of the log?

    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Monday, September 26, 2016 8:25 PM
  • I think a better place is to enable SMTP protocol logging and look at the protocol log.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, September 27, 2016 6:56 AM
    Moderator
  • I have logging set to Verbose in the Receive Connector.  I have the message tracking logs - now all I have to do is find something relevant.

    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Tuesday, September 27, 2016 7:40 AM
  • The message tracking log has this which looks like what I got earlier:

    REDACTED


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.


    Tuesday, September 27, 2016 8:36 AM
  • The SMTP Receive Protocol Log says lots of things but I found one item which might be significant.  Despite the mail having a 17MB attachment, at roughly the time the problem occurred there's this log entry.  At one point it says "250-SIZE 37748736" - does that mean the message is 37748736 bytes or does it indicate the limit?

    REDACTED


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.



    Tuesday, September 27, 2016 8:56 AM
  • It's immediately followed by this entry which looks like something went wrong:

    REDACTED


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.


    Tuesday, September 27, 2016 9:16 AM
  • "2016-09-15T18:57:51.597Z,,08D3C3DAB4877EDC,1,127.0.0.1:25,127.0.0.1:14493,>,421 4.3.2 Service not available,"

    This line is culprit here


    Mihir Nayak If a post is helpful, please take a second to hit the green arrow on the left, or mark as answer, thanks

    Tuesday, September 27, 2016 9:21 AM
  • 127.0.0.1:25,127.0.0.1:14493 - that has to be internal.  There is a firewall on there.  Maybe that got involved?  I've told it to ignore anything to/from 127.0.0.1, that seems like it ought to be safe.  Now for some testing...

    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Tuesday, September 27, 2016 9:37 AM
  • I've completely disabled the firewall and it's still doing it.

    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Tuesday, September 27, 2016 5:21 PM
  • Have you examined the event logs?  Is your server under stress?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, September 28, 2016 6:27 PM
    Moderator
  • I was looking at the Event Logs yesterday.  There are a few of these:

    "Ping of mdb '67fcc8b0-9c9f-40d7-81f7-a22e86667e48' timed out after '00:00:00' minutes.  Last successful ping was at '28/09/2016 13:01:21' UTC."

    The internet seems to think they're not a real problem.


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Thursday, September 29, 2016 7:15 AM
  • As for stress, the server seems to do everything else expected of it without trouble.  I have about 50 users and I do the tests when they're not using it.  The tests fail consistently with this one file.  What strikes me as odd is that if I create another attachment with a larger size it comes through.  Surely if it just couldn't cope that would fail too?

    Today I sent myself a message with an attachment (a 19MB file full of random numbers) which the tracking log says is 27268927 bytes.  That's more than the 24244578 in the message which always fails.  My message came through.

    I thought it might be a scanner but since I have external filtering I have the Malware Agent disabled.  The server has Symantec Endpoint Protection on it, it's supposed to be configured to not interfere with Exchange but I'm beginning to wonder if that might be the problem.  I suppose the only way to find out is to remove it and try again.


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Thursday, September 29, 2016 8:41 AM
  • Bing "exchange 2013 421 4.3.2 Service not available" and you'll get a lot of hits.  Some of them point to the transport service blocking connections because of server stress, which was once known as backpressure.  Do you have enough memory, and is CPU load under control?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Sunday, October 2, 2016 12:50 AM
    Moderator
  • Memory in standard use is at about 50%.  CPU is at about 2%.  Disc usage is less than 50% on the system drive, about 25% on the database drive.  EdgeTransport.exe is at ~725MB (out of 32GB)

    I looked at http://exchangeserverpro.com/exchange-transport-server-back-pressure/ and I've worked through some steps:

    I ran a script which is supposed to help, Test-ExchangeServerHealth.ps1 , it doesn't report any 15006/7 events and says:
    [PS] .\Test-TransportServerBackPressure.ps1

    REDACTED

    So what now?  I can remove the Symantec app, if only to eliminate it from the possibilities.  Any other useful suggestions gratefully received...


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.






    Tuesday, October 4, 2016 11:38 AM
  • https://technet.microsoft.com/en-us/library/bb201658(v=exchg.160).aspx

    "A list of changes that are made to the message queue database is kept in memory until those changes can be committed to a transaction log. Then the list is committed to the message queue database itself. These outstanding message queue database transactions that are kept in memory are known as version buckets. The number of version buckets may increase to unacceptably high levels because of an unexpectedly high volume of incoming messages, spam attacks, problems with the message queue database integrity, or hard drive performance."

    So that's what version buckets are, but it's not happening a lot - is it not something that will happen from time to time anyway?


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.






    Tuesday, October 4, 2016 12:02 PM
  • I tried Get-ServerHealth too, that wasn't much help.  It tells me there a few things which are unhealthy but the remedy, to probe them, results in an error message for which the best explanation I can find is "some of them do that".

    Monitoring\MaintenanceFailureMonitor.Monitoring\

    FEP\MaintenanceFailureMonitor.FEP\ (I don't have FEP)

    DataProtection\DatabaseHealthCircLoggingMonitor\Mailbox Database 1325811692 (I don't want circular logging)

    FrontendTransport\OnPremisesInboundProxyMonitor\

    HubTransport\HubAvailabilityMonitor\

    The suggested next step was to do

    Invoke-MonitoringProbe HubTransport\HubAvailabilityMonitor -Server Exchange13 | Format-List

    That gets me:

    WARNING: Could not find assembly or object type associated with monitor identity 'HubTransport\HubAvailabilityMonitor'. Please ensure that the given monitor identity exists on the server.

    I've also been reading about Event ID 6002:

    http://windowsitpro.com/blog/irritation-mailbox-database-pings-and-event-6002

    http://www.eventid.net/display-eventid-6002-source-MSExchange%20Mid-Tier%20Storage-eventno-11191-phase-1.htm

    https://social.technet.microsoft.com/Forums/exchange/en-US/cfed5d9a-31f3-4b50-bb06-20f42386f1cb/microsoft-exchange-2013-mdb-ping-warning?forum=exchangesvradmin


    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Wednesday, October 5, 2016 12:38 PM
  • I completely removed SEP and the message still doesn't get through, so it wasn't that.  I'm off to find some sort of useful information about how to work out where this 'back pressure' is from.  So far I can't find anything which provides a useful indicator of what the problem might be.

    Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.

    Monday, October 17, 2016 1:39 PM