Article ID: 2688798 - View products that this article applies to.
Recently, there was an upswing in the consumerization of enterprise information technology together with the increase in consumer-oriented devices such as smartphones and tablets. This is increasing the number of scenarios in which businesses may experience a large increase in legacy authentication in their enterprise environments. This increase in legacy authentication could lead to performance problems such as delays or time-outs for clients.
When you discover authentication time-outs or delays (also known as MaxConcurrentApi bottlenecks) in an environment, the typical way to resolve the problem is to raise the maximum allowed worker threads that service that authentication. You do this by altering the MaxConcurrentApi registry value and then restarting the Net Logon service on the servers.
Identifying which servers are victims of the bottleneck and which servers are actually the source of the bottleneck delays can be difficult. This article describes how to do performance tuning for NT LAN Manager (NTLM) authentication by using the MaxConcurrentApi setting. This article contains guidance for administrators in identifying the servers on which to raise the MaxConcurrentApi value and the amount to which that value should be set.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756To resolve this issue, you must review the performance data that was taken from the all servers that are involved in the scenario. Then, you can try to increase the MaxConcurrentApi setting on those servers that show a loss in performance.
(http://support.microsoft.com/kb/322756/ )How to back up and restore the registry in Windows
Note The only performance data counters that can consistently show the authentication bottleneck are the Net Logon performance object counters. By default, these counters are present in Windows Server 2008 and in later versions of Windows. The Net Logon performance object is discussed in more detail in the following article in the Microsoft Knowledge Base:
928576In order to determine the best MaxConcurrentApi value for your servers, several data points must be brought together and calculated by using a formula. The data to be used to estimate MaxConcurrentApi is as follows:
(http://support.microsoft.com/kb/928576/ )Netlogon counters for Windows Server 2003
(semaphore_acquires + semaphore_time-outs) * average_semaphore_hold_time / time_collection_length = < New_MaxConcurrentApi_settingAfter you collect the Net Logon performance data from when the server was under authentication load, you should determine the duration of the data-collecting process by looking at the Line View beginning and end times.
Note The placeholders semaphore_acquires and semaphore_time-outs represent cumulative numbers that indicate how many time-outs occurred during the lifetime of a security channel. Therefore, the numbers will most likely not start at zero in the data that is collected. The starting number must be subtracted from the ending number when you use Line View in the Performance Monitor (Perfmon.msc). Then, you use this calculated number in the formula for the new MaxConcurrentApi setting. To determine the number of time-outs that occurred during data collection, use Line View in Perfmon.msc, and rest the mouse pointer over the line for that counter at the end and the start, and then subtract the starting number from the ending number. That result is the number to put into the equation.
The average semaphore hold time can be determined by changing the default view from Line View to Report View in Perfmon.msc. For example, consider the following scenario:
(8,286 + 883) * .5 / 90 =< 51
If the value that is derived from the formula is 150 or larger, you should add more servers to service the legacy authentication load.
If the value is less than 150, you should alter the MaxConcurrentApi registry value on that server to the value that is suggested by the formula or to a larger value.
Note If you decide to increase the MaxConcurrentApi value to greater than 10, the load and the performance of the desired setting should be tested in a nonproduction environment before you implement the change in a production environment. This is recommended to make sure that increasing this value does not cause other resource bottlenecks. Additionally, be aware that load conditions may change based on each scenario and business environment. Therefore, the MaxConcurrentApi value may have to have a different setting at a later date if the service load changes.
To change the MaxConcurrentApi setting, follow these steps:
You can use the following Knowledge Base article to identify the client-side symptoms of legacy authentication bottlenecks in more detail:
975363The authentication bottleneck may be on multiple servers in the scenario. Therefore, you must make sure that all servers in a given scenario have their performance data reviewed while they are busy servicing heavy loads.
(http://support.microsoft.com/kb/975363/ )You are intermittently prompted for credentials or experience time-outs when you connect to Authenticated Services
The counters for semaphore acquires, for semaphore time-outs, and for average semaphore hold time must be reviewed on all application servers, domain controllers, and trusted domain controllers that are involved in servicing client requests.
The performance data must be tracked while the servers are under heavy load. Heavy load occurs when the servers see the most client requests. For example, in an email server scenario, the best time to collect the performance data is when users arrive at work and check their email messages.
Additional items for consideration are as follows:
109626Be aware that the Perfmon.msc counter for NTLM authentications under the Security System-Wide Statistics object is not a reflection of the number of uses of the MaxConcurrentApi tracked thread. There is no one-to-one correlation between the MaxConcurrentApi semaphore usage that is shown in the Net Logon performance counter and the NTLM authentication counter increments. The NTLM authentication counter is not useful in determining the best MaxConcurrentApi value.
(http://support.microsoft.com/kb/109626/ )Enabling debug logging for the Net Logon service
Additionally, it is very likely that legacy authentication performance time-outs that are related to MaxConcurrentApi will be seen but not reflected in any performance counter other than the Net Logon counter. This means that other performance metrics such as CPU use and disk and network use may show no load even though the MaxConcurrentApi load is heavy and users are having problems.
An additional minimizing procedure can be performed on domain controllers that have entries in their Net Logon service debug log that indicate that clients are submitting <null>\username instead of domainname\username. This procedure is described in the following article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/923241/ )The Lsass.exe process may stop responding if you have many external trusts on an Active Directory domain controller
Article ID: 2688798 - Last Review: July 24, 2012 - Revision: 5.0