Internet e-mail messages are typically structured in MIME
format. In some cases, Microsoft Exchange Server must convert MIME messages to MAPI
For Post Office Protocol version 3 (POP3) or Internet Message
Access Protocol, version 4rev1 (IMAP4) clients to gain access to that e-mail,
the MAPI-formatted content must be converted back to MIME format before the
clients can log on. This conversion allows the exact message size to be
calculated, although the MIME-converted content is not persisted in the
database. If the file is larger than 4 kilobytes (KB), the mail cannot be
converted in memory. Therefore, Microsoft Exchange 2000 Server writes a temporary file to the
Windows Tmp folder.
Mail is converted to MAPI during the following
- A move-mailbox procedure
- Public folder replication
This may cause POP3 and IMAP4 clients to experience long delays
during logon. In some cases, without proper planning or available server
resources, this conversion to MAPI may also cause system latencies.
If timeouts occur during the conversion, the following event ID
messages are logged in the Application event log:
Event Source: ESE
Event ID: 623
Description: Information Store (2048) The version store for
instance 0 ("c49a179d-ac1f-4894-8211-0c2917d34500") has reached its maximum
size of 108Mb. It is likely that a long-running transaction is preventing
cleanup of the version store and causing it to build up in size. Updates will
be rejected until the long-running transaction has been completely committed or
rolled back. Possible long-running transaction: SessionId: 0x1B6525A0
Session-context: 0x00000000 Session-context ThreadId:
Event Type: Error
Source: MSExchangeIS Mailbox Store
Event Category: Logons
Description: Logon Failure on database "First
Storage Group\Mailbox Store (EXCHANGE)" - Windows NT account DOMAIN\user,
Conditions under which client latencies occur
If all of the users on an Exchange 2000 server are using POP3 or
IMAP4 clients, a large number of the messages in the mailboxes are frequently
stored in MIME format. If the mailboxes are moved, Exchange 2000 converts all
of these messages to MAPI.
Client latencies may occur in the
- A large number of these mailboxes have been
- Mail has been converted.
- Users log on and use their POP3 clients (by using RETR commands) or IMAP4 clients (by using FETCH commands) to gain access to mail.
In this scenario, Exchange 2000 must convert the MAPI messages
back to MIME. The Windows Tmp folder typically is not on a disk that has a
large number of spindles. The disk cannot handle the large number of
input/output (I/O) requests caused by a conversion of so many messages.
Therefore, a user may experience long delays (up to several minutes) when the
user does something as simple as switching between messages on the client. This
behavior occurs because the disk that the Tmp folder is located on cannot keep
up with all of the disk activity that Exchange 2000 generates to convert
Client latencies may also occur in the following scenario:
- A public folder store contains messages that are in MIME
- That data is replicated to another server. The MIME
messages in this new server's public folders are converted to MAPI.
- Users use IMAP4 to gain access to the messages on the new
In this scenario, Exchange 2000 has to convert the messages
back to MIME, which frequently causes similar disk problems.
How to avoid client latencies
You cannot prevent Exchange 2000 from converting messages to MAPI
when mailboxes are moved or when public folder data is replicated.
Additionally, you cannot set the folder that Exchange 2000 uses to convert the
messages in Exchange 2000. Exchange 2000 must use the folder that either the
Microsoft Windows TMP system variable or the Windows TMP user variable
The TMP system variable is used on stand-alone Exchange
2000 servers. The cluster service account user's TMP user variable is used on
clustered servers. To avoid the adverse effects of this behavior, change the
TMP folder variable that is used to a location represented by a drive that has
a high-performance caching controller connected to it and enough spindles to
handle the conversions.
Note that on a cluster, when you relocate
the Tmp folder to a shared cluster drive, this may cause problems during
failover. These problems occur because disk ownership is transferred to a
surviving node during failover. Therefore, Microsoft recommends that you do not
move the folder to a shared cluster drive. If you can, move the Tmp folder to
locally attached storage.
If the Exchange 2000 server has either very
limited local disk storage or no local disk storage, and all of the external
storage is allocated as shared cluster resources, you may not be able to move
the Tmp folder to locally attached storage. As a last resort, either reallocate
some of the shared storage as a non-cluster resource, or add additional storage
area network (SAN) storage that is not shared among the nodes, so that there is
a location that the Tmp folder can be moved to.
To permit users to
log on faster, you can also set the following registry keys to turn off exact
message-size calculation. One of the keys is for POP3 clients, and the other is
for IMAP4 clients. Warning
Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
- Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Pop3svc\Parameters
- Parameter: Compatibility (REG_DWORD)
- Default setting: Not present
- When to change: Change this setting when you want the store to use approximate
message-size calculations. Note that if you change this setting, some older
mail clients may no longer operate correctly. This key may break Request for
Comments (RFC) compliance.
- Recommended setting: 0xfffffffe
Enable fast message retrieval for IMAP4 users. To do this, follow these steps:
- Open the properties of the IMAP4 virtual server.
- On the General tab, click to select the Enable fast message retrieval check box, and then click OK.
After you modify these registry keys, restart the Microsoft
Internet Information Services (IIS) Admin service and the Microsoft Exchange
information store services. If you are running an Exchange Virtual Server (EVS)
and using cluster services, take the EVS offline before you restart these
How to determine whether access to the Tmp folder is causing client latencies
To determine whether access to the Tmp folder on the Exchange
2000 server is causing client latencies, use System Monitor to monitor disk I/O
activity on the disk where the Tmp folder is located. On the disk where the Tmp
folder is located, you may notice the following behaviors:
- Long disk queue lengths
- High disk I/O activity
If your Tmp folder is on a logical disk instead of a dedicated
physical disk, the logical disk I/O activity is important. Therefore, you must
first install the Logical Disk
counters in System Monitor. To do this:
- Click Start, click Run,
type cmd, and then press ENTER.
- Type diskperf -yv, and then press
ENTER to turn on the disk performance counters for logical drives or storage
- Restart the computer to load the Logical Disk counters.
For additional information about how to create and use counter logs in which to
monitor server performance, click the following article numbers to view the
articles in the Microsoft Knowledge Base:
How to Create a Log Using System Monitor in Windows 2000
How to determine how many disk spindles you need
If the average message size is 45 KB, the server does about 3 TMP
writes for each RETR
(POP3) or FETCH
(IMAP4) when the server converts from MAPI to MIME. You can use
this value to determine how many disk spindles are necessary on any
For example, assume that a server has 1,000 users. Each
user has an Inbox that contains 500 messages, and all of the mailboxes have
just been moved. After the move, when users log on and RETR
their mail at a rate of 42 messages per second, the server
performs about 126 writes per second to the TMP drive (3 writes per RETR
multiplied by 42 RETR
commands per second). One spindle can handle about 100 writes per
second. Therefore, two Raid0 spindles are necessary, or four Raid0+1 spindles.
This example was tested on a 4 x 450 megahertz (MHz) Exchange 2000 server with
4 gigabytes (GB) of RAM.