Sending Messages -- Routing and Transport

Windows IT Pro

- Advertise

Sending Messages -- Routing and Transport
View the book table of contents

Author:	Tony Redmond
Published:	October 2000
Copyright:	2001
Publisher:	Digital Press

      In the case shown in Figure 12, we can see that the warning was issued because the SMTP service tried to send a message to a recipient with a Compaq.com address, but the message couldn’t get through because the domain was unreachable. A simple “PING” command to Compaq.com will usually determine whether the problem still exists, or the NSLOOKUP utility can be used to validate whether the correct name servers are being used for the problem domain. Remember that a successful PING only indicates that the computer is available on the network. Something else might be causing SMTP to fail to connect, or the Exchange services might not be running on the target computer.

      Exchange 2000 servers do not need MX records to enable SMTP message interchange across Routing Group connectors because they use routing information held in the AD rather than DNS. Exchange 2000 servers do need MX records if they communicate with each other across an SMTP connector.

      We’ve already said that the Queue Viewer displays link queues, but isn’t “hotmail.com” a final destination? The answer is yes and no. It is true that impossible.com is the final destination for a message, but it’s also the next hop or link that the message has to travel. In this case, there is an SMTP connector configured on the server with an address space of “*”, meaning that the SMTP connector is able to route messages to any Internet domain. The message sent to “hotmail.com” is placed on the queue for the SMTP connector (its final destination), but its next hop is to “hotmail.com”, which is the reason why this queue is shown. Using the same logic, link queues can be seen for messages going to a server in the same Routing Group. Again, this is a final destination, but it’s also the next hop in the message’s route. The entry for QEMEA-DC17 in Figure 10 is an example of a queue for a server in the same Routing Group.

      Note that link queues are transient and only appear when they are in use. If you go back to refresh the Queue Viewer after the message has been successfully transferred, the queue for “hotmail.com” may not be visible. Queue cleanup happens each time a message goes through the system, and unused or unwanted queues are removed at this point.

      Two special queues are visible — the “Messages awaiting directory lookup” queue and the “Messages waiting to be routed” queue¹¹. The first holds messages that have not yet been processed by the Categorizer. If messages show up in the second queue, it may be an indication that the Categorizer is unable to retrieve the information about available routes from the routing table held in memory. Check that a GC is available and review the contents of the Application event log in the system event viewer to ensure that no errors are reported. The second queue holds messages that have not yet been analyzed to determine which link queue they should be placed on. Again, if messages show up on this queue, it’s an indication that something is not working as planned, so it’s a good idea to check the Application event log and review any errors shown there.

      Messages to other Exchange 2000 routing groups connected by an X.400 connector are sent via the MTA. Sometimes an interim routing group is on the route to the eventual X.400 connection, and if so the routing engine dispatches the message to that routing group, where the message is then reassessed and routed to X.400. Once the message arrives at the server that hosts the X.400 connector, it is placed on the local delivery queue and processed by the Transport Core Store driver, which assesses the recipient list again and makes any local deliveries for mailboxes on this server. The message is then placed into the MTA’s MTS-Out folder in the Store, which is the final stop before it is dispatched out via the X.400 connector.

      The same type of routing occurs for foreign connectors. The routing engine assesses the route to the connector and either dispatches the message directly to the connector, if it is available locally, or routes via another routing group to reach the connector.

      All mail-enabled users, including those that have their mailbox on an Exchange 5.5 also have a value in their HomeMBD attribute, which points to the distinguished name of the mailbox store where their mailbox is held. The routing engine can use this information to consult the routing table to determine whether the server exists in the same routing group, a mixed-mode site, or in another Exchange 5.5 site that must be routed through a connector hosted by an Exchange 5.5 server. Delivery to an Exchange 5.5 server in the same site is routed via the MTA and executed with RPCs.

      Mail-enabled contacts do not have a HomeMDB attribute, so the routing engine consults the TargetAddress attribute, which should contain a routable address in the form “ADDRESS-TYPE: ADDRESS.” For example: “SMTP: Tony.Redmond@compaq.com.” The categorizer encapsulates the found address inside an SMTP address, with the right hand side of the address containing the FQDN of the server that has the most suitable gateway to process the address. Of course, if the address is an SMTP address then no rewrite is necessary and the message can be routed directly to the lowest-cost SMTP connector that is able to handle the address space specified in the address.

