Exchange Server 5.5 clients appear to hang when the information store queries the directory

Article ID: 268357 - View products that this article applies to.
This article was previously published under Q268357
Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986
(http://support.microsoft.com/kb/256986/ )
Description of the Microsoft Windows registry
Expand all | Collapse all

SYMPTOMS

It may appear that the client process has stopped responding (hangs), and it displays the hourglass cursor for long periods, yet the process eventually returns control to the user. This behavior typically reoccurs throughout the day, often during replication cycles, and only when the site is under load.

As measured by Performance Monitor, the information store becomes unresponsive, accompanied by spikes in the RPC Requests counter while the Write Bytes RPC Clients/sec counter remains at zero. High remote procedure call (RPC) requests by themselves or low write bytes alone are not related to this problem. Only when a server experiences both of these simultaneously might this be the problem.

This behavior has only been observed within Exchange Server organizations with hundreds of sites.
Back to the top | Give Feedback

CAUSE

Large Exchange Server organizations with hundreds of sites often require a few minutes to complete a search of the directory by the information store. When certain objects are modified in the directory, a notification may be triggered to tell the information store to rebuild such things as site addressing lists or valid SMTP domain lists.

If the information store is already very busy searching the directory for something, and is notified that an object in the directory that it was watching has changed, the information store may return a DS_E_TOO_LATE error, which looks like the following in the Application event log:
Event ID: 7201
Source: MSExchangeIS
Type: Warning
Category: General
Description: Background thread FDsWaitTask encountered a problem.
Error code DS_E_TOO_LATE
The information store's response to this error is to rebuild the list of objects it was searching against. In these cases, the information store is using serialized access to read from the directory, which compounds the slowness. When the server is already busy trying to handle client requests (some of which are likely waiting for this search to finish), clients appear to hang because they are waiting for their RPC calls to finish. Note that each update can force the information store to search the directory for information, so a long string of updates can lead to several minutes of apparent hang time.

Of course, clients often produce the hourglass cursor for many reasons completely unrelated to this problem. In this case the client is waiting for response from the server, and consumes little or no CPU time on the client computer.
Back to the top | Give Feedback

RESOLUTION

To resolve this problem, obtain the latest service pack for Exchange Server 5.5. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
191014
(http://support.microsoft.com/kb/191014/ )
How to obtain the latest Exchange Server 5.5 service pack
This problem is worse when the Directory Name attribute is not indexed. When the Directory Name attribute is not indexed, the performance of some searches can be negatively impacted.

To index the Directory Name attribute, follow these steps.

Warning If you use the raw mode of the Exchange Server Administrator program (admin /r) incorrectly, serious problems may occur that may require you to reinstall Microsoft Windows NT Server, Microsoft Exchange Server, or both. Microsoft cannot guarantee that problems that result from using raw mode incorrectly can be solved. Use raw mode at your own risk.
  1. Start the Exchange Administrator program in raw mode. To do this, you can use the Admin /r command at a command prompt.
  2. On the View menu, click Raw Directory.
  3. In the left pane, click Schema.
  4. In the right pane, double-click Directory Name, and then click Yes.
  5. In the Object attributes list, click Search-Flags.

    If the value of the Search-Flags attribute is set to 0, change the value to 1.
  6. Restart the Microsoft Exchange Directory service.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
184823
(http://support.microsoft.com/kb/184823/ )
Bad schema index after Exchange 4.0 to 5.5 upgrade
Back to the top | Give Feedback

WORKAROUND

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 your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
You can decrease or dampen the effect of this problem by increasing the time that the directory replication bridgehead server waits before it notifies other servers in the site of changes. You can increase this time in the following the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDS\Parameters\Replicator notify pause after modify (secs)
The default value for this key is 0x12C, or 300 seconds (five minutes). If you increase this value to match the duration of the longest series of hangs, you may reduce the impact of the problem.

The strategy here is to force the directory replication bridgehead to hold on to its updates a bit longer. This decreases the chance that a series of randomizing updates will pour into the site. Note that each update might force the information store to search the directory for information, and that an update during a period where the information store is already searching the directory is where this problem begins.

Note that like any performance tuning, there is a balance or equilibrium to be maintained. If you increase this registry value, you can reduce the likelihood of client hangs but at the expense of potentially slower times to complete directory replication.
Back to the top | Give Feedback

STATUS

Microsoft has confirmed that this is a problem in Microsoft Exchange Server version 5.5. This problem was first corrected in Exchange Server 5.5 Service Pack 4.
Back to the top | Give Feedback

MORE INFORMATION

It can be helpful to use Performance Monitor to diagnose this problem. Use the following objects:
  • MsExchangeIS::RPC Requests
  • MsExchangeIS::Write Bytes RPC Clients/sec
  • MsExchangeDS::ExDS Reads/sec
A typical Performance Monitor graph of this problem depicts MsExchangeIS::RPCRequests (and possibly, MsExchangeDS::ExDS Reads/sec) spiking upward, while at the same time MsExchangeIS::Write Bytes RPC Clients/sec dives to 0 and remains there. Eventually, RPC Requests returns to normal levels and Write Bytes returns up to its typical values.
Back to the top | Give Feedback

Properties

Article ID: 268357 - Last Review: October 26, 2006 - Revision: 4.1
APPLIES TO
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 5.5 Service Pack 1
  • Microsoft Exchange Server 5.5 Service Pack 2
  • Microsoft Exchange Server 5.5 Service Pack 3
Keywords: 
kbhotfixserver kbbug kbexchange550sp4fix kbfix kbqfe KB268357
Retired KB Content Disclaimer
This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.
Back to the top | Give Feedback

Give Feedback

 
Back to the topBack to the top