Mitigate MCA Vulnerabilities: Calculate and Apply Changes on Your Windows Servers

Table of Contents

This article provides detailed guidance on how to calculate appropriate values for the MaxConcurrentApi parameter on your Windows servers and implement these changes. Understanding and tuning this parameter can help mitigate performance issues related to secure channel connections managed by the Netlogon service. This information is applicable to Windows Server 2012 and later versions, as well as Windows 8 and later versions.

Understanding MaxConcurrentApi and Performance Issues¶

The MaxConcurrentApi setting in Windows controls the maximum number of concurrent secure channel calls that the Netlogon service can handle at any given time. Secure channel calls are fundamental to authentication and communication between computers in a Windows domain environment. When the number of concurrent requests exceeds the MaxConcurrentApi limit, subsequent requests are queued. If requests remain in the queue for too long, they can time out, leading to authentication failures, delays in accessing resources, and other performance problems often referred to as “MCA vulnerabilities” or issues related to the MaxConcurrentApi bottleneck. Identifying and addressing this bottleneck is crucial for maintaining a responsive and stable network environment.

Once you have identified servers that may be experiencing MaxConcurrentApi related performance issues, the next critical step is to determine the optimal value for this parameter. This isn’t a one-size-fits-all approach; the ideal value depends heavily on the specific workload and characteristics of each individual server. The process involves collecting detailed performance data during peak load periods to accurately assess the demands placed on the Netlogon service. By analyzing this data, you can calculate a value that is specifically tuned for that server’s operational needs, ensuring it can handle the required volume of secure channel requests efficiently.

The general process for tuning MaxConcurrentApi involves several key steps. First, you must establish a baseline of the server’s typical performance under normal and peak conditions. This baseline serves as a crucial reference point for evaluating the impact of any changes you make. Next, you collect specific performance metrics related to the Netlogon service during periods of high demand, capturing the behavior of the secure channel queue and processing times. Using this collected data, you apply a specific formula to calculate a recommended MaxConcurrentApi value. If this calculated value is different from the current setting and within the acceptable range (above the default but below the maximum supported value), you implement the change by modifying the server’s registry. Finally, you continue monitoring the server’s performance after applying the change to confirm that the adjustment has resulted in the desired improvement and hasn’t introduced any new issues.

Set the Performance Baseline¶

Before making any modifications to the MaxConcurrentApi setting, it is absolutely essential to establish comprehensive performance baselines for the affected servers. This involves monitoring their performance over a sufficient period, particularly during peak operational hours when network activity is highest. The performance data collected during this baseline phase will provide a clear picture of the server’s typical behavior under various load conditions. This data is invaluable for two main reasons: first, it helps confirm that the performance issues you suspect are indeed related to MaxConcurrentApi or another underlying cause; and second, it provides a benchmark against which you can compare performance after implementing MaxConcurrentApi changes to objectively measure their effectiveness. Without a solid baseline, it is impossible to definitively determine whether your tuning efforts have improved performance or made it worse.

To establish a thorough performance baseline and subsequently verify the impact of MaxConcurrentApi adjustments, you should monitor a specific set of performance counters. These counters provide insight into the overall health and resource utilization of the server, as well as detailed metrics for the Netlogon service itself. Monitoring counters across various categories helps ensure that you are not overlooking other potential bottlenecks (like insufficient memory, high disk utilization, or CPU saturation) that might be contributing to the observed performance problems, even if MaxConcurrentApi is also a factor. The list below outlines the minimum set of counters recommended for this purpose.

