Routing status information is not propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003

In certain situations, routing status information may not be dynamically propagated correctly across servers throughout an Exchange organization. Some servers in the organization continue to operate with old and possibly incorrect routing status information. This may include new connectors that do not appear when you view a remote routing group by using the WinRoute tool (Winroute.exe).

Note You can use the WinRoute tool to verify that link state information is propagating. To do this, use the WinRoute tool to view the link state information from several different locations in the Exchange organization, and then compare the version numbers for each routing group. The WinRoute tool connects to the link state port on an Exchange computer and extracts the link state information for the Exchange organization. Although link state information is typically a series of globally unique identifiers (GUIDs), WinRoute matches the GUIDs of connectors and of bridgehead servers to objects in the Active Directory directory service and presents the information in a readable format. For more information about the WinRoute Tool, see the "More Information" section.

This problem may occur if the link state information was once propagated, but because of some change in the organization, the link state information is no longer being propagated. This problem may occur if one of the following conditions is true:

• An Exchange 2000-based routing group connector or an Exchange 2003-based routing group connector was removed and replaced with another connector, such as a Microsoft Exchange Server 5.5 Internet Mail Connector or an Exchange Server 5.5 Site Connector.
• A non-Exchange Simple Mail Transfer Protocol (SMTP) smart host that is blocking link state propagation is added to the system between routing groups.
  
  Note This configuration is not supported.
• A firewall that is blocking link state propagation is added to the system. For example, port 691 is required within a routing group, and port 25 is required between routing groups. Also, the Extended Simple Mail Transfer Protocol (ESMTP) command X-LINK2STATE must not be blocked by the firewall.

To work around this problem, use one of the following methods, as appropriate:

• Recommended - Restore the deleted routing group connector or change both bridgeheads so that they are running Exchange 2000 or a later version of Exchange. This will restore the connectivity that is required for the link state to be propagated. For more information about how to configure routing group connectors to connect routing groups in Exchange 2003, click the following article number to view the article in the Microsoft Knowledge Base:
  822929 How to use routing group connectors to connect routing groups in Exchange Server 2003
  For more information about how to configure routing group connectors to connect routing groups in Exchange 2000, click the following article number to view the article in the Microsoft Knowledge Base:
  319416 How to use routing group connectors to connect routing groups in Exchange 2000
• Shut down all Exchange computers in the organization to reset non-connected routing groups to link state major version number 0. For more information about the link state version number in Exchange 2000 Server, click the following article number to view the article in the Microsoft Knowledge Base:
  285130 Link state information
• Remove all non-Exchange SMTP smart hosts that exist as hops between servers that are running Exchange in the same organization.
  
  Note Non-Exchange smart hosts that exist outside the organizational boundaries are supported.
• Configure the firewall so that link state propagation is not prevented.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

The Microsoft Exchange Routing Engine service (RESvc) listens for routing link state information on Transmission Control Protocol (TCP) port 691. Exchange uses routing link state information to route messages, and the routing table is regularly updated. The Link State Algorithm (LSA) propagates routing status information between servers that are running Exchange. This algorithm is based on the Open Shortest Path First (OSPF) protocol from networking technology. The algorithm transfers link state information between routing groups by using the X-LSA-2 command X-LINK2STATE verb over SMTP and by using a TCP connection to port 691 for transmission within a routing group.

Notes

• Servers that are running Exchange in different routing groups exchange routing and link state information through the X-LINK2STATE verb over port 25. For this communication to occur, both bridgeheads in the separate routing groups must be servers that are running Exchange 2000 or Exchange 2003.
• When a bridgehead is changed on a non-Exchange 2000-based computer or on a non-Exchange 2003-based computer, link state propagation between routing groups is affected or stopped. For example, when a bridgehead is changed on an Exchange Server 5.5 computer, link state propagation between routing groups is affected or stopped. Additionally, if direct point A to point B transmission is prevented by a firewall or a similar device, link state propagation between routing groups is also affected or stopped. However, servers that are running Exchange do have a mechanism to obtain updated information from Active Directory when link state propagation is stopped. This mechanism was built for scenarios where servers that are running Exchange 2000 or Exchange 2003 must communicate and obtain routing information instead of link state information from pure Exchange Server 5.5 sites.
• Pure Exchange Server 5.5 sites, Exchange 2000 sites, or Exchange 2003 sites that are disjointed from other Exchange 2000 or Exchange 2003 sites will always have a major version of zero (0). Routing groups that are truly disjointed means that there has never been an X-LINK2STATE exchange between the two disjointed routing groups. If there has ever been an X-LINK2STATE exchange between Exchange routing groups, the major version will always be a non-zero number.

For sites or routing groups with a non-zero number, servers that are running Exchange will always subsequently rely on a link state exchange to obtain more updated information. This means that if you create a scenario that is described in the "Cause" section, any new or updated information about changes on connectors, creation of connectors, and so on, will never be updated between disjointed routing groups. As a fail-safe mechanism for updated information outside an X-LINK2STATE Exchange organization, Exchange reads directly from Active Directory one time every hour. This Active Directory read is only performed on sites or routing groups that have a zero (0) major version. This Active Directory read interval can be configured by using the registry entry. Therefore, the second workaround method that is described in the "Workaround" section will reset the major version of the routing group to zero and enable servers in adjacent disjointed routing groups to obtain updates from Active Directory.

To configure the Active Directory read interval, follow these steps.

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.

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type ReloadOsInterval for the name of the DWORD, and then press ENTER.
5. Right-click ReloadOsInterval, and then click Modify.
6. In the Value data box, type the value in seconds that you want to use, and then click OK.
   
   Note By default, the Active Directory read interval is one hour. One hour is equal to 3600 seconds.
7. Quit Registry Editor.

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

WinRoute routing version changes

The WinRoute tool reports routing versions in the following format: The three numbers that are separated by periods that follow the routing group name are the major version, the minor version, and the user version. Major version changes are typically changes in directory service that involve routing and connectors. If there is a frequent change here, monitor it by using the Remonitor.exe tool, and then investigate it for a probable root cause. For example, an administrator may make significant changes in directory service.

A major version of zero is shown for isolated routing groups with no routing and no link state exchange with other nodes. Additionally, a major version of zero is shown for Microsoft Exchange Server 5.5-based sites because they do not use link state information.

A minor version change may indicate changes to the state of a connector. Frequent changes may be caused by faulty links or by links that fluctuate between the "UP" state and the "DOWN" state. Advanced Queuing (AQ) tries to send a message over a connector. If AQ fails, it sends a notification to routing to mark the connector as "DOWN." Then, AQ initiates retry pings to the connector. After AQ detects that the connector is up, AQ notifies routing by calling the LinkStateNotify() method.

User version changes may occur in the following situations:

• Servers attach to or detach from master nodes.
• Windows Management Instrumentation (WMI) services send data to the routing group master.
• There is callback registration by routing clients such as message transfer agent (MTA) or SMTP.
• There are routing group membership changes.
• You rename the routing group
• A new master node is elected.

For more information about how to use the WinRoute tool, click the following article numbers to view the articles in the Microsoft Knowledge Base: