Memory reports from Exchange BPA tool trouble users

The problem centers around the use of the /3GB switch. According to Microsoft Knowledge Base Article number 266096, the BOOT.INI file must contain the /3GB switch if the Exchange Server is running on Windows 2000 Advanced Server (or Windows Server 2003), the machine has 1 GB or more of physical RAM and the server stores mailboxes and/or public folders.

Normally, Windows 2000 Advanced Server sets aside 2 GB of virtual address space for the kernel and allows Exchange and other user-level processes to also use up to 2 GB of virtual address space.

However, in Windows 2000 Advanced Server and Windows Server 2003, 2 GB of user mode process space often isn't enough. Unless you add the /3GB switch to the BOOT.INI file, Windows will likely run out of virtual memory space. If the STORE.EXE process runs out of virtual memory space memory allocation will fail even if there is plenty of free physical RAM. When this occurs, the Information Store will shut down and must be manually restarted. Although the /3GB switch is required for servers running Windows 2000 Advanced server with more than 1 GB of RAM, you must not enable this switch on Windows 2000 Server. Doing so will lead to severe virtual memory fragmentation, which really hurts performance.

Now that I have explained what the /3GB switch is and what it does, let's take a look at the BPA. The BPA seems to have three main issues with the /3GB switch.

Issue Number 1
There are unconfirmed reports of the BPA recommending the use of the /3GB switch on Windows 2000 Servers. In a Windows 2000 environment, the /3GB switch is safe to use only in Windows 2000 Advanced Server and in Windows 2000 Data Center Server. Messages telling you to enable the /3GB switch should be ignored in all other versions of Windows 2000.

Issue Number 2
The second issue involves Windows 2003 servers with more than 1 GB of RAM. As expected, if the /3GB switch is not set in such environments, then BPA will generate the following warning:

Active Directory server <servername> has 1 GB or more of memory and does not have /3GB set in the boot.ini file. LDAP performance can be increased by setting this parameter.

However, when you add the /3GB switch, then you may see this warning:

Exchange server <servername> has /3GB set in the boot.ini. If this is a routing or bridgehead server, better performance would result if this value was removed.

At first it seems as though the BPA is having a tough time making up its mind. What is actually going on is that the BPA looks to see how many mailboxes are on the server. If there are fewer than 20 mailboxes, then the BPA triggers the alert because it thinks that there is a possibility that the server might be being used primarily as a routing or bridgehead server. According to Paul Bowden, the tool's creator, this issue is being fixed.

Issue Number 3
The third issue involving BPA and the /3GB switch involves incorrect memory calculations on machines with exactly 1 GB of physical RAM. On such machines, the BPA tool may issue a warning that the machine has less than 1 GB of physical RAM and that the /3GB switch should therefore be removed.

In such cases, the tool typically detects 1023 MB of RAM instead of the 1024 MB that are actually installed. So what happened to the missing 1 MB? According to Bowden, this is one of those grey areas. Technically, the BPA did detect less than 1 GB of RAM, so the alert is triggered.

Typically, this problem occurs when a server uses shared RAM for video. The server may actually have a full GB of RAM installed, but may set aside 1 MB of that memory for video. Some servers will even share as much as 64 MB of RAM for video. Microsoft has now modified the BPA so that if 1023 MB of RAM is detected, the alert will still be displayed, but will explain that shared video may be to blame.

In my opinion, the BPA is a long overdue tool. As with any first version software, some bugs are bound to be uncovered. However, from the looks of the Microsoft message boards, it seems that Microsoft is making a legitimate effort to correct such bugs as they are discovered.