Spat's WebLog (Steve Patrick)

When things go wrong...

MaxConcurrentAPI update - monitor the netlogon secure channel ... finally!

MaxConcurrentAPI update - monitor the netlogon secure channel ... finally!

  • Comments 4

Edit 11/21/2011 NOTE: Please see http://support.microsoft.com/kb/975363 for updated informaton

Here is something which will be very very useful for a lot of larger IT shops.

 

It is a DCR which implements perfmon counters to monitor netlogon  performance, specifically the  scenario I discussed last year.MaxConcurrentAPI - or, how fast can you authenticate users?

 

 

 Here was a comment on my previous blog entry:

 # re: MaxConcurrentAPI - or, how fast can you authenticate users?
In the truted domains scenario, how is possible to verify the effect of this Key? Perfomon "NDTS\NTLM Authentications" item could be useful?
It could be nice to have a performance baseline before regkey optimization and after.

 

 

Well here we are…

 

The new code is available via a hotfix  928576 – don’t bother looking for a public KB yet – there isn’t one ( but should be out there soon )

 

In the meantime.. a little info about the fix.

Once you install it, ideally on all DC’s since you don’t know which one is going to be servicing secure channel traffic for a given client – then you need to register the perfmon counters via the following command:

 

         C:\WINDOWS\system32>lodctr nlperf.ini

 

 

When you have done this you can then monitor the status of the semaphore which specifies the maximum number of simultaneous, logon-related, application programming interface (API) calls that can be transmitted across a secure channel at any one time.

 

Here is a simple screenshot – I have one domain trust here…

 

 

C:\WINDOWS\system32>nltest /sc_query:single

Flags: 30 HAS_IP  HAS_TIMESERV

Trusted DC Name \\SAMME3J7

Trusted DC Connection Status Status = 0 0x0 NERR_Success

The command completed successfully

 

 

 

 

 

Average Semaphore Hold Time

Each time the semaphore is acquired we start a timer and when it is released we stop it. We take that value and divide it by the total number of times the semaphore has been acquired in order to provide you this average number of the hold time in seconds.

 

 

SemaphoreWaiters

 This counter tracks the current number of threads that are currently waiting on the semaphore at any given point in time.   

 

SemaphoreHolders

This counter tracks the current number of threads that are currently holding the semaphore at any given point in time.

 

SemaphoreAcquires

This counter tracks the total number of semaphore acquisitions that have occurred on the Secure Channel since the last time it connected.  For the '_Total' instance this counters is from system boot.  This counter gets  incremented at the time the semaphore is released .

 

SemaphoreTimeouts

This counter tracks the total number of threads that have timed out while  waiting to acquire the semaphore for this Secure Channel since the last time it connected.  For the '_Total' instance this counters is from system boot.   

 

 

Very very nifty to be able to track this instead of plowing through a bunch of netlogon logs.

 

 

 

 

Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post
  • Once again I am looking for info and I find myself reading one of your pages without realizing whose blog I am on. :)

    My issue is simple, I've pulled the counters via WMI and the hold times and system times are represented in a number that I don't recognize.  Do you know how to convert these values into Julian clock?

  • After cluttering your blog with my question I figured it out.  These numbers are represented in nanoseconds.

  • After cluttering your blog with my question I figured it out.  These numbers are represented in nanoseconds.

  • After cluttering your blog with my question I figured it out.  These numbers are represented in nanoseconds.

Page 1 of 1 (4 items)