Share via

Recommended Changes and Tweaks for Exchange Servers in an Enterprise Environment (whew!)

  • Article

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: https://support.microsoft.com/kb/938118, https://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Entry: MaxTokenSize
Data type: REG_DWORD
Value: 48000

NOTE: The default for this value in Windows 2012 IS 48000. The maximum value is 65535 - https://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: https://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 https://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 - https://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: https://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.

  • Start Registry Editor.

  • Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  • Create the following registry entry:

    Name: MaxConcurrentApi
    Type: REG_DWORD
    Value: Set the value to the larger number, which you tested (any number greater than the default value).

  • At a command prompt, run net stop netlogon, and then run net start netlogon.

The MaxConcurrentApi SDP is available to help troubleshoot MaxConcurrentApi bottlenecks: https://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. https://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: https://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!!

  1. Click Start and then click Run.

  2. In the Run dialog box, type notepad %systemroot%\Microsoft.Net\Framework64\v2.0.50727\CONFIG\machine.config, and then click OK.

  3. Locate the processModel element that looks like this: <processModel autoConfig="true" />

  4. Replace the processModel element with the following value: <processModel enable="true" requestQueueLimit="65535" />

  5. Save and close the Machine.config file

  6. The above settings modify the global machine.config file. please notes that the below appConcurrentRequestLimit and the above requestQueueLimit are TWO DIFFERENT SETTINGS!

  7. 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

    1. 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)

    2. 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>.

    3. Change the line to <serverRuntime appConcurrentRequestLimit="65535" />

    4. 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 - https://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.

 

<a href="https://s51.sitemeter.com/stats.asp?site=s51technet" target="_top"> <img src="https://s51.sitemeter.com/meter.asp?site=s51technet" alt="Site Meter" border="0"/></a>

Comments

  • Anonymous
    January 01, 2003
    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 technet.microsoft.com/.../bb984870.aspx Is this horse dead yet: NTLM Bottlenecks and the RPC runtime blogs.technet.com/.../is-this-horse-dead-yet-ntlm-bottlenecks-and-the-rpc-runtime.aspx

  • Anonymous
    January 08, 2014
    Kris Waters, one of my great colleagues from the US, originally posted a really neat list of items which