Wow, that was a mouthful!!!
For my latest project, I decided to try to put together a list of various tweaks that I recommend for Enterprise environments that run Microsoft Exchange Server 2007 x64 or higher. Please remember that these are RECOMMENDATIONS, not hard and fast guidelines! YMMV, please test these yourself, etc. The main goal here was to consolidate these recommendations into one place, rather than having to visit various blogs and TechNet articles to piece them all together.
Many of the settings described herein are the defaults that were in place for 32 bit (x32) systems (i.e., Windows 2000/2003).They were never increased in the x64 versions of the product. Proactively increasing these values can help insure that x64 servers are more fully utilized.
Please visit my colleague Rhoderick Milne's blog post for a few additional recommendations!
Windows: MaxTokenSize – this setting can affect users with large tokens (also known as "token bloat") . The default value is low, imo, and the issue can be very frustrating to troubleshoot. The following article recommends setting the default to 48,000: http://support.microsoft.com/kb/938118, http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\ParametersEntry: MaxTokenSizeData type: REG_DWORDValue: 48000
NOTE: The default for this value in Windows 2012 IS 48000. The maximum value is 65535 - http://support.microsoft.com/kb/938118
IIS: MaxFieldLength and MaxRequestBytes – these settings control the maximum header length and maximum number of bytes that are allowed in http headers. Users with large tokens can experience logon failures if the defaults are left in place. This article discusses those concerns: http://support.microsoft.com/kb/2020943
From the above referenced KB:
NOTE: If MaxFieldLength is configured to its maximum value of 64KB, then the MaxTokenSize registry value should be set to 3/4 * 64 = 48KB. For more information on the MaxTokenSize setting, please see the Microsoft knowledge base article KB327825. Note that many of settings detailed in this post are interrelated.
Article http://support.microsoft.com/kb/2491354 for Exchange server details a free/busy issue that can be caused by low/default values for these settings, and reccommends setting them to their maxiumum allowed values of 65534 for MaxFieldLength and 16777216 for MaxRequestBytes
IIS: Queue Length for IIS application pools - I recommend changing the queue length value to at least 5000 (which is now the default) for all Exchange related application pools (Found in Advanced Settings on the properties of the Application Pools themselves). If you are still running Exchange 2007, your Queue Length is likely still at 1000. For example, if your application has its own App pool (such as OWAAppPool), the Advanced Settings of that App pool are where you would make this change. I have seen customers set this value higher (8000 or so) with no ill effects. PLEASE TEST IN YOUR ENVIRONMENT BEFORE MAKING DRASTIC CHANGES!
The following article describes the effects on Lync of leaving the default value of 1000 in place - http://technet.microsoft.com/en-us/library/dd441171(v=office.13).aspx
To set the Queue Length for ALL app pools via appcmd, the syntax is as follows:
“%systemroot%\system32\inetsrv\appcmd.exe set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.queueLength:"5000" /commit:apphost”
- Many thanks to Finbar Ryan for contributing this syntax!
Windows: MaxConCurrentAPI (On DC’s) – this setting affects certain types of authentication traffic (particularly NTLM) and is described here: http://support.microsoft.com/kb/975363.
The maximum value on either 2003 OR 2008 DC’s of any version (without the hotfix mentioned in the article) is 10, and I see no reason at all not to set ALL DC’s to this value, rather than leaving them at the default of 1. Please READ the article before making this change.
The MaxConcurrentApi SDP is available to help troubleshoot MaxConcurrentApi bottlenecks: http://support.microsoft.com/kb/2709071
IIS: ASP.NET Request Queue Limits - (requestQueueLimit and appConcurrentRequestLimit)- Changing the request queue limit to 65,535K is known to resolve an issue that primarily exhibits itself on Exchange 2010 sp3 and above. However, there are other circumstances where changing this limit could be beneficial, and is another example of something that could be proactively changed before any box is put into production. http://technet.microsoft.com/en-us/library/dd425294(v=office.13).aspx (Lync article) says to set the limit for requestQueueLimit to 15,000. However, testing by the Exchange team has validated that a limit of 65,535 poses no problems in most circumstances.
As it specifically relates to Exchange, a change was made in the way Outlook Anywhere in SP3 and above traffic is processed that can cause it to bottleneck in ASP. This is typically seen only in very large environments, but I included this section anyway (just for thoroughness). In coming versions of Exchange, the rpc/http configurator will automatically set the requestQueueLimit to 65535 but ONLY for the rpc virtual directory. Thus, this it will be set not at the root level (as we are doing below), but at the rpc virtual directory level, so you will find the change in the web.config file specifc to the rpc virtual directory. See my IIS7 primer for more information about config files: http://blogs.technet.com/b/kristinw/archive/2012/11/28/iis7-primer-for-non-iis-admins-originally-written-for-exchange-engineers.aspx
To modify the values, do the following (copied from the above referenced TechNet article):
PLEASE MAKE A BACKUP OF THE CURRENT FILES BEFORE MAKING ANY CHANGES!!
Click Start and then click Run.
In the Run dialog box, type notepad %systemroot%\Microsoft.Net\Framework64\v2.0.50727\CONFIG\machine.config, and then click OK.
Locate the processModel element that looks like this: <processModel autoConfig="true" />
<processModel autoConfig="true" />
Replace the processModel element with the following value: <processModel enable="true" requestQueueLimit="65535" />
<processModel enable="true" requestQueueLimit="65535" />
Save and close the Machine.config file
The above settings modify the global machine.config file. please notes that the below appConcurrentRequestLimit and the above requestQueueLimit are TWO DIFFERENT SETTINGS!
Now to edit the ApplicationHost.Config, in the Run dialog box, type %systemroot%\system32\inetsrv\appcmd.exe set config -section:System.Webserver/serverRuntime -appConcurrentRequestLimit:65535 -commitpath:APPHOST
If you have problems running the above command (some people have reported errors trying to run the command in virtual environments), you can manually make this change by locating the ApplicationHost.Config file in %systemroot%\system32\inetsrv\config directory. (You can also check this file to verify the change)
After locating the file AND MAKING A BACKUP COPY, open the file and search for serverRuntime until you find the one that looks like this: <serverRuntime />, located just underneath </security>.
Change the line to <serverRuntime appConcurrentRequestLimit="65535" />
Save and close the file.
NOTE: You are likely to hit other bottlenecks (notably port exhaustion) long before you ever hit the 65535 value noted in this post. This value CAN be set higher if you have configured port scaling.
PLEASE BE SURE THAT YOUR DO NOT FAT FINGER ANYTHING IN THE Machine.Config or ApplicationHost.config file!!! Bad things will happen if you do!
IIS - Speeding up Integrated Authentication
The following is courtesy of Greg Askew. The logic here is that certain web services within Exchange primarily use integrated authentication (internal OWA, EWS, anything OTHER than basic or anonymous auth). An easy way to determine what type of authentication a particular web service is using is to ask this question: upon initially hitting the site or service, does the get prompted for a username/password? If the answer is yes (this includes mobile devices that 'store' such information), then its probably integrated authentication of some type.
If integrated authentication is used extensively (NTLM or Kerberos) and there are lots of connections, IIS can be configured to authenticate ONLY the first request by using the following command:
appcmd set config /section:windowsAuthentication /authPersistNonNTLM:true
You may experience slow performance when you use Integrated Windows authentication together with the Kerberos authentication protocol in IIS 7.0 - http://support.microsoft.com/kb/954873
Kerberos authPersistNonNTLM authentication, request based vs. session based authentication - https://blogs.msdn.com/b/benjaminperkins/archive/2011/10/31/kerberos-authpersistnonntlm-authentication-request-based-vs-session-based-authentication.aspx
Many thanks to Casey Spiller, Steve Wesa, Chris Korff, David Santamaria, Finbar Ryan, Konstantin Papadakis and Greg Askew for contributing to these recommendations.
Please note: Increasing MaxConCurrentAPI at Exchange CAS Server is even more important than increasing MaxConCurrentAPI only on DCs (especially in a Single Domain Forest).
More Information WHY will be found a.o. in the following articles (initial using the example of a comparable scenario with ISA/TMG):
Improving Web Proxy Client Authentication Performance on ISA Server 2006
Is this horse dead yet: NTLM Bottlenecks and the RPC runtime