Exchange 2000 and SMTP

Messaging Administration
Exchange Server 5.5 groups servers into sites—one or more servers connected in a common management unit that uses LAN-quality bandwidth. You connect sites to form an organization, a management unit that shares a common directory and configuration. The organization concept remains in Exchange 2000. Only one Exchange 2000 organization can exist in a Win2K forest because servers now share configuration data through AD's configuration naming context.

Win2K uses the term site to describe a collection of servers that share a common network—in this case, one or more IP subnets define the network. Win2K sites are far more tied to the underlying network than Exchange Server 5.5 sites are. I doubt we'll see a Win2K site that spans the world, but I know of several successfully implemented Exchange Server worldwide sites. (For more information, see Ian Tweedie, "Global Site," July 1999.) Win2K sites don't have the same profound administrative effect that sites have in Exchange Server 5.5, in which a site marks the boundary for administrative, security, and replication operations.

Administrative groups and routing groups replace Exchange Server 5.5 sites. An administrative group sets the boundary for management operations. The administrator manages all the servers in an administrative group according to common policies, which might remind you of the way servers in an Exchange Server 5.5 site share settings (e.g., default site addressing). Routing groups define how messages flow between an organization's servers. Each server in a routing group can make a point-to-point connection to another server on a demand basis in exactly the same way that servers connect in an Exchange Server 5.5 site. In mixed-mode organizations, one administrative group and one routing group represent each Exchange Server site. In mixed mode, Exchange 2000 pretends that it uses the site model. Because older servers don't understand the division between administration and routing, Exchange 2000 must mimic the site structure. Later, when all servers are running Exchange 2000, you can switch the organization into native mode and split the groups to form a different structure.

Sites work extremely well in small organizations in which administrators typically monitor management and routing. However, large enterprises often have teams to take care of server management and the email backbone. The good news is that you can manage Exchange 2000 in the same way that you manage Exchange Server 5.5, if those procedures make sense for your company. But Exchange 2000 gives you greater management granularity by letting you allocate responsibilities to different teams. Greater granularity in systems administration is a theme throughout Win2K. Microsoft designed the Microsoft Management Console (MMC) framework so that you can build customized consoles by assembling snap-ins that meet specific needs.

Many large companies operate multiple levels of support from their Help desk. The Help desk, in turn, takes the support calls to backup support, which might take complex problems directly to Microsoft support. Exchange Server 5.5 provides one tool that everyone can use—the Microsoft Exchange Administrator program. Certainly, a single all-in-one tool is convenient. However, why should someone who simply changes users' directory information have access to a tool that administrators who configure complex components such as X.400 or SMTP connectors use?

Screen 4 shows the Exchange 2000 System Manager, an MMC console comprising several snap-ins that is the closest thing you'll find to Exchange Administrator. The fact that you can allocate the snap-ins to different groups makes granularity possible. The screen shows the relationship between administrative groups and routing groups. An administrative group typically has a broader range and scope than a routing group. In this example, three administrative groups manage a worldwide deployment, and each administrative group has one or more routing groups. The QEMEA (European) Administrative Group spans four routing groups (i.e., France, Germany, Ireland, and Valbonne).

Routing Groups
All the servers inside a routing group can communicate with one another automatically. The same situation exists in an Exchange Server 5.5 site, but the servers communicate differently. Remember that Exchange Server 5.5 servers use RPCs, whereas Exchange 2000 servers use SMTP and connect to the standard port 25. Another basic difference between Exchange Server 5.5 and Exchange 2000 is that directory replication generates much of the intrasite traffic between Exchange Server 5.5 servers, whereas the vast majority of email that users send between Exchange 2000 servers is interpersonal communication. Exchange 2000 sends a small amount of data to update servers about the state of the network, but this data represents far less overhead than the overhead of a site's directory replication. Directory replication is now AD's responsibility.

