HTTP Proxy TargetBackEnd limits

Posted on December 22, 2015 by Michel de Rooij

powershell Last Update: February 4th, 2016

When deploying Exchange 2013 or Exchange 2016 in co-existence with a legacy version of Exchange, there comes a point where all traffic is routed through Exchange 2013/2016. Traffic for mailboxes hosted on legacy Exchange versions will be proxied by Exchange 2013/2016 to the back end.

This proxy process has some built-in limits for certain protocols, which you could encounter. Symptoms of these limits are Event 2022’s being logged in the Application log by the MSExchange Front End HTTP Proxy service:

Per Exchange 2013 CU7, this message should be considered a notice, despite the confusing event description. No connections are being blocked. However, the events create noise in your logs, which can be prevented by raising these limits. To accomplish this, you need to dive in to the web.config of the applicable HTTP Proxy protocols:

$ExInstall\FrontEnd\HttpProxy\sync\web.config (for ActiveSync, EAS)
$ExInstall\FrontEnd\HttpProxy\rpc\web.config (for OA, RPC/http)

In those files, create or adjust the entry in the <appsettings> configuration node, where <value> is the limit you want to configure (default is 150):

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

After adjusting these values, recycle the relevant application pools, e.g. MSExchangeSyncAppPool and MSExchangeRPCProxyAppPool.

The above steps need to be performed on all Exchange 2013/2016 Client Access Servers.

To automate this process of tedious editing in web.config files, I have created a small script which lets you alter these values for EAS and RPC against the local server or remotely. The script, Configure-HTTPProxyTargetBackEnd.ps1, has the following parameters:

Server to specify server to configure. When omitted, will configure local server.
AllServers to process all discoverable Exchange Client Access servers
TargetBackEnd specifies Target Backend limit (default 150).
NoRecycle to prevent recycling the MSExchangeSyncAppPool and MSExchangeRPCProxyAppPool

For example, to configure the local server with a limit of 2000 for Exchange Active-Sync and RPC access, use:

.\Configure-HTTPProxyTargetBackEnd.ps1 -TargetBackEnd 2000

Note that the script will create a backup copy of the web.config files before editing, using the current timestamp.

Download
You can download the script from the TechNet Gallery here.

Feedback
Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.

Revision
See TechNet Gallery page.

Exchange 2010 CAS workloads paper

Posted on August 17, 2010 by Michel de Rooij

The Exchange team at EHLO released a nice paper in the TechNet library on the subject of Client Access Server workloadson Exchange Server 2010. This paper is to illustrate the effect of using different client modes with different protocols (i.e. Outlook Cached Mode yes/no, Outlook Anywhere, OWA, POP, IMAP, ActiveSync). It also shows the differences between using Windows Server 2008 SP2 and Windows Server 2008 R2 in combination with these protocols.

Some examples:

For Outlook Anywhere, the CPU usage per user on CAS servers almost quadruples around 6.000 users when comparing SP2 against R2;
For Outlook Anywhere, CPU usage for AD/Hub/Mailbox starts to flatline at 3.000+ users;
For Outlook Anywhere, as you probably already knew, it is recommended to use Windows Server 2008 R2;
For IMAP, the mailbox size is of big influence on the CPU usage;
For POP3, the number of Mailbox IOPS drops as the number of users increases;

They also perform a comparison between Exchange Server 2007 SP1 and Exchange Server 2010 regarding IMAP. For example, CPU usage on CAS servers when using IMAP clients is reduced by 40% and memory bij 30%.

What does puzzle me is that in some comparisons they left out certain measurements and some graphs are missing scale information. For instance, the graph for Total CPU consumption for IMAP4 has SP2 start at 37.000 while R2 starts at 12.000. Why? Did SP2 produce some weird results or is it off the scale? The paper doesn’t mention it.

Nevertheless, interesting stuff.

You can read the whitepaper here. Unfortunately, there’s only an online version of the paper.

Configure External Client Access Domain

Posted on January 31, 2010 by Michel de Rooij

Many articles on (re)configuring Exchange 2007’s internet-facing Client Access Server contain steps to (re)configure all external URLs. Most of the times this is a list of one or more of the following cmdlets to execute:

Set-OWAVirtualDirectory –Identity <CASSERVER>\OWA (default web site) -ExternalURL https://someURL/OWA
Set-OABVirtualDirectory –Identity <CASSERVER>\OAB (default web site) -ExternalURL https://someURL/OAB
Set-WebServicesVirtualDirectory –Identity <CASSERVER>\EWS (default web site) -ExternalURL https://someURL/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Identity <CASSERVER>\Microsoft-Server-ActiveSync (default web site) -ExternalURL https://someURL

In Exchange 2010 this process has been made easier because Exchange 2010 setup will ask you if it’s an “external facing” Client Access Server, after which it will configure externalURLs for you. But what if you want to reconfigure the setting afterwards? Exchange 2010’s Configure External Client Acess Domain to the rescue! To access it, start Exchange Management Console, expand Server Configuration and select Client Access node. Now either click Configure External Client Access Domain in the right pane or select it after right-clicking.

After entering the new external domain and adding the Client Access Server(s) to which to apply the setting, click Configure.

As you can see from the progress windows, the new URL will be set as ExternalURL for the virtual directories. Note that you can ignore the warning on setting the ExternalURL identical for ‘owa’ and ‘ecp’ to the same value using Set-ECPVirtualDirectory, because the wizard will do that for us.