Tài liệu Module 9: Creating and Managing Routing Groups in Exchange 2000 ppt

Link State Table Connector The routing process for a message begins when Microsoft® Exchange 2000 receives a message either from a user, another computer running Exchange, or a foreign m

Routing Groups in Exchange 2000

with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, MS-DOS, MS, Windows, Windows NT, Active Directory directory service, ActiveX, BackOffice, FrontPage, Hotmail, MSN, Outlook, PowerPoint, SQL Server, Visual Studios, and Win32, are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries

The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

Project Lead: David Phillips

Instructional Designers: Lance Morrison (Wasser), Janet Sheperdigian, Steve Thues

Lead Program Manager: Mark Adcock

Program Manager: Lyle Curry, Scott Hay, Janice Howd, Steve Schwartz (Implement.Com), Bill Wade (Wadeware LLC)

Graphic Artist: Kimberly Jackson, Andrea Heuston (Artitudes Layout and Design)

Editing Manager: Lynette Skinner

Editor: Elizabeth Reese (Write Stuff)

Copy Editor: Ed Casper (S&T Consulting), Carolyn Emory (S&T Consulting), Patricia Neff

(S&T Consulting), Noelle Robertson (S&T Consulting)

Online Program Manager: Debbi Conger

Online Publications Manager: Arlo Emerson (Aquent Partners)

Online Support: Eric Brandt

Multimedia Developer: Kelly Renner (Entex)

Compact Disc Testing: Data Dimensions, Inc

Production Support: Ed Casper (S&T Consulting)

Manufacturing Manager: Bo Galford

Manufacturing Support: Rick Terek

Lead Product Manager, Development Services:

Lead Product Manager: David Bramble

Group Product Manager: Robert Stewart

# 0RGXOH#<=#&UHDWLQJ#DQG#0DQDJLQJ#5RXWLQJ#*URXSV#LQ#([FKDQJH#5333# # LLL#,QVWUXFWRU#1RWHV#

This module provides students with knowledge and skills to design, implement, and manage routing groups This module explains the message routing

algorithms used in Microsoft® Exchange 2000 Routing groups and the link state table are explained Various routing scenarios are discussed and analyzed

At the end of this module, students will be able to:

„#Describe the components that enable message routing between servers and routing groups

„#Explain what the link state table is and how it is used for message routing

„#Describe the routing algorithm used to determine the path for a message

„#Design routing groups for a given situation

„#Create and manage routing groups and routing group connectors

0DWHULDOV#DQG#3UHSDUDWLRQ#

This section provides you with the required materials and preparation tasks that are needed to teach this module

5HTXLUHG#0DWHULDOV#

To teach this module, you need the following materials:

• Microsoft PowerPoint® file 1569A_09.ppt 3UHSDUDWLRQ#7DVNV#

To prepare for this module, you should:

„#Read all of the materials for this module

„#Complete the lab

„#Practice your demonstration

restart by right-clicking on the PreRoutingQueue, and then clicking Make Connection Active

# 0RGXOH#<=#&UHDWLQJ#DQG#0DQDJLQJ#5RXWLQJ#*URXSV#LQ#([FKDQJH#5333# # Y#

0RGXOH#6WUDWHJ\#

Use the following strategy to present this module:

„#Overview of Message Routing in Exchange 2000 Give an overview of message routing, defining terms and making a clear distinction from previous versions of Exchange

„#Routing Groups Describe the characteristics of a routing group

„#Connecting Routing Groups List and describe each of the connectors that can be used to connect routing groups

„#Link State Describe the link state table and how its information is used to determine message routes

„#How Messages Are Routed Explain how messages are transferred from sender to recipient for a variety

of scenarios Present each slide, keeping the focus on that specific scenario, rather than using one slide to explain every scenario

„#Designing Routing Groups Discuss routing group designs, including what servers can be part of a routing group, when to use multiple routing groups, and how to choose a connector

„#Creating Routing Groups and Routing Group Connectors Demonstrate how to create a routing group and a routing group connector

# 0RGXOH#<=#&UHDWLQJ#DQG#0DQDJLQJ#5RXWLQJ#*URXSV#LQ#([FKDQJH#5333# # 4#2YHUYLHZ#

preventing the ping-pong effect, if a link has failed With the flexibility comes additional complexity in planning and properly grouping servers within a routing group

