This article has been archived. It is offered "as is" and will no longer be updated.
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:
Description of the Microsoft Windows registry
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.
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
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.
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:
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.
- Start the Exchange Administrator program in raw mode. To do this, you can use the Admin /r command at a command prompt.
- On the View menu, click Raw Directory.
- In the left pane, click Schema.
- In the right pane, double-click Directory Name, and then click Yes.
- 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.
- Restart the Microsoft Exchange Directory service.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
Bad schema index after Exchange 4.0 to 5.5 upgrade
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.
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.
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.