Microsoft KB Archive/326106

= XCON: RESVC Takes a Long Time to Synchronize =

Article ID: 326106

Article Last Modified on 2/28/2007

-

APPLIES TO


 * Microsoft Exchange 2000 Server Standard Edition

-



This article was previously published under Q326106



SUMMARY
When you move a server, its service node (either the master or the subordinate [also known as the slave]) is deinitialized, and its client node (Simple Mail Transfer Protocol [SMTP], message transfer agent [MTA], or store) changes to an error state (or a retry state). While the server is in this error state, messages that have outdated topology information may loop on the routing node.

For additional information about the latest service pack for Microsoft Exchange 2000 Server, click the article number below to view the article in the Microsoft Knowledge Base:

301378 XGEN: How to Obtain the Latest Exchange 2000 Server Service Pack



MORE INFORMATION
The new service node cannot be constructed unless there is at least one successful connection from a client computer. When a client makes that connection, it typically has the most up-to-date information, such as the routing group that the home server is in and the master that the client talks to. This information is called the &quot;attach info&quot; and it is vital for constructing the correct internal structure when there are changes.

In some cases, the server may read outdated attach info from the DsAccess cache. However, if you use Exchange 2000 Service Pack 3 (SP3), the information is up to date when you make the connection attempt. This behavior occurs because the routing group and master object are purged from the cache before the server calls the DsAccess cache to make the inquiry. As a result, DsAccess always makes direct Lightweight Directory Access Protocol (LDAP) searches for the routing group and the master object to obtain the updated information, instead of returning a cached version of the information for these objects.

Additionally, Exchange 2000 SP3 includes an optional registry key which you can use to configure a shorter retry time interval. In earlier versions of Exchange 2000, the retry time interval was hard-coded to two minutes. The shorter interval configuration causes the outdated routing information to be flushed and reconstructed more rapidly than before.

In Exchange 2000 SP3 and later, the following process occurs:  Routing group and master objects are purged from the DsAccess cache before the client/subordinate attach info is updated. As a result, the most up-to-date attach info is returned from the DsAccess cache. Exchange 2000 SP3 and later includes the following registry key that you can use to configure a shorter retry interval for both the client and the subordinate:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters\ClientConnectRetryInterval

You can configure this new registry value to set a timeout value in seconds. Microsoft recommends that you use a value that ranges from 10 to 30 seconds. The retry interval occurs when the client cannot connect to the subordinate or if the subordinate cannot to connect to the master. In earlier versions of Exchange 2000, this value was hard-coded to two minutes (120 seconds).

Keywords: kbexchange2000presp3fea kbexchange2000sp3fea kbinfo KB326106

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.