Exchange 2000 and MX Records
In a classic SMTP environment, the MX records held in DNS indicate the preferred servers to handle mail traffic for a domain. MX records aren’t strictly required for mail to flow into a domain, as if the MX records aren’t present, external servers will attempt to connect to all the servers listed with “A” DNS records for the domain. In effect therefore, the MX records enable us to channel messages to a set of servers that we can configure to handle mail effectively.

      Exchange 2000 must accommodate two cases when it wants to send messages: connection to a server within the same Exchange organization, or connection to a server outside the organization. The server outside the organization could be another Exchange server, but it could also be a UNIX server running sendmail, or some other server that supports SMTP such as Lotus Notes.

      The AD is consulted to decide whether a target server is inside the organization. If it is, the GUID of the server or connector to use is fetched from the directory and is used to determine the next hop. The routing engine has a special protocol sink that can act as a DNS resolver, but only to take a GUID and look up the AD to retrieve a host name. The resolver responds with either the host name of the server to connect to or one of the servers that can act as a bridgehead for a connector. The resolver then passes the name of the selected server back to the routing engine, which can then check with the AD to get the IP address of the server and proceed to make a connection to port 25 to transfer the message.

      If a target server or domain is outside the organization, a standard DNS lookup is performed to locate an MX record for the name. Three possibilities exist:

An MX record is found. In this case, the routing engine uses the MX record priorities to locate the name of the server to send the message to, and then resolves the name to find the IP address to make an SMTP connection.

DNS responds with “authoritative host not found” for the record, which indicates that DNS was able to contact the root of the DNS tree and verify that not even an “A” record exists for the target domain. The most common cause is that the sender mistyped the address, turning for instance, compaq.com into compak.com. The message is returned to the originator with a non-delivery notification.

No MX record is found, but either the DNS root cannot be reached to make an authoritative determination or an “A” record is found for the domain. In this case, Exchange attempts to use a gethostbyname() call, which performs both a DNS lookup for the A record and also attempts a WINS/NetBIOS name resolution.

In all cases, the end result should be that the routing engine knows where to send the message.

      In summary, Exchange 2000 servers do not need MX records to send messages to other servers either inside or outside the organization, but MX records are used if they exist and are defined in DNS. The routing engine is also able to retrieve information about servers and connectors from the AD and resolve this data into the basic IP address to transfer messages.

ROUTING GROUPS

At first glance, every server in a routing group is expected to enjoy high-speed connectivity with its peers, so the definition of a routing group is very similar to an Exchange 5.5 site. The servers form a point to point full-mesh network with each other to route messages within the group, and it is expected that each server is able to make a connection to another server in the group without waiting for a network link to become available. Servers in Routing Groups send messages to each other via SMTP. The sole exception to this rule is when older Exchange servers operate inside a Routing Group in a mixed mode organization. In this situation, the MTA is used to send messages to the older servers via RPCs.

      While high-speed connectivity is a definite plus, the move away from RPCs in favour of SMTP messages, means that a routing group is able to span a much wider set of computers than an Exchange 5.5 site. RPCs are prone to failure over low latency connections where SMTP is able to connect quite happily. The network link is also expected to be capable of supporting the transfer of even very large messages (>10MB) within the routing group without causing concern.

      Apart from routing messages, Routing Groups also control access to public folder replicas and replace the concept of “public folder affinity” as implemented in Exchange 5.5. (Affinity is now called “Referral” throughout Exchange 2000) A list of available replicas for every public folder is held with other Exchange configuration data in the AD. When a client attempts to access a public folder, Exchange looks for a replica on the same server as the user’s mailbox, and then for a replica on a server within the same Routing Group. If a replica cannot be found, Exchange looks for a replica in other Routing Groups that are connected by connectors that allow public folder referrals¹². The connection cost is used to decide which replica to access if replicas exist in multiple Routing Groups. Connectors are not used to physically access the content in the public folder. A direct network link is created between the client requesting the content and the server hosting the public folder. Naturally, if this link is extended or across low bandwidth connections, access to the public folder is slow. MAPI clients continue to use RPCs to access public folder content, while other clients use their native protocol (IMAP or WebDAV). Most IMAP clients don’t support referrals because the protocol doesn’t include any mention of this functionality.

      Initially, organizations that migrate from Exchange 5.5 will start operating with a Routing Group for every Exchange 5.5 site. After the organization is moved into native mode, consideration can be given to modifying the Routing Group structure. Exchange 5.5 site design is heavily influenced by network connectivity, with the main requirement being the need to transport RPCs between servers in the site. Most of the RPC traffic is taken up with directory replication messages, which is now replaced by AD replication. The number of DCs, the number of domains, the number of GC servers, and the placement of Windows 2000 sites dictate the replication load generated by the AD. Ideally, fewer computers will participate in replication, so the overall load should be reduced. We therefore have an opportunity to take advantage of reduced replication traffic plus the lower bandwidth requirement for SMTP messaging to consider moving servers between Routing Groups and reshape the organization. From a best practice perspective, it is wise to use islands of high bandwidth as the basis for allocating servers to routing groups, but you should be aware that the opportunity now exists to consolidate Exchange 5.5 sites into a smaller number of routing groups after the organization moves into native mode.

      Many Exchange 5.5 designs feature hub and spoke networks, with sites that contain mailbox servers connecting into hub routing sites. The hub sites are usually created to introduce resilience and provide multiple message paths. However, the dynamic nature of link state routing and the way that messages are now routed between Routing Groups reduces the need for hub sites, which affords a further opportunity to simplify the routing infrastructure within the organization.

      In order of importance, the factors that influence the decision to create new Routing Groups include:

