The SMTP AdditionalPoolThreadsPerProc registry value has been manually set

[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at]  

Topic Last Modified: 2007-01-17

The Microsoft® Exchange Server Analyzer Tool reads the following registry entry to determine if additional pool threads have been manually configured:


If the Exchange Server Analyzer finds AdditionalPoolThreadsPerProc to be present and configured, a non-default configuration message is displayed.

There are five work queues in SMTP that use a pool of threads known as the ATQ threads. By design, two of these queues can, by default, use up to 90 percent of the available threads. This thread pool is shared by the process accepting POP and IMAP requests. Therefore, in a moderate to high load scenario, a situation can arise where SMTP can keep resources from POP and IMAP services.

You can reserve adequate threads for POP and IMAP by limiting the percentage of threads SMTP can use. To make this change, increase the overall number of threads available to IIS. The only tradeoff here is increased memory usage for the additional threads.

There are two registry values that allow you to control the SMTP percentage of threads and additional threads per processor:

Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Parameters

Value: AdditionalPoolThreadsPerProc


Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Parameters

Value: MaxPercentPoolThreads


Both registry values should be adjusted on clustered Exchange Server computers if high SMTP activity causes POP3, IMAP4 or both resources to fail. You can use the following formulas to calculate the optimum value for your cluster:


Registry Value Formula


((9 / (MaxPercentPoolThreads/100)) – 4) / 2


90 / (2 * Number of protocol virtual servers)

For example, in an Exchange Server cluster with two protocol virtual servers, the formula for MaxPercentPoolThreads is 90 / (2*2) = 22. When calculating the MaxPercentPoolThreads value, if your calculations result in a value that includes a decimal point, you should round the result down to the next integer. When calculating the AdditionalPoolThreadsPerProc value, if your calculations result in a value that is greater than 200, you will also need to assign the resulting value to an additional registry value:

Location: HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\

Value: PoolThreadLimit


This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

  1. Open a registry editor, such as Regedit.exe or Regedt32.exe.

  2. Navigate to:

  3. Create a DWORD registry value called AdditionalPoolThreadsPerProc and set its value data to the appropriate number based on the above formulas.

  4. Create a DWORD registry value called MaxPercentPoolThreads and set its value data to the appropriate number based on the above formulas.

  5. Close the registry editor and restart the IIS Admin service for the change to take effect.

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (

For more information about the specific cluster resource issue described in this article, see Microsoft Knowledge Base article 281868, "XADM: POP\IMAP4 Virtual Servers Repeatedly Fail Over Under High Load" (


Community Additions