At the end of this module, you will be able to:

„#Describe the components that enable message routing between servers and routing groups

„#Describe requirements for routing groups and when to use multiple routing groups

„#Describe the connectors used to connect routing groups

„#Explain what the link state table is and how it is used for message routing

„#Describe the routing algorithm that is used to determine the path for a message

„#Create and manage routing groups and routing group connectors

Link State Table

Connector

The routing process for a message begins when Microsoft® Exchange 2000 receives a message either from a user, another computer running Exchange, or a foreign messaging system through a connector or gateway The server running Exchange 2000 looks up the recipient in Active Directory™ directory service and routes the message to the recipient

5RXWLQJ#*URXSV##

Routing groups are groups of servers running Exchange 2000 that are connected over reliable, permanent links From a topological perspective, routing groups are equivalent to sites in previous versions of Exchange

Separating servers into routing groups enables you to control mail flow, trouble-shoot message transfer between groups of servers, and track messages Exchange 2000 uses Simple Mail Transfer Protocol (SMTP) as its primary protocol, rather than RPC (Remote Procedure Call), which was used by previous versions of Exchange With SMTP, it is not as important to have a high bandwidth connection between servers SMTP is more reliable over limited bandwidth connections than is RPC It is more important that servers in

a routing group have permanent, reliable connectivity than high bandwidth between them

# 0RGXOH#<=#&UHDWLQJ#DQG#0DQDJLQJ#5RXWLQJ#*URXSV#LQ#([FKDQJH#5333# # 6#

&RQQHFWRUV#

Routing groups are connected using connectors Following is a list of connectors available with Exchange 2000 that can connect routing groups together:

„#Routing group connector

„#Simple Mail Transfer Protocol connector

„#X.400 connector Connectors designed for third party mail systems cannot be used to connect routing groups

/LQN#6WDWH#

The Exchange 2000 routing and selection process uses a link state table to determine the shortest path between two routing groups for a given message To provide an efficient fault tolerant routing mechanism, Exchange 2000 uses a link state table The link state table is stored on each server running

Exchange 2000 and contains the status of each connector in the Exchange 2000 organization If a server running Exchange 2000 cannot find a route for a particular message after referring to the link state table, it will not attempt to deliver the message

as needed in a single hop Servers running Exchange 2000 in the same routing group are assumed to have reliable, permanent network connectivity between them

When you plan your routing topology, you should take into consideration the physical locations that you have, how they are connected, and whether or not you want to control message flow This exercise is similar to designing Exchange sites in earlier versions of Exchange and similar to designing Microsoft Windows® 2000 Active Directory sites

Servers within a routing group communicate directly to each other The following must apply to servers within the same routing group:

„#Servers running Exchange must belong to the same Active Directory forest

„#Servers running Exchange must have permanent direct SMTP connectivity

„#Network connectivity is unreliable

• Network traffic is saturated to the point that communications are not reliable

• The underlying network experiences frequent problems

„#You want to control the message paths within an Exchange organization For example, the messaging path needs to be altered from single-hop to multi-hop, such as when servers are located in separate physical locations, but communicate in a single-hop environment

„#You want to schedule messaging between two locations

If you have a single physical location and all servers are connected through a reliable, permanent link, you may not require multiple routing groups

In earlier versions of Exchange, the site topology had to take into account the possible message ping-pong that would occur if sites had multiple routes between them This meant that most site topologies were hub-and-spoke, with only a single connector between the hub and each spoke With Exchange 2000 and the link state table, this topology is not necessary because messages are not bounced back and forth If a connector fails, the message may be rerouted through another routing group, but will not bounce back to the original routing group

0HVVDJH#7UDIILF#$QDO\VLV#&DQ#+HOS#'HILQH#%RXQGDULHV#Message traffic analysis can provide helpful information regarding which servers communicate with each other the most It can be efficient to include servers that communicate regularly in the same routing group However, designing routing groups solely based on traffic analysis, without regard to management overhead, may not be the most efficient solution

$GGLWLRQDO#&RQVLGHUDWLRQV#

Some additional considerations may impact how you design a routing group

„#Servers can be connected over slow (but reliable) links as part of the same routing group

„#Routing groups are dynamic, and they can be changed at any time

„#The routing group architecture determines public folder access