Connecting Routing Groups
You can use the Routing Group Connector (RGC), the SMTP connector, or the X.400 connector to connect routing groups. In some respects, the RGC is the equivalent of Exchange Server 5.5's RPC-based Site Connector. The RGC is easy to set up and configure and is typically the connector of choice. Unlike the Site Connector, the RGC offers you a finer degree of control over the servers that participate in routing. The Site Connector lets you select all servers in a site or a nominated bridgehead server to handle traffic for the site. The RGC lets you nominate as many servers as you want to act as a bridgehead. The RGC also lets you restrict the connector to particular users, define the priority of traffic across the connector (i.e., high, medium, or low), and determine the connector's availability. You can also establish a schedule to control when large messages go across the connector, so you can prevent large attachments from interfering with typical business traffic.

The RGC handles only SMTP traffic and runs under the context of an SMTP virtual server. The RGC is a unidirectional connector, and you must configure both sides of the connection before messages can flow both ways. However, if you have permission to perform administrative operations in the target routing group, you can set up both sides of the connection in one step.

Screen 5 shows the properties of an RGC linking the Ireland routing group with the Valbonne routing group. The Do not allow public folder referrals check box is important. By default, the check box is cleared; therefore, users can connect to public folder replicas on a server in another routing group across this connector. In Exchange 2000, referrals replace Exchange Server 5.5's concept of public folder affinity, and routing groups now achieve the notion of control that sites and locations (or subsites) previously accomplished. When users attempt to access a public folder, Exchange 2000 first attempts to refer the users to a replica of the public folder that resides on the same server as their mailbox. If a replica is unavailable, Exchange 2000 then refers the users to another server within the users' routing group. If a replica is still unavailable, Exchange 2000 attempts to refer the users to a replica of the public folder that resides in a routing group across the lowest-cost connector. Each connector has a cost (i.e., from 1 to 100) that rates the expense (in network terms) of connecting to a target bridgehead. Lower values indicate a preferred route. In the case of the RGC that Screen 5 shows, the cost of the connector is 1, the lowest possible value. This connector is a preferred route to a public folder replica if the replica is available in the Valbonne routing group.

The RGC uses SMTP, so why do we need a separate SMTP connector? The answer is simple—Exchange 2000 is still a small presence in the SMTP world. People want to communicate with other domains that use SMTP, and they'd like to do so in as functional a manner as possible.

Like the RGC, the SMTP connector runs under the context of an SMTP virtual server. The RGC uses the Exchange 2000 configuration data in AD to route messages, whereas the SMTP connector uses standard SMTP routing techniques such as the mail exchanger (MX) records in DNS. Therefore, whenever you want to route messages to a SmartHost system, use MX records as the basis for routing, or simply send messages outside Exchange Server (including to the IMS running on older Exchange servers), you need to use an SMTP connector.

Screen 6 shows an SMTP connector in action. This connector sends all messages to smarthost.compaq.com. Smart hosts are mail servers that often act as central collection and dispatch points for an enterprise's SMTP mail. Bringing messages together to a central point before they leave the company lets you check the messages for viruses and profanity. Smart hosts also let you verify that users are complying with company standards (e.g., attaching disclaimer text on messages, refraining from sending classified information to external correspondents). MIMEsweeper (http://www.mimesweeper.com) is a popular example of software that runs on smart hosts.

Setting up the connector to route all mail to a smart host is one step toward control. You can achieve finer control through the SMTP connector's Address Space property sheet, which is where you define the SMTP domains that Exchange 2000 can reach through the connector. The default setting is an asterisk (*), which means that Exchange 2000 can reach all domains. However, in some cases, you might want Exchange 2000 to handle a specific domain's messages in a certain manner. Screen 7 shows the address space configured for a specific domain (i.e., compaq.com). With this configuration, the connector can only handle messages addressed to a recipient in compaq.com; all other messages must find another route. At the bottom of the dialog box in Screen 7, you can see how Exchange 2000 controls the connector scope. Exchange Server 5.5 introduced the Connector scope feature, which restricts the availability of a connector to other servers. In Exchange Server 5.5, you can restrict a connector to servers at a location, site, or the organization. In Exchange 2000, you can restrict either to the routing group or the organization. In Screen 7, the connector is available only to the servers in the local routing group.

