Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

XCON: RESVC Takes a Long Time to Synchronize


View products that this article applies to.

This article was previously published under Q326106

↑ Back to the top


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

↑ Back to the top


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 "attach info" 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).

↑ Back to the top


Keywords: KB326106, kbinfo, kbexchange2000sp3fea, kbexchange2000presp3fea

↑ Back to the top

Article Info
Article ID : 326106
Revision : 5
Created on : 2/28/2007
Published on : 2/28/2007
Exists online : False
Views : 279