Bridgehead Server

Bridgehead Server

Communication between servers in different routing groups is accomplished by using connectors You can use any of the following connectors to connect two routing groups:

„#Routing group connector

„#SMTP connector

„#X.400 connector The Routing Group Connector can only connect routing groups Other connectors provide connections to foreign systems in addition to connecting routing groups within an organization

When you configure a connector on a server, the connector is included in the routing process for messages destined outside of the routing group Servers running Exchange 2000 that host routing group connectors are called

bridgehead servers All messages that are delivered between routing groups

pass through the bridgehead server that hosts the routing group connector

Bridgehead Server

Bridgehead Server

Bridgehead Server

The routing group connector provides the simplest, easiest way to connect two routing groups The routing group connector is similar in function to the Site Connector in previous versions of Exchange However, a major difference is that the routing group connector uses the SMTP message transport protocol rather than remote procedure calls (RPC) to deliver messages Benefits of the routing group connector are:

„#It is easy to configure

„#It can be configured with multiple target bridgehead servers

„#It can be used to connect to previous versions of Exchange that are configured with the Site Connector, which uses RPCs

0XOWLSOH#%ULGJHKHDG#6HUYHUV#

The routing group connector can be configured with one or more bridgehead servers on either end of the connector This allows you to control which servers send and receive messages between routing groups An advantage of having multiple servers identified as bridgehead servers for a routing group connector

is that if a bridgehead server is down, Exchange can choose another bridgehead server within the routing group to transmit the message

When the bridgehead server that hosts the Routing Group Connector receives a message to be delivered across the connector, the bridgehead server tries to resolve the target server’s Internet Protocol (IP) address by using the standard SMTP resolution process That is, the bridgehead server first tries to resolve the target server defined on the Routing Group Connector by using Domain Name System (DNS) mail exchange (MX) records If no MX records exist for the target server, which is not unusual, then a DNS query for an A record for the target server is performed This means that an A record must exist in DNS for all servers running Exchange When the Windows 2000 version DNS is used, all Windows 2000-based servers, including servers running Exchange 2000, automatically register A records in DNS

If, for some reason, an A record for the target server is not found, the bridgehead server will try to resolve the IP address by using the network basic

input/output system (NetBIOS) name resolution process

When multiple target servers exist for a Routing Group Connector, then before SMTP resolves the MX record against a DNS server, Exchange 2000 code intercepts the request, looks up the bridgehead servers, and returns them to SMTP

In short, Exchange performs MX record resolution for SMTP but usually will resolve the target server by using an A record This simplifies the configuration

of the Routing Group Connector because an Exchange or a DNS administrator does not have to create or manage MX records

In Exchange 2000 Beta 3, NetBIOS name resolution is used to resolve bridgehead server IP addresses

1RWH#

Bridgehead Server

Bridgehead Server

Bridgehead Server

SMTP connectors can be used to connect routing groups They should be used when:

„#The other side of the connector is the Internet Mail Service (IMS) from previous versions of Exchange

„#When a pull-relationship is required between servers Where one side

queues messages and the other side pulls them by using the TRN or ETRN

attempt to resolve the destination server by using the host name resolution

process, which includes querying DNS for an A record If the destination server

is still not found, the bridgehead server tries to resolve the IP address by using the NetBIOS name resolution process

When multiple target servers exist for an SMTP connector, Exchange 2000 code intercepts the request, looks up the target servers, and returns them to SMTP before SMTP resolves the MX record against a DNS server

With an SMTP connector, you can optimize the message transport to a greater extent than with a Routing Group Connector SMTP connector options include authenticating remote domains before sending mail, designating specific times when mail can be sent, and setting multiple permission levels for multiple users

destination by using DNS

A smart host is helpful for messages traveling between servers over the Internet, such as when the remote domain can only be reached during certain times or infrequently Instead of repeatedly contacting the domain until a connection is made, the server running Exchange only needs to transmit to the smart host Then the smart host makes the remote connection

If a smart host is not designated, a DNS lookup will be made on every address

to which the SMTP connector sends e-mail

If you use an IP address to identify the smart host, enclose the address in brackets ([ ]) to increase system performance The SMTP service first checks for a server name, then an IP address The brackets identify the value as an IP address, so that the DNS lookup is bypassed