Link State Routing
A connector is simply a link between a routing group and another set of systems. Multiple routing groups and connectors can operate within a company. Therefore, to foster effective decision-making about message routing, you need a mechanism that informs all the servers about these other servers and connectors.

To maintain a list of all possible routes within an organization, Exchange Server 5.5 uses the Gateway Address Routing Table (GWART). A server called the Relative Identifier (RID) master (typically the first server you install in a site) builds the GWART nightly, using information replicated around the organization. The other servers in the site automatically share the GWART. Thus, every server in a site has a common understanding of the available connectors and the best way to route messages.

Exchange Server has used this mechanism since 1996. The GWART is fairly successful, but its nondynamic nature is a major drawback. The GWART works best when the network is stable and servers and connectors are available in a predictable manner. If inoperative connectors introduce a level of unpredictability into the routing equation, the GWART loses some of its effectiveness and the potential for misrouting grows. Misrouting doesn't result in lost messages. However, misrouting can send messages down paths that might lead to a dead end. Such an occurrence requires you to reroute the messages so that they can reach their final destination. Rerouting is expensive and slows message delivery, so you need to avoid it.

We can't all have a wonderfully stable network environment, so we need to move toward a more dynamic way of updating servers about the current state of the network and the routes that are available to send messages. Exchange 2000 uses Link State Routing. LSR lets servers update one another about changes that occur to network links or connectors. Information about those changes broadcasts quickly to other routing groups so that their picture of the network is current.

Imagine that a network error causes a connection to a routing group to fail. After 60 seconds, the bridgehead server makes a second attempt to contact the bridgehead server in the remote routing group to determine whether the fault is a temporary glitch. If the connection fails, the bridgehead server tries twice more before concluding that the problem is persistent. The server marks the link as down and establishes a connection (using port 3044) to the Routing Group Master. Each routing group nominates a Routing Group Master to collect updates from the servers in the routing group and also to collect updates from other routing groups. With that information, the Routing Group Master builds a Link State Table (LST), which represents the current state of the routing network. The Routing Group Master is typically the first server you install into a routing group, but you can easily use the Exchange System Manager console to transfer this role, as Screen 8 shows.

After the Routing Group Master receives the update about the inoperative link, it adjusts its LST and broadcasts details about the new LST to all the routing group's servers. Once again, communication takes place through port 3044 using a special protocol called LSA, which Microsoft developed for this purpose. Exchange 2000 uses an ESMTP extension called X-LINK2STATE to send link-state updates between routing groups across the RGC and SMTP connectors. Exchange 2000 sends updates between bridgehead servers, which then pass the updates to the Routing Group Master in the local routing group. Exchange 2000 can also send updates in the form of application-specific data across X.400 connectors. The passed data is highly compressed, so Exchange 2000 needs only a matter of seconds to pass the information and create a new LST for the routing group. The addition of new servers or the creation of new connectors also initiates link-state updates.

Link-state updates ripple quickly through an organization. The aim is to reach every server in an organization within a matter of minutes—rather than hours or days, as can happen today. Updates travel as quickly as messages move between servers. Because Exchange 2000 needs to transfer so little data, link-state updates typically move across extended links before administrators realize that a problem exists.

The Future of Messaging
I've only scratched the surface of Exchange 2000's new technology. In addition to the split between administration and routing, the messaging system offers a host of settings that you can apply to the SMTP service and its virtual servers to make messages flow. Also, to link the servers in an Exchange Server organization together, we have a set of new connectors. If that weren't enough, the topic of link-state routing is substantial enough to warrant a separate discussion in its own right.

Above all, the fact that Exchange 2000 is very different from its predecessors is clear. Given that Exchange 2000 can run only on Win2K and that you must have a solid infrastructure in place before you deploy your first Exchange 2000 server, your knowledge of how SMTP works with Exchange 2000 might take time. However, you need to understand now that SMTP is just one of the close dependencies that exist between Win2K and Exchange 2000. SMTP represents the future of message routing in Exchange Server.

End of Article

   Previous  1  [2]  Next