Hi folks!
I’m due for my (now) semi annual blog post, and I have a pretty good one. Short and sweet.
Remember my blog posts about MaxConcurrentApi problems? Well, of course not but they are here and here so you can read them now.
I’m certain you read these fine blog posts about the same issue written by my esteemed colleagues here and here though. And, of course, the TechNet wiki here .
One of the toughest things to understand is which servers are involved in a NTLM or PAC validation bottleneck like a MaxConcurrentApi scenario has and how bad things are. Of course you can view the Performance Monitor stuff but it’s not exactly an intuitive interface.
To help make these issues easier to detect and understand I wrote a PowerShell script. It’s available at the TechNet Script Center here . It can help you find if the problem is effecting a particular server, and if it is it will tell you what the MaxConcurrentApi setting for your server should be . Cool, right?
Here’s some details about the script (which I also posted there ).
To help make the problem easier to detect I wrote this PowerShell script. Run this script against a server to find out if it is having a MaxConcurrentApi problem or not. It can be ran remotely against a member server or domain controller. It can also be called via another script to check an array of servers.
The script has two switches, -CheckMaxConcurrentApi and –GetNetlogonInstances, and optional parameters of Computer, Instance or CalcMCA. InstanceName (defaults to “_Total”), ComputerName (defaults to “localhost”) and Calc (defaults to $false).
The script contains two functions: CheckMaxConcurrentApi and GetNetlogonInstances. You can pull the functions out and use them in other scripts, or you can use them as is by calling this script.
- The CheckMaxConcurrentApi function uses a combination of .Net methods and WMI. It should work fine on Server 2008 and up.
- The function checks registry value, presence of hotfix, OS version, and performance counters and produces a summary of the “MaxConcurrentApi” state of the computer.
- The GetNetlogonInstances function uses .Net to query for a computers secure channels by way of parsing the Netlogon Performance instances. On a domain member it will return one domain controller, but on a domain controller it will return one per trusted domain.
- Administrator privileges are required on the computer you are running the script against.
And a sample of what the script will get for you.
.CheckMaxConcurrentApiScript.ps1 -checkmaxconcurrentapi -Computer "2K8member2" -CalcMCA $true
In the sample above, the server TSPRING3 returned that the problem was detected. It also shows that it has had 3.2 million semaphore acquires (that’s usually just clients getting their password validated for an NTLM authentication) in well, almost immediately since the server had just been rebooted. 1679 users are currently waiting for the authentication to finish, and since the server was rebooted 1679 have gotten errors or credential prompts. On top of that we now know what a suggested MaxConcurrentApi setting (set via the Registry) is for that server. Note that 1679 is an artifact of the technique used to reproduce the problem and would be a really unique roll of the dice in real life on your servers.
Go forth and have MaxConcurrentApi bottlenecks no more, my friends!