There are many applications that can be affected by a server’s paged pool size. Applications such as Exchange server can report problems if the page pool size is not large enough to support the large number of user connections that are common in enterprise environments.

Sometimes Exchange server can be impacted if there is not enough paged pool memory. So what exactly is paged pool memory and how do you solve problems associated with a lack of paged pool memory?

One of the steps that occur at boot up time is the creation of memory pools. Two dynamically sized memory pools are created by the memory manager and it is those two memory pools that are used by applications during execution. Kernel-mode components use the two pools to allocate memory for the processes that are running. Those two pools are called the Paged Pool and the Non-Paged Pool.

The size of the physical memory helps in determining the initial sizes of each of those two pools at boot up. The pools are dynamic and so can grow in size over time up to a pre-determined maximum.

So how do the pool sizes affect the execution of Exchange?

Part of the problem has to do with how Exchange server handles security. When users try to gain access to resources in Windows that are protected by security the user accounts receive access tokens. These access tokens have been created by the owner of those resources using information they receive from corresponding domain controllers. The tokens control accesses to those resources and the limitations, if any, on the access to those resources.

Each of these access tokens include several pieces of information one of which is a security identifier (SID) that consists of information which identifies the user account and the user’s security group. This SID is made up of a string of numbers that corresponds to a Windows security principal or security group. When the user makes a connection to the server an access token is created that contains the SIDs for the user’s account and group membership.

How many client access tokens there are and the size of those tokens will affect how many clients can be supported by Microsoft Exchange Server.

These access tokens use Windows kernel memory and can vary based on different parameters.  One of those parameters is group membership. When there are a large number of group memberships then the size of the tokens will be higher. And when there are a small number of group memberships then the size of the tokens will be smaller.

It is in the paged pool kernel memory of the server where each user’s access token is stored. There can be multiple copies of user tokens in memory based on whether or not a client maps a share on a Windows Server 2003-based server by using the NET USE command. In that case two copies of the user’s token will be stored on the server to support the connection.

When client applications make connections to the Exchange server they can result in many copies of user tokens being created. And as client connections are made to the Exchange server access tokens are granted and hence the amount of paged pool memory used and available will change.

Most often, the largest consumers of paged pool memory on an Exchange server are the client access tokens that are generated for the client connections. This can lead to bottlenecks on the Exchange server when user tokens are large in size and numerous in quantities. And because there is a fixed amount of paged pool memory available then there is also a corresponding limit to the number of client connections that can be simultaneously maintained.

But an administrator can control how much paged pool memory is affected by controlling the size and quantity of the access tokens.

For example, on a Windows server that has more than one gigabyte (1GB) of physical memory, the maximum paged pool memory is about three-hundred fifty megabytes (350MB). If there are other resource needs not being met then an administrator can reduce the paged pool memory amount by using the /3GB boot.ini switch. The net effect is that the maximum paged pool memory size will be reduced to less than two-hundred fifty megabytes (250MB).

Not using the /3GB switch can have the undesired consequence of Exchange Server services having to be restarted periodically to defragment virtual memory. Although you are freeing up resources for application memory this will mean more time will be spent by an administrator on monitoring the paged pool memory.

To make an administrator’s life easier there is a hotfix available from Microsoft, called hotfix 912480  that can be used to limit the number of client access tokens that are made available during client connections to Microsoft Exchange Server 2003.