Performance Counter Set	Purpose
Memory	Tracks overall system memory usage (e.g., Available MBytes, Pages/sec). Ensures the system isn’t constrained by lack of available RAM, which could impact any service, including Netlogon.
Physical Disk or Logical Disk	Tracks disk I/O performance (e.g., Disk Reads/sec, Disk Writes/sec, Avg. Disk Queue Length). Important for identifying disk bottlenecks, particularly if Netlogon logging is enabled, as logs are written to disk.
Process (lsass.exe)	Monitors resource usage for specific processes. Lsass.exe is critical as it hosts the Netlogon service and handles security authentication. High CPU or memory usage by lsass.exe could indicate an issue within the security subsystem.
Processor	Monitors CPU utilization (e.g., % Processor Time, % Interrupt Time). High processor load can prevent the server from keeping up with requests, potentially leading to delays and timeouts in Netlogon.
Network Interface	(Optional, but recommended) Tracks network throughput and errors (e.g., Bytes Total/sec, Output Queue Length). Helps identify if network congestion or issues are contributing to delays.
Netlogon	Provides specific metrics for the Netlogon service (e.g., Semaphore Acquires, Semaphore Timeouts, Average Semaphore Hold Time). These counters directly measure the activity and efficiency of the secure channel handling process. They are the most direct indicators of potential MaxConcurrentApi bottlenecks.

Monitoring these counters diligently, especially the Netlogon counters, provides both a quick assessment of whether authentication timeouts are occurring and the necessary data for deeper analysis. While the Netlogon performance counters give a summary view, the Netlogon debug logs (which should be enabled when troubleshooting these issues) offer detailed information about specific authentication attempts, including client IPs, errors, and timings, which is essential for trending and identifying the root cause and scope of the problem.

Collect the Tuning-Related Statistics¶

To accurately calculate the optimal MaxConcurrentApi value for a server, you need to collect specific performance data focused on the Netlogon service’s semaphore usage. Performance Monitor (Perfmon.msc), a built-in Windows tool, is the primary utility for this task. You can access Performance Monitor via Server Manager or by running perfmon.msc from the Run dialog or Command Prompt. Configuring Perfmon correctly is crucial to capture the relevant metrics over a suitable time interval.

When configuring Performance Monitor for MaxConcurrentApi tuning data collection, pay attention to the following settings:

• Duration: Set the duration for data collection. A duration of 90 to 120 seconds is generally recommended during a period of peak load. This timeframe is short enough to capture a snapshot of intense activity but long enough to gather sufficient data points for the calculation. Ensure the server is actively experiencing the performance issue or peak authentication load during this monitoring interval.
• Counters: Add specific counters from the Netlogon performance object. These counters provide the raw data needed for the MaxConcurrentApi calculation formula. You should add the following counters, typically using the _Total instance to capture aggregate data across all secure channels:

Counter	Instance
Semaphore Acquires	_Total
Semaphore Timeouts	_Total
Average Semaphore Hold Time	_Total

Note that while you can view most counter values in the standard Line view of Performance Monitor, the Average Semaphore Hold Time is often best viewed in the Report view. The Report view presents the average value calculated over the entire data collection interval, which is precisely what is needed for the formula. You can switch between Line and Report views using the toolbar options within Performance Monitor.

Once Performance Monitor is configured and running during a peak load period, you will collect the following specific values for use in the MaxConcurrentApi calculation:

• <Duration>: This is the constant value you set for the data collection interval (e.g., 90 or 120 seconds).
• <Semaphore_Acquires>: This represents the change in the cumulative value of the Netlogon Semaphore Acquires counter over the specified duration. Since this is a cumulative counter, you subtract the value at the start of the monitoring period (minimum value) from the value at the end of the period (maximum value) to get the total number of semaphore acquisitions during the duration.
• <Semaphore_Timeouts>: Similar to Semaphore Acquires, this is the change in the cumulative value of the Netlogon Semaphore Timeouts counter over the specified duration. Calculate it by subtracting the minimum value from the maximum value. This number represents the total count of secure channel requests that timed out while waiting for a semaphore during the monitoring interval.
• <Avg_Semaphore_Hold_Time>: This is the average value of the Netlogon Average Semaphore Hold Time counter over the specified duration. Obtain this value from the Report view in Performance Monitor for the most accurate average over the entire monitoring interval. This counter measures the average time (in seconds) that a thread holds a semaphore, essentially representing the average processing time for a secure channel request once it has acquired a semaphore.

These four values are the inputs required for the formula that calculates the recommended MaxConcurrentApi value.

Calculate the New MaxConcurrentApi Value¶

With the performance data collected from Performance Monitor during a peak load period, you can now use a specific formula to calculate a potential new MaxConcurrentApi value that is tuned for your server’s workload. The formula is designed to estimate the number of semaphores (concurrent slots) needed to handle the observed volume of requests and timeouts within the average processing time.

