When and where to increase MaxConcurrentAPI in a BCAAA deployment
search cancel

When and where to increase MaxConcurrentAPI in a BCAAA deployment

book

Article ID: 169381

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

The MaxConcurrentAPI is a Windows registry setting:

Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Name: MaxConcurrentApi
Type: REG_DWORD


which only needs to be increased on a Domain Controller (DC) if you need to increase NTLM throughput for users from trusted domains, in other words this does not need to be increased if the customer only has a single domain.

BCAAA sends all NTLM requests to a DC from its local domain, regardless of user. If a request is for a user in a trusted domain, then the DC forwards it to a DC in the user's domain. That's when MaxConcurrentAPI on the DC comes into play.

As a result in a single domain environment there is no need to increase the MaxConcurrentAPI as there will be no outbound requests to trusted domains
 

Resolution

MaxConcurrentAPI in a multi trust domain environment should be set on the Windows BCAAA server(s) and on every DC in the site or domain (this is not true for IWA direct where MaxConcurrentAPI/Schannel needs to be increased on the primary and alternate DCs.

Bear in mind that it is the Windows server that BCAAA is installed on that chooses the DC it will talk to, BCAAA has no say in this process. Sometimes Windows will pick the fastest DC, but not necessarily the DC in the best position to handle the load of NTLM request. If Windows changes DCs for some reason (the DC goes off-line, the BCAAA server is rebooted, etc.) and the new DC is slower, then the customer may have an outage. In many cases, Windows won't switch away from a slow DC without admin intervention, because Windows doesn't know there is a problem ie the DC is still responding to requests, albeit it more slowly.

While it may be tempting to disregard MaxConcurrentAPI in a Kerberos environment, remember that Client/Browser will fall back to NTLM if it is not able to fetch the Kerberos tokens from the KDC for some reasons.