5HPRWH#7ULJJHUHG#'HOLYHU\#

You can configure the SMTP connector to retrieve queued e-mail from a remote SMTP server at specified intervals That is, a remote domain can be configured to receive and hold e-mail on behalf of the destination domain

Messages sent to the remote domain are held until the SMTP ETRN command

is received from an authorized account on your local server running Exchange

The ETRN command can also be used to dequeue e-mail Select the Request that remote servers dequeue mail at these times check box, then select the

times that you want the SMTP connector to contact the remote domain and trigger the delivery of queued mail

1RWH#

Cost = 10

Cost = 20

You can use an X.400 connector to establish an X.400 messaging route between two routing groups or between a routing group and an X.400 system An X.400 messaging route defines the path that an X.400 message follows to reach its final destination

Use the X.400 connector to connect routing groups in the following situations:

„#When the network connection between routing groups is X.25

„#When the network connection between routing groups is over Remote Access Service (RAS)

You can configure multiple X.400 connectors, each using different transport

stacks, such as X.25, Transport Control Protocol (TCP), or remote access

functionality To connect two routing groups, you must configure X.400 connectors in both routing groups to create a two-way connection

To provide load balancing and fault tolerance between two routing groups with the X.400 connector you need to configure multiple connectors

Exchange offers several ways to route mail to people outside of your company

or to mail systems other than Exchange You can route mail to SMTP recipients over the Internet or to X.400 recipients through an X.400 provider

In addition, you can use the following connectors to connect to a non-Exchange systems:

Like Exchange Server 5.x, Exchange 2000 determines the route that a message

will take based on a least cost algorithm However, a server running Exchange 2000 also has a map of the entire messaging topology of which it is a member This map, represented in what is called the link state table, is updated regularly and propagated among all the servers so that each server can

determine not only the cheapest way to deliver a message, it can also determine whether all of the connectors that make up the route are functioning

There are only two states for any given link: UP or DOWN; so connection information, such as whether a link is active or in a retry state, is not propagated and is only known on the server involved in the message transfer

5RXWLQJ#*URXS#0DVWHUV#

The administrator designates a server to be the routing group master for a routing group The routing group master maintains link state information received from different sources The routing group master tracks this data and propagates it to the rest of the servers within the routing group The first server added to a routing group becomes the routing group master, but this can be changed through the Exchange System Manager console

If the routing group master fails, an administrator must designate a new routing group master The servers running Exchange 2000 in the routing group will continue to use the existing link state table, without updates, until the original routing group master returns or a new routing group master is designated

The status of connectors can be viewed from the Exchange System

Manager, under Tools, Monitors

„#Each server running Exchange makes the best routing choice at the time it receives a message, by using the latest information from the link state table,

so that messages are not sent along a path where a link may have failed

„#The link state algorithm eliminates message bounce between servers, because each server running Exchange 2000 knows whether other alternate

or redundant links are UP or DOWN

„#The link state algorithm overcomes message ping-pong problems

Routing Group Master

Routing Group Master

Routing Group Master

Port 25

3044 3044

1 The bridgehead server with the new connection status marks the connector

as UP or DOWN in the link state table

2 The bridgehead server updates the routing group master over TCP port

3044

3 The routing group master updates its link state table and updates all of the other servers running Exchange 2000 in the routing group over TCP port

3044

4 All other bridgehead servers in the routing group update the routing groups

to which they are connected over TCP port 25

5 Those bridgehead servers update their routing group masters over TCP port

3044, and so on until all routing groups have been updated

The link state status is transferred by using an SMTP command rather than a message Therefore, status updates cannot be lost

# 0RGXOH#<=#&UHDWLQJ#DQG#0DQDJLQJ#5RXWLQJ#*URXSV#LQ#([FKDQJH#5333# # 4<#

5HFRYHULQJ#D#&RQQHFWLRQ#

When a connection fails, the bridgehead server with the failed connector continues to retry the connection at 60 second intervals This interval cannot be configured

Although messages have been rerouted, the bridgehead server continues to try

to open port 25 on the destination server After a connection is re-established, the bridgehead server notifies the local routing group master that the connection

is available The routing group master, in turn, notifies all of the servers in the routing group that the connection is available Finally, all bridgehead servers in the routing group notify the bridgehead servers to which they are connected in adjacent routing groups