The formula is as follows:

(<Semaphore_Acquires> + <Semaphore_Timeouts>) × <Avg_Semaphore_Hold_Time> / <Duration> = <MaxConcurrentApi>

Let’s break down what the components represent:
* (Semaphore_Acquires + <Semaphore_Timeouts>) represents the total number of secure channel requests that either successfully acquired a semaphore or timed out trying, within the measured duration. This is an estimate of the total demand for semaphores during that peak interval.
* <Avg_Semaphore_Hold_Time> is the average time each request took to process once it got a semaphore.
* <Duration> is the length of the measurement period in seconds.

The calculation essentially estimates the average number of requests that were being processed concurrently (or attempting to be processed) during the measurement interval. The result, <MaxConcurrentApi>, is the calculated recommended value for the setting.

Once you have calculated this value, you must compare it to the default and maximum supported values for the server’s operating system role. Microsoft specifies limits to prevent setting the value excessively high, which could potentially consume excessive system resources or introduce other issues.

Operating System Type or Role	Default Threads (per secure channel)	Maximum Threads
Domain Controllers Windows Server 2012 and later	10	150
Member Servers Windows 2012 and later	10	150
Workstations Windows 8 and later	1	150 Note: A value greater than 1 is rarely needed on a workstation.

If the calculated value for MaxConcurrentApi meets the following criteria, it is a candidate for implementation:
1. It is greater than the default value for the server’s role.
2. It is less than or equal to the maximum supported value (150 in most cases).

If the calculated value is less than or equal to the default, it suggests that MaxConcurrentApi is likely not the primary bottleneck, and you should investigate other performance counters and potential causes (as mentioned in Part 3 of the hypothetical series). If the calculated value is significantly higher than 150, it may indicate an unusually high demand or a fundamental architecture issue requiring a solution beyond simply raising this parameter. However, within the range between the default and 150, implementing the calculated value is a reasonable next step. Remember that the registry setting requires an integer value, so you should round the calculated decimal value to the nearest whole number, typically rounding up to be slightly safer.

Change MaxConcurrentApi¶

The MaxConcurrentApi setting is configured exclusively through the Windows Registry. There is no corresponding Group Policy setting or graphical interface option to adjust this parameter. Modifying the registry requires careful attention to avoid errors that could impact system stability. Always ensure you have a backup or system restore point before making registry changes.

To change the MaxConcurrentApi setting on a server, follow these steps:

1. Open the Registry Editor. You can do this by selecting Start, typing regedit in the search box, and then selecting Registry Editor from the results. User Account Control (UAC) may prompt you for permission; confirm if necessary.
2. Navigate to the following registry subkey by expanding the keys in the left-hand pane: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Within the Parameters key, check if a DWORD (32-bit) Value named MaxConcurrentApi already exists. If it does, you will modify its value in the next step. If it does not exist, you need to create it. To create a new value, right-click in the right-hand pane (where the values are listed), select New, and then select DWORD (32-bit) Value. Type MaxConcurrentApi exactly as shown, including capitalization.
4. Once the MaxConcurrentApi DWORD value exists, right-click on it and select Modify. Alternatively, double-click the value name.
5. In the Edit DWORD Value dialog box, ensure that Decimal is selected under Base. Enter the calculated MaxConcurrentApi value (rounded to the nearest integer, typically rounded up) into the Value data field. For example, if your calculated value was 4.1552, you would enter 5.
6. Click OK to save the change.
7. For the change to take effect, the Netlogon service must be restarted. Open a Command Prompt window as an administrator. You can do this by selecting Start, typing cmd, right-clicking Command Prompt, and selecting Run as administrator.

8. In the Command Prompt window, run the following commands sequentially, pressing Enter after each:

   net stop netlogon
   net start netlogon
   

   These commands will stop the Netlogon service and then start it again, applying the new MaxConcurrentApi setting without requiring a full server restart. This minimizes downtime for the server.

After restarting the Netlogon service, the new MaxConcurrentApi value is active. It is now crucial to proceed to the verification step to ensure the change has had the desired positive impact on performance.

Verify the New MaxConcurrentApi Setting¶

Implementing the calculated MaxConcurrentApi value is only half the battle; the other, equally important half, is verifying that the change has actually improved performance and hasn’t introduced any unforeseen issues. As mentioned in the section on setting the baseline, continuous monitoring after the change is vital. You should monitor the same set of performance counters you used to establish your baseline, paying close attention during peak load periods.

Concentrate your monitoring efforts on the following performance counter sets:

• Memory: Check if overall memory usage remains within acceptable limits.
• Physical Disk or Logical Disk: Ensure disk I/O performance is not degrading.
• Process (lsass.exe): Monitor the CPU and memory consumption of the lsass.exe process; ideally, its resource usage might decrease slightly if it was previously spending time managing timeouts or a large queue.
• Processor: Check if overall CPU load has decreased or stabilized during peak periods compared to the baseline.
• Network Interface: (If monitored previously) Verify network performance remains healthy.
• Netlogon: This is where you should see the most direct impact. Look for a significant decrease or elimination of Semaphore Timeouts. The Semaphore Acquires rate might remain similar (representing the demand), but the processing should be smoother. The Average Semaphore Hold Time should ideally remain stable or even slightly decrease if the bottleneck is truly resolved.

Compare the performance data collected after the MaxConcurrentApi change to your initial baseline data. You should aim to see a reduction in the symptoms that led you to investigate MaxConcurrentApi in the first place, such as authentication delays or errors. Ideally, the Netlogon performance counters should show a healthy state, with minimal or zero semaphore timeouts during peak load. If performance does not improve significantly, or if new issues arise, the calculated MaxConcurrentApi value may still not be optimal, or the performance problem might be rooted in a different component of the system. Further analysis of the performance counters and Netlogon debug logs would be necessary in such cases to identify the true bottleneck. It may sometimes be necessary to incrementally adjust the MaxConcurrentApi value and re-test if the first calculated value does not yield the expected results.

Example: Calculating a Tuned MaxConcurrentApi Value¶

Let’s walk through a concrete example to illustrate the MaxConcurrentApi calculation process. This example uses hypothetical data similar to a scenario where a server is experiencing noticeable MCA-related performance issues, potentially following initial identification steps described in related documentation.

Suppose we have configured Performance Monitor to collect data for 90 seconds (<Duration> = 90) during a peak load period. We are monitoring the three key Netlogon counters: Semaphore Acquires, Semaphore Timeouts, and Average Semaphore Hold Time (all using the _Total instance).

The first step is to determine the value for <Avg_Semaphore_Hold_Time>. As recommended, we switch Performance Monitor to the Report view after the 90-second collection period has completed. The report view shows the calculated average value over the duration. Let’s assume the Report view shows the value for Average Semaphore Hold Time as 0.098.

So far, our formula looks like this:

(<Semaphore_Acquires> + <Semaphore_Timeouts>) × 0.098 / 90 = <MaxConcurrentApi>

Next, we need the total number of Semaphore Timeouts that occurred during the 90-second interval. Switching Performance Monitor back to the Line view, we examine the raw data for the Semaphore Timeouts (_Total) counter. This counter is cumulative, meaning its value only increases over time. To find the count during our 90-second interval, we take the final value recorded at the end of the duration (the maximum value) and subtract the initial value recorded at the start of the duration (the minimum value). Suppose the minimum value was 10,120 and the maximum value was 12,103.

The change in value is 12,103 - 10,120 = 1,983.
So, <Semaphore_Timeouts> = 1,983.

Our formula is now updated:

(<Semaphore_Acquires> + 1,983) × 0.098 / 90 = <MaxConcurrentApi>

Finally, we need the total number of Semaphore Acquires during the same 90-second interval. Returning to the Line view, we examine the data for the Semaphore Acquires (_Total) counter. This counter is also cumulative. We again subtract the minimum value from the maximum value over the 90-second duration. Suppose the minimum value was 55,450 and the maximum value was 57,283.

The change in value is 57,283 - 55,450 = 1,833.
So, <Semaphore_Acquires> = 1,833.

Now we have all the values needed to complete the calculation:

(1,833 + 1,983) × 0.098 / 90 = <MaxConcurrentApi>

Performing the arithmetic:

(3,816) × 0.098 / 90 = <MaxConcurrentApi>
374.008 / 90 = <MaxConcurrentApi>
4.155644… = <MaxConcurrentApi>

The calculated value for MaxConcurrentApi is approximately 4.1556. The registry setting requires an integer. Rounding this value, we get 4. However, considering that we observed 1,983 timeouts during this period, a value of 4 (which is below the default of 10 for servers) is unlikely to resolve the issue. In such cases, rounding up is generally recommended to provide a slight buffer. Rounding up 4.1556 gives us 5. Even a value of 5 is still well below the default of 10 for a server, suggesting that while this formula provides a calculation based on the observed data, the underlying issue causing such a high timeout rate might require further investigation beyond just this parameter, or perhaps the peak load was extremely short and intense. However, based purely on the formula and rounding up, 5 would be the calculated value.

Given the server role (let’s assume it’s a member server, default 10, max 150), a calculated value of 5 is less than the default (10). According to the guidance, if the calculated value is less than or equal to the default, it’s less likely MaxConcurrentApi is the primary issue. However, with nearly 2000 timeouts in 90 seconds, something is clearly wrong. This highlights that the formula is a guide, but the interpretation requires judgment and consideration of all collected data, including Netlogon logs. In a real-world scenario with 1983 timeouts, you would likely try a value significantly higher than the default (e.g., 50 or 100) and re-test, while simultaneously investigating other performance bottlenecks or configuration issues. If we strictly follow the rule “If the calculated value is greater than the default value and less than 150, change the server’s MaxConcurrentApi value”, this calculated value (5) would not lead to a change based only on the formula result compared to the default.

However, let’s consider a different hypothetical outcome where the calculation resulted in a value of 55.12. Rounding up gives us 56. This value (56) is greater than the default (10 for a server) and less than the maximum (150). In this adjusted example, setting the MaxConcurrentApi registry value to 56 (Decimal) would be the recommended action based on the calculation and criteria. After setting this value in the registry and restarting the Netlogon service, you would then proceed to the verification step by monitoring performance during another peak load period to see if the timeouts have decreased and overall performance has improved.

Next Steps¶

After calculating a potentially tuned MaxConcurrentApi value and implementing the change in the registry, the most crucial next step is rigorous monitoring and validation. Re-run your performance monitoring during typical peak load times, using the same counters as your baseline collection. Analyze the Netlogon counters, especially Semaphore Timeouts, to confirm that the frequency of timeouts has significantly decreased or been eliminated. Also, review the other performance counters (CPU, Memory, Disk) to ensure that the change hasn’t negatively impacted other system resources.

If performance improves and the symptoms of MCA issues are resolved, you have likely found an optimal setting for this server under its current workload. However, remember that workloads can change over time. It’s good practice to periodically review performance metrics, especially after significant changes in the environment (e.g., adding many new users, deploying new applications, upgrading client operating systems), to ensure the MaxConcurrentApi setting remains appropriate.

If performance does not improve as expected, or if timeouts persist, this indicates that either the calculated value was not sufficient, or the root cause of the performance bottleneck lies elsewhere. You may need to:

1. Recalculate MaxConcurrentApi using data from a different or longer peak period.
2. Incrementally increase the MaxConcurrentApi value (e.g., in steps of 20 or 30) up to the maximum of 150, testing performance after each change.
3. Conduct a deeper analysis of the performance counters and Netlogon debug logs to identify other potential bottlenecks or issues within the authentication process or broader system. This might involve investigating network latency, DNS issues, client-side problems, or performance issues with the domain controllers themselves (if the server in question is a member server accessing DCs). The related article series (hypothetically Part 3) would delve into troubleshooting these other potential causes.

Tuning MaxConcurrentApi is an important step in addressing specific Netlogon performance bottlenecks, but it is part of a larger strategy for maintaining healthy authentication performance across your network.

Do you have experience calculating or tuning MaxConcurrentApi on your Windows servers? Share your experiences, tips, or challenges in the comments below!