9.11 Understanding routing

---

Most of the time, things just work and messages flow reliably, so you do not have to worry about all the behind-the-scenes processing. When things go wrong, it is useful to have a set of tools to use to understand how the Transport Engine and the connectors process messages. WinRoute helps you understand the link state table, while SMTP logging and archiving capture information about the flow and format of messages processed by Exchange.

9.11.1 WinRoute

The link state table only exists in memory. Most administrators are not equipped to interrogate data held in memory, and viewing queues is not always the best way to understand how routing works. WinRoute began as a Microsoft support tool and is now part of the shipping product (see the \ support\utils\i386 directory on the server CD); it is the best way to gain an insight into how the Exchange routing topology works.

You can launch WinRoute from the server CD, but it is more convenient to move the executable into the same directory as the rest of the Exchange binaries. You can also run WinRoute on a Windows XP Professional workstation. Apart from some bug fixes, the version of WinRoute provided with Exchange 2003 is no different from the version used with Exchange 2000.

WinRoute works by connecting to an Exchange server as if it were another Exchange server and then requesting the current link state table. WinRoute then interprets the data before displaying it, as shown in Figure 9.42, which illustrates data taken from the HP production environment. You can see some of the native link state data in the lower panel. It is composed of a series of GUIDs and other binary information that Win- Route resolves by reference to the configuration data in the AD. Sometimes WinRoute cannot resolve the GUIDs and you will see "object_not_found_in_ds" displayed instead of connector names. Normally, this is due to temporary glitches between Exchange and the AD, perhaps because you removed a server that was a routing group master or hosted a connector and replication is not yet fully complete. In this situation, WinRoute may encounter some outdated information and is unable to turn the contents of the link state routing table into people-friendly displays. Replication latency is the root cause in the vast proportion of such instances, and the errors in interpretation do not affect effective message routing. You can either ignore the glitches by waiting for replication to complete, or flush the cached data that WinRoute depends on by stopping and restarting either IIS or Exchange. This is acceptable practice on a test box but not on a production server, so most administrators overlook this small WinRoute bug.

Figure 9.42: The WinRoute utility.

The upper two panels are most important in interpreting WinRoute information. The top panel displays the routing topology as normally visualized through ESM, with the organization broken down into routing groups and connectors. You can expand objects to discover information such as version numbers, details of bridgehead servers, restrictions, and so on (Figure 9.43). All of this information is available through ESM, but WinRoute makes it available more quickly and in a format that allows you to capture the data to a .rte file for later analysis with the File/Save option, perhaps even when working offline. This facility is also useful when problems occur, since you can give the WinRoute file to Microsoft PSS to help isolate the problem or identify a bug. Analysis of the data in a captured .rte file can also verify that the expected routing topology is in use.

Figure 9.43: Details exposed by WinRoute.

The middle panel reveals the set of connectors known by the server. You can sort the data by address space, address type, cost, restrictions, connector name, routing group, and administrative group. Address type includes standard values of "RG" (routing group), "SMTP," and "X400," as well as types used by nonstandard connectors, such as "FAX," "SMS," and "NOTES."

As with any tool, WinRoute is not a solution in itself. However, its value increases with the size of the Exchange organization. Anyone can understand the routing topology of a single server organization, and it is not difficult to comprehend how messages flow between two or three routing groups, especially if you only use routing group connectors. Organizations that span 20 or more administrative groups, that incorporate nonstandard connectors, or that operate multiple SMTP connectors for external communications are a different matter, and it is almost impossible for a person to grasp the full picture through ESM. WinRoute is, therefore, an invaluable tool for enterprise Exchange administrators.

---