Availability of stable network links
The available bandwidth cannot support the automatic on-demand connections made by servers within a Routing Group
A need to schedule connectivity between servers
A need to control the transmission of large messages
A need to restrict the use of connections to particular users, or to deny a connection to particular users

      The first three factors also pertain to Exchange 5.5 sites while the last two are specific to Exchange 2000. The routing engine is flexible, but it depends on some consistency in the network. You will never attain efficient routing if the links between routing groups go up and down all the time. In this scenario, the link state table will be in “continuous update mode,” and messages will be rerouted across connectors in a ping-pong manner. This is the logic that drives the grouping servers into islands of highly available connectivity. The islands (routing groups) can then be linked together with whatever connections are available. If the connections are high-speed, but unreliable, then messages will queue until the connection is available and then be quickly transferred, while messages sent to recipients within the same Routing Group will be delivered immediately.

      Exchange 2000 is very much more flexible than Exchange 5.5 in terms of internal infrastructure. The Move Server Wizard, which is only available for Exchange 5.5 SP2 or higher, can move a server to a new organization or site, but it requires a lot of up-front planning before it can be successfully executed and it certainly is not something that enables servers to be moved around an organization with alacrity. The merge of the Compaq and Digital Exchange organizations (a result of Compaq’s acquisition of Digital) probably provides the best example of the wizard in action. Each company had used Exchange since 4.0 and had deployed worldwide across nearly 400 servers. Planning to move servers from the Digital organization into Compaq started soon after the acquisition, and servers began to be moved in late 1998. The move finished in early 2000, and the elapsed time for the project is testimony to both the complexity of the planning and the need to let the changes made to the organization structure replicate fully after each server was moved¹³.

      The amount of data changed when a server is moved between two Routing Groups is much less than the equivalent Exchange 5.5 operation. All of the issues related to moving Exchange 5.5 servers related to the dependency on distinguished names in the directory. Every object uses the site and organization name as part of their distinguished name, so moving a server to a different site inside the same organization or to a different organization causes thousands, perhaps millions, of distinguished names to be updated. Users are impacted by the move too as their profiles and offline stores contain distinguished names. None of this happens in Exchange 2000, so you can afford to take a much more relaxed attitude to routing group design. Clearly, refining routing group design techniques is an area that will evolve quickly as knowledge is gained from Exchange 2000 deployments. Plan to remain flexible and review the organizational structure every three months or so. Network usage and message delivery times are the key indicators that changes need to be made. If network links become saturated, then something must be done to reduce the traffic that is directed across the link. If message delivery times become extended (more than 15 minutes between individual routing groups, or more than 1 minute between servers in a routing group), then changes in the routing group structure may be called for, depending on the goals of the organization. Some companies will want message delivery times of less than one minute everywhere, while others will be happy if delivery is achieved in less than an hour. Understanding the expectations of users for message delivery time is an important piece of data for a Routing Group design.

      Always remember that Exchange 2000 depends on Windows 2000 far more than Exchange 5.5 relies on Windows NT 4.0. The underlying Windows 2000 infrastructure, particularly the site design and AD replication, is probably going to take far more care and attention than the Exchange 2000 organization. This is a dramatic reversal in roles to the situation that pertains in a Windows NT/Exchange 5.5 infrastructure, where Exchange can use almost any Windows NT design as long as network links are available. In an Exchange 5.5 project, a lot of effort is expended to get the site design right. Now, the same effort must be expended on the AD design and comparatively less attention can be given to routing groups. Remember that if your AD design doesn’t work, no amount of tinkering with routing groups will be able to resolve the problem and messages will not flow smoothly.

¹¹ In early builds of Exchange 2000, these queues were called “PreCatQueue” and “PreRoutingQueue.”

¹² The “Do not allow public folder referrals” checkbox on a connector’s general property page controls referrals. The default is to allow referrals across the connector.

¹³ Servers were not moved during a three-month Y2K moratorium, so the actual elapsed time required to move all the servers was approximately 12 months.

Page: 1, 2, 3, 4, 5, 6, 7, 8

ADS BY GOOGLE