One size does not fit all. The MaxConcurrentApi value may have to be a different value for each server. This situation can be caused by multiple application servers gaining authentication from a single domain controller or by similar scenarios in which multiple servers provide a larger volume of load with which the domain controller must deal.
If the users who are being authenticated are from trusted domains, it can cause longer delays, because the local domain controller must wait for the reply from the trusted domain controller before the local domain controller provides the response to the application server. Network latency. Network latency can also play a major part in causing MaxConcurrentApi bottlenecks. This issue can occur when the MaxConcurrentApi semaphore uses a time-based time-out counter so that clients do not wait indefinitely for legacy authentication.
If network latency exists and is causing delays and bottlenecks in completing MaxConcurrentApi threads, a common solution is to put the servers in the same physical location so that network latency is reduced.
In a domain model in which a trusted domain has Microsoft Exchange CAS servers, for example, and the user's domain is in another region or Active Directory site, it would mean putting the user's domain controllers into the same physical location and Active Directory site as the Exchange CAS servers and their domain controllers. Possible downstream delay. If the Semaphore Waiters counter value is continually greater than 0 zero for any time and the Semaphore Holders value is less than the MaxConcurrentApi setting on that server, the bottleneck is not located on that server.
In this case, look to the domain controller that is cited in the counter name that is listed as a host computer fully qualified domain name. That domain controller's Semaphore Waiters and Semaphore Holders performance data should be reviewed.
Changes in load or in network configuration. Future changes in the load that is being serviced or in network configurations may produce network latency and could lead to a need for gauging the correct MaxConcurrentApi setting again.
For environments in which legacy authentication volume is seen to the extent that MaxConcurrentApi settings are being examined, we strongly recommend that you continually monitor and review the Net Logon performance object counters.
You can do it by using scheduled custom Perfmon. Windows Server maximum. The maximum setting that is allowed for MaxConcurrentApi in Windows Server and in later versions of Windows is Apply the hotfix that is described in the following Knowledge Base article to have the maximum available setting if the server that you are using is not running Windows Server R2: You are intermittently prompted for credentials or experience time-outs when you connect to Authenticated Services.
The maximum setting that is allowed for MaxConcurrentApi in Windows Server and in earlier versions is Windows Server and newer Defaults. It is 10 for member Servers and Domain Controllers. It remains at 1 for member Workstations. Windows Server and performance counters. The original release of Windows Server did not contain the Net Logon performance counters. You can apply a hotfix to add it. Identifying unauthorized or unknown clients or services that are performing repeated and continuous NTLM authentication can be useful when you want to reduce the overall NTLM authentication load and therefore ultimately decrease the number of MaxConcurrentApi semaphore uses.
Repeated authentication in that manner can be identified by using Net Logon service debug logging. For Terminal Services connections, data encryption protects data by encrypting it on the communications link. By default, Terminal Services connections are encrypted at the highest available level of security - bit. However, some older versions of the Terminal Services client application do not support this high level of encryption. The encryption level of the connection may be configured to send and receive data using different encryption levels to support legacy clients.
There are four configuration options as outlined below:. There are four possible values for MinEncryptionLevel that correspond to the settings in the table above:. And with that we come to the end of this post. In tomorrow's post, we'll take a look at Terminal Server printing. Until next time 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, see How to back up and restore the registry in Windows. For Windows clients that support channel binding that are failing to be authenticated by non-Windows Kerberos servers that do not handle the CBT correctly:. There is a known issue with Sun Java which has been addressed to accommodate the option that the acceptor might ignore any channel bindings supplied by the initiator, returning success even if the initiator did pass in channel bindings as per RFC For more information, see ignore incoming channel binding if acceptor does not set one.
We recommend that you install the following update from the Sun Java site and re-enable extended protection: Changes in 1. For Windows clients that support channel binding that are failing to be authenticated by non-Windows NTLM servers that do not handle the CBT correctly, set the registry entry value to 0x Extended protection is accomplished by the client communicating the SPN and the CBT to the server in a tamperproof fashion.
0コメント