Based out of the Boston-Metro area, Justin Alvarez is an IT consultant with over 10 years experience, specializing in Microsoft Exchange and Active Directory. is a technical blog where Justin shares various content including lessons learned in the field, powershell scripts developed, relevant IT news, and the occasional rant from my desk or the datacenter. 

Thank you for subscribing and following! 

TargetBackEnd Throttling - MSExchangeFrontEnd HTTP Proxy

Recently, I found myself in an Exchange 2010 to 2013 transition which required a long period of co-existence. The client had some political reasons behind not moving to 2016 which is besides the point, as I believe this issue also occurs on Exchange 2016. Where did I notice this issue?

Application Event Logs:
Source: MSExchange Front End HTTP Proxy
EventID: 2002
General: {EAS} The number of outstanding requests for guard TargetBackend("FQDNofServer") has exceeded the max limit 150. Current request will be rejected.


When you are operating in a state of co-existence, all of the various Exchange protocols / virtual directories perform some level of proxying, as client requests need to make there way back "home" to the legacy 2010 servers. Exchange 2013 proxies all client connections for mailboxes still homed on the 2010 servers, which is expected behavior in coexistence. However, Exchange has some throttling mechanics that it uses to prevent itself from saturating connections and causing performance bottlenecks.  Looking at the error it's a bit worrisome because it informs you that client requests are going to be rejected, since it's exceeded some threshold. We don't want end-users connections to be rejected, especially when it's the CEO of the company or the person that signs your paycheck! ;) So how do we avoid this problem?!

It is important to note that as of Exchange 2013 CU7, Exchange no longer actually rejects the connection. Instead, it will log this scary error message over and over again, and just silently allows the client's connection through. So can't we just ignore this warning message then? Sure, we could, but I'm a bit OCD and like my logs clean. If you're like me, follow the notes below to increase the proxy limits:

NOTE: I assume no responsibility for any typeo's you may make, so please make a copy/backup of the original web.config files BEFORE editing anything in here.

1. On each and every server running the Client Access Server role edit the following web.config files:

  • $ExInstall\FrontEnd\HttpProxy\sync\web.config (for Activesync / EAS limits)
  • $ExInstall\FrontEnd\HttpProxy\rpc\web.config (for Outlook Anywhere, RPC/http)

In each of those web.config files, create or edit the existing entry in the <appsettings> configuration section of the file where <value> is the limit you want to actually edit (default value will be 150). 

<add key=”HttpProxy.ConcurrencyGuards.TargetBackendLimit” value=”<value>” />

3. After this key is edited, save the file, and recycle the applicable IIS Appplication pool. In this case MSExchangeSyncAppPool and MSExchangeRPCProxyAppPool


These steps needs to be repeated on each and every 2013/2016 Client Access Server in your environment. Also, in case you are wondering, recycling those two application pools won't have any negative impact on any client touch points or user experience. Also, if you're wondering what value you should increase the limit to, you can go up to 500 and increase from there. In my particular case, I pushed it up to 5000 without any negative impact. I hope this helps!

Data Guarantee API & the Mailbox Replication Service (MRS)