Exchange 2013 SMTP Throttling

I am in the process of migrating to Exchange 2013 SP1 from 2010 SP3.  In my environment, I have several .NET applications that authenticate to Exchange as an internal Exchange user and attempt to relay large amounts (1000+) messages through one of my receive connectors.  Most of these messages are bound for internal users, but there are a few that traverse my outbound send connector.  In Exchange 2010, this setup worked flawlessly.  As soon as I redirect my applications to the new Exchange 2013 server, I start getting the behavior described below.


<<Begin>>
UG Application notifications sent to intended recipients at 8/6/2014 1:00:17 AM
AU-ABC or BAS/BCM Application notifications sent to intended recipients at 8/6/2014 1:00:18 AM
Grad Application notifications sent to intended recipients at 8/6/2014 1:00:20 AM
ERROR: email@domain.com SmtpException: Service not available, closing transmission channel. The server response was: 4.4.2 Message submission rate for this client has exceeded the configured limit…

And then the last line begins repeating for multiple email addresses.
<<END>>

So, my first thought was that this must be a symptom of either the anti-spam or anti-malware transport agents, as I have both of these installed in my environment.  I have disabled both agents and am still experiencing the problem.  I am now thinking that this is a result of some kind of change in the throttling behavior of the transport service.  I would like some other opinions before I start to dismantle my transport service.  I also discovered that the "Get-TransportService" cmdlet has no equivalent in 2010.  Any ideas on how to get this working?
LVL 1
marrjAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

imkotteesSenior Messaging EngineerCommented:
marrjAuthor Commented:
Yes, I saw that post.  My limits far exceed the defaults in Exchange and exceed the numbers I am trying to achieve.  I did try deleting and recreating the receive connector.  No luck.  Any more advice?

Mine seems to choke after only three messages.  There are only ~150 messages that are trying to go out.  Yes, the messages are all going out at a rapid rate.  I've increased my receive connector's message rate limit to 12000 to match my organizational config limit of 12000.  Still no luck.
marrjAuthor Commented:
Upon further investigation, I don't believe I'm having a receive connector issue.  I enabled verbose logging for the connector in question, only to find that the message seems to relay through the frontend perfectly (this is a frontend receive connector).  What I found in the frontend send protocol log are messages saying "Inbound Proxy Internal Send Connector,08D18072EB9A2BD6,1,,HT_IP:2525,*,,"Failed to connect. Winsock error code: 10061, Win32 error code: 10061, Error Message: No connection could be made because the target machine actively refused it HT_IP:2525"

So, it looks like my receive connector is working.  The message is getting rejected at the hub or somewhere else.  Any ideas on how to get more information.  I only have one server.  It has all roles installed.
marrjAuthor Commented:
http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-97-19/6153.1.png

I think I've figured this out.  Apparently, there is a new receive connector for proxied requests in 2013 that did not exist in 2010.  Once I figured this out, I was able to adjust the MessageRateLimit to fit my needs.  The default value is 5.  This means that any frontend receive connector that depends on the frontend service to proxy requests to internal mailboxes will pass through this internal connector as well.  In a coexistence scenario, this is over TCP 2525.  

So, my issue did turn out to be a receive connector limitation, just not a frontend connector limitation.  Messages are flowing smoothly now.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
marrjAuthor Commented:
I did the research myself.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.