0989709

Module 9: Managing
Routing
Contents
Overview 1
Lesson: Explaining How Message Routing
Works in an Exchange Organization 2
Lesson: Configuring Routing in an
Exchange Organization 9
Lesson: Explaining Internet Connectivity
Concepts and Protocols 26
Lesson: Managing Connectivity to the
Internet 39
Discussion: Managing Routing 61
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part
of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted
in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft Corporation.
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.
 2003 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Windows Server, ActiveSync, ActiveX, Active
Directory, Hotmail, MSDN, MSN, Outlook, PowerPoint, Visual Basic, and Windows Media are
either registered trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Module 9: Managing Routing iii
Instructor Notes
Presentation: Administrators assemble servers running Microsoft® Exchange Server 2003
60 minutes into routing groups to control message traffic and to help Exchange route
messages more efficiently. This module provides students with the knowledge
Practices: and skills that they will need to configure routing groups and to manage their
80 minutes connectivity to the Internet.
After completing this module, students will be able to:
! Explain how message routing works in an Exchange organization.
! Configure routing in an Exchange organization.
! Explain Internet connectivity concepts and protocols.
! Manage connectivity to the Internet.
Required materials To teach this module, you need the following materials:
! Microsoft PowerPoint® file 2400B_09.ppt
! Module 9 video file 2400B_09_v05.wmv
! Module 9 animation, How Messages Are Routed Within and Between
Routing Groups, 2400B_09A_05.html
Important It is recommended that you use PowerPoint 2002 or later to display

the slides for this course. If you use PowerPoint Viewer or an earlier version of
PowerPoint, all the features of the slides may not be displayed correctly.
Preparation tasks To prepare for this module:

! Read all of the materials for this module.
! Complete the practices and review the discussions and assessment
questions. Where possible, anticipate alternate answers that students may
suggest and prepare responses to those answers.
! Review the animation.
! Complete the demonstration regarding how to use Connectix Virtual PC,
which is in the Introduction module of this course. All students must watch
you perform this demonstration. It is crucial that students become familiar
with the virtual environment that is used in the practices before they attempt
to complete the first practice in this module on their own.
! Review the links and suggested additional readings for this module.
Document your own suggested additional readings to share with the class.
Classroom setup The classroom should be set up to use Connectix Virtual PC software, as
discussed in the Manual Classroom Setup Guide. No additional classroom setup
is needed.
iv Module 9: Managing Routing
How to Teach This Module

This section contains information that will help you to teach this module.
Instructor notes have been written only for the topics that required them.
If no student practice is included in a How-to topic, consider demonstrating the
task for students.
How to start Start this module by telling students that there are four lessons. In the first
lesson, they will learn how message routing operates in an Exchange
organization. In the second lesson, students get to configure routing in an
Exchange organization. The third lesson explains Internet connectivity concepts
and protocols. In the fourth lesson, students get to manage connectivity to the
Internet.
After you discuss the tasks on the module overview slide, show the brief video
from a Northwind Trader’s employee before you continue with the module. To
start the video, click the video button on the overview slide, or open the Web
page on the Student Materials compact disc, click Multimedia, and then click
the title of the video. In this video, students will be given overall instructions
for tasks from their team lead or co-worker at Northwind Traders. You can play
this video again at the beginning of the first practice in the module if you think
it will help motivate students.
Time to teach this We anticipate that your total presentation time will be about 1 hour. The
module majority of the time spent on this module should be time that students get to
complete hands-on practice activities, view multimedia presentation, and
participate in discussions. In addition to your presentation time, we anticipate
that hands-on time for students will be about 1 hour and 20 minutes.
Tip When this symbol appears on the lower-right corner of a slide, it indicates
that there is an inline practice for students to complete before you move on to
the next slide:
Practices Some practices in this module require initial startup time. Consider having
students perform the initial step in these practices before you begin the lecture
on the related content. If a practice begins with a procedure titled “To prepare
for this practice,” then it requires initial startup time.
You may wish to create an additional Virtual PC running Exchange server in a
separate organization for testing the Simple Mail Transfer Protocol (SMTP)
practices in this module. Due to space limitations on the Trainer Materials
DVD, we are unable to provide a Virtual PC for this purpose.
Module 9: Managing Routing v
Lesson: Explaining How Message Routing Works in an Exchange

Organization
What Are Routing Use the first two topics to briefly introduce the concepts of routing, routing
Groups? groups, multiple routing groups, and routing group connectors.
When Is More Than One Use the animated slide to first review the conditions in which one routing group
Routing Group will work for an Exchange organization. Then review the reasons why a
Necessary? company would decide to use more than one routing group.
Multimedia: How To show the animation, click the projector button on the slide or open the Web
Messages Are Routed page on the Student Materials compact disc, click Multimedia, and then click
Within and Between the title of the animation. When the animation is over, answer any questions
Routing Groups that the students may have before you move on to the practice.
Emphasize to students that if they want to view the animation again on their
own, they can open the Web page on the Student Materials compact disc, click
Multimedia, and then click the title of the presentation.
While the animation is running, draw a diagram on the white board that depicts
the routing groups, servers, and connectors that are defined in discussion
questions that follow. When the animation is over, use the discussion questions
that are provided and the diagram that you drew to facilitate a discussion.
The discussion questions were designed to help you confirm that students
understand how routing works. In the second question, students are given a
scenario in which they must decide which servers will be used to route
messages in a fictitious Exchange organization. Have students explain the
reasoning behind their answers.
Lesson: Configuring Routing in an Exchange Organization

The Connectors That Use this slide to briefly describe the three connectors that Exchange supports
Exchange Supports and mention that the Routing Group connector is the recommended connector.
Mention that the Routing Group connector, the specific name of a type of
connector, is different from the generic routing group connector, or connector,
which is discussed in this module.
Considerations for Use these three slides to discuss the issues that administrators must consider as
Using Routing Group they choose connectors.
Connectors
Practice: Deciding on This brief practice is designed to help you confirm that students will be able to
the Best Way to Connect decide which type of routing group connector will work for their Exchange
Routing Groups organization. The students are given two scenarios in which they must decide
which routing group connector to use in a fictitious Exchange organization. The
students are then asked to explain their answers.
Give students approximately seven minutes to read the scenarios, decide on a
solution, and write down their explanation. Then, discuss the solutions as a
class. Or, if you have time, have students work in pairs to decide on solutions
and then have each pair present their solutions to the class.
vi Module 9: Managing Routing
How to Create a Routing Use the slide to discuss the high-level steps for creating a routing group. Then,
Group have students complete the inline practice and answer any questions that they
have.
How to Create a Routing Use the slide to discuss the high-level steps for creating a routing group
Group Connector connector. Then, have students complete the inline practice and answer any
questions that they have.
How to Monitor Server, Use the slide to discuss the high-level steps for monitoring server, connector,
Connector, and and resource status. Then, have students complete the inline practice and
Resource Status answer any questions that they have.
Lesson: Explaining Internet Connectivity Concepts and Protocols

Consider asking your students if the topics in this lesson are new to them. If
they are not new topics, you may want to just give a high-level review of this
lesson and then move on to the next lesson.
How an SMTP Use the illustration on the slide to go through the steps in the process of how an
Connection Works SMTP connection works. Refer students to Request For Comments (RFCs)
2821 and 2822 for more information.
Common SMTP You can use the slide to show common SMTP commands. The reply codes are
Commands and Reply shown in a table in the student workbook.
Codes
How an ESMTP Use the slide to first explain what SMTP Service Extensions (ESMTP) are.
Connection Works Then, use the illustration on the slide to go through the steps in the process of
how an ESMTP connection works. Refer students to RFC 2821 for more
information.
Common ESMTP Use the slide to describe the most common ESMTP commands. Mention to
Commands students that the table in their workbook contains even more ESMTP
commands.
Practice: Explaining This brief practice is designed to help you verify that students understand the
Internet Connectivity Internet connectivity concepts and protocols that you have been discussing. The
Concepts and Protocols students are given two brief scenarios in which they must choose which
commands to use. Give students approximately five minutes to read the
scenarios and come up with solutions. Then, discuss the solutions as a class.
What Are MX Records? Use the slide to explain what MX records are. Then, step through the four
examples in the student workbook to help the students understand how mail
exchanger (MX) resource records would be configured in different situations.
How to Configure DNS Use the slide to discuss the high-level steps for configuring Domain Name
to Support an Exchange System (DNS) to support an Exchange organization. Then, have the students
Organization complete the inline practice and answer any questions that they have.
Module 9: Managing Routing vii
Lesson: Managing Connectivity to the Internet

Steps You Can Take to Emphasize that although Internet connectivity is managed automatically by the
Control Internet E-Mail default SMTP server, the students can complete these steps to control message
Access flow in and out of their Exchange organization.
How to Create and Use the slide to discuss the high-level steps for creating and configuring an
Configure an SMTP SMTP connector. Then, have students complete the inline practice and answer
Connector any questions that they have.
Methods for Securing As you discuss the methods for securing SMTP traffic, use the animated slide to
SMTP Traffic first focus the students’ attention on authentication, then on encryption, and
finally on reverse DNS lookup.
Mention to students that IP spoofing and SMTP spoofing are different. If
someone is spoofing an IP address, a reverse DNS lookup will show that the
correct server sent the message although it did not. If someone is spoofing an
SMTP domain, a reverse DNS lookup will make sure that the IP address (and
the fully qualified domain name) of the server sending the e-mail message
matches the message sender’s domain name.
How to Restrict User Start this topic by discussing why an administrator would want to restrict a user
Accounts from Sending from sending Internet e-mail. Then, use the slide to discuss the high-level steps
Internet E-Mail for restricting a user account from sending Internet e-mail. Finally, have the
students complete the inline practice and answer any questions that they have.
How to Configure SMTP Start this topic by defining SMTP relaying. The slide mentions six different
Relays in Exchange methods that can be used to accomplish SMTP relaying, and the student
workbook provides high-level steps for each of these methods. The practice
focuses on configuring an Internet e-mail connector to use a relay host for
outbound SMTP messages. Have students complete the inline practice and then
answer any questions that they have.
When to Use and Use the animated slide to teach this topic. The first two mouse clicks in the
Restrict Open Relaying animated slide show an e-mail relaying attack in progress. The final mouse
in Exchange click shows when you should consider restricting open relaying (always
consider it), and it shows an example of when restricting open relaying is not
possible.
How to Prevent and Use the slide to discuss the high-level steps for preventing and restricting open
Restrict Open Relaying relaying. Then, have the students complete the inline practice, which has them
in Exchange use the SMTP connector to override the relay settings on the SMTP virtual
server.
How to Connect Use the slide to discuss the steps in this procedure. Consider demonstrating this
Exchange Servers to the task to the students, because they are not asked to practice it.
Internet by Using
Routing and Remote
Access
How to Configure Use the slide to discuss the high-level steps for configuring Exchange to
Exchange to Retrieve retrieve e-mail from an Internet service provider (ISP). Then, have students
E-Mail from an ISP complete the inline practice and answer any questions that they have.
How to Identify The task that this topic describes is one of the most common troubleshooting
Problematic E-Mail tasks that Microsoft Product Support Services group performs. Discuss the two
Domains troubleshooting commands.
viii Module 9: Managing Routing
Discussion: Managing Routing

The scenarios in this discussion were designed to allow students to reflect on
what they did in the module and to give them an opportunity to ask any
remaining questions that they have. Use the discussion scenarios to provide a
summary of the module content. You can also return to the Module overview
slide and use it to help summarize the lessons that are covered in this module.
You can do this activity with the entire class. Or, if you have time, have
students work in small groups to come up with solutions to the problems in the
scenarios and then present and discuss their ideas with the class.
Before taking part in the discussion, students should have completed all of the
practices. Students who have not completed the practices may have difficulty
taking part in the discussion.
Tip To facilitate the discussion for the first scenario, draw a diagram on the
white board that depicts the routing groups, servers, and connectors that are
defined in the scenario. Use the diagram to facilitate the discussion.
Assessment
Assessment questions for this module are located on the Student Materials
compact disc. You can use the assessment questions in whatever way you think
is best for your students. For example, you can use them as pre-assessments to
help students identify areas of difficulty. Or, you can use them as post-
assessments to validate learning. Consider using the questions to reinforce
learning at the end of the day or at the beginning of the next day. If you choose
not to use the assessment questions during class, show students where they are
so that they can use them to assess their own learning outside of class.
Module 9: Managing Routing 1
Overview
*****************************ILLEGAL FOR NON-TRAINER USE******************************

Introduction Messaging administrators assemble servers running Microsoft® Exchange
Server 2003 into routing groups to control message traffic and to help Exchange
route messages more efficiently. Configuring routing groups and managing
their connectivity to the Internet are important parts of an administrator’s day-
to-day job.
Objectives After completing this module, you will be able to:
! Explain how message routing works in an Exchange organization.
! Configure routing in an Exchange organization.
! Explain Internet connectivity concepts and protocols.
! Manage connectivity to the Internet.
2 Module 9: Managing Routing
Lesson: Explaining How Message Routing Works in an

Exchange Organization

Introduction This lesson explains what routing groups are and how message routing works in
an Exchange organization. You must understand these concepts to effectively
manage routing in an Exchange organization.
Lesson objectives After completing this lesson, you will be able to:
! Explain the purpose of routing groups.
! Explain the purpose of routing group connectors.
! Explain when more than one routing group is necessary.
! Describe how Exchange routes messages within and between routing
groups.
What Are Routing Groups?

Many companies need multiple servers running Exchange 2000 Server or
Exchange Server 2003 in their Exchange organization. When a user connected
to one server wants to send a message to a user on another server, Exchange
must transfer the message between servers. Transferring messages between
servers is called message routing.
Administrators assemble servers running Exchange into routing groups to more
efficiently route messages between servers:
! Routing groups are groups of servers running Exchange that are connected
over permanent network links.
! The routing group master is the server that is responsible for tracking and
maintaining routing, such as routing path availability, for all the servers in
the routing group.
In an Exchange organization that has one routing group, message routing can
occur on the same server or among different servers. In an Exchange
organization that has multiple routing groups, message routing occurs among
routing groups by using connectors.
What Are Routing Group Connectors?

Routing group connectors, called connectors, are components that are used to
link routing groups so that messages can reliably and efficiently travel between
groups. You can create one or more connectors and then configure and use
these connectors to control:
! Message connection schedules. Enables an administrator to create
connectors that route messages only at particular times. For example, in
environments where it is too expensive to maintain a constant connection
between routing groups (such as environments that use Integrated Services
Digital Network [ISDN] lines), an administrator could create a connector
that only routes messages several times a day.
! Message priority. Enables an administrator to create connectors that route
only messages of a particular priority level, such as high, medium, or low.
For example, an administrator could create a connector that only routes
high-priority messages.
! Message content. Enables an administrator to create connectors that route
only messages of a particular content type. For example, an administrator
could create a connector that routes all messages except system-related
messages.
! Message size limits. Enables an administrator to create connectors that route
only messages of a particular size. For example, in environments where a
reliable high-speed connection is billed on a per-packet basis, an
administrator could create one connector that routes only small messages,
using the reliable high-speed connection, and another connector that routes
only large messages, using a less costly, slower network connection.
! Message delivery restrictions. Enables an administrator to create connectors
that route only messages from a particular group of users. For example, an
administrator could create a connector that maintains an expensive
connection but routes only messages from users who do not send
unnecessary e-mail.
! Cost. Enables an administrator to assign a value between 1 and 100 that

indicates the relative cost of using the connector to send e-mail messages.
When multiple routes exist, Exchange will select a lower-cost route over a
higher-cost route when determining the preferred route for a message.
! Public folder referrals. Enables users of MAPI, Microsoft Outlook® Web
Access, and Internet Message Access Protocol (IMAP) clients to access a
public folder that is not in their routing group by redirecting the user to
another routing group to access the replica (additional copy of the public
folder). Public folder referrals are enabled by default. You can disable
public folder referrals on a single connector to prevent public folder
referrals over that connector to another routing group.
When Is More Than One Routing Group Necessary?

When to use just one You can use just one routing group if the servers that are running Exchange:
routing group
! Have permanent and reliable connections to each other.
! Belong to the same Microsoft Active Directory® directory service forest.
! Connect consistently and reliably to the routing group master.
When multiple routing Multiple routing groups may be required if any of the following apply:
groups may be required
! Network connections are slow or intermittent.
! The network is unreliable or unstable.
! Message transmission is complex and indirect, thereby requiring multiple
physical network hops.
! Message transmission must be scheduled between different locations.
! The routing group structure is created to prevent users from accessing public
folder replicas.
Multimedia: How Messages Are Routed Within and Between

Routing Groups

This animation shows how messages are routed within and between routing
groups.
Tip To view the presentation How Messages Are Routed Within and Between
Routing Groups later on your own, open the Web page on the Student Materials
compact disc, click Multimedia, and then click the title of the presentation.
Discussion question 1 Your company is creating support documentation for your Exchange
organization, and you have been asked to provide a description of the
components that are used to route messages between routing groups. What
description should you provide?
Message routing between routing groups occurs by using bridgehead
servers and routing group connectors. Bridgehead servers are Exchange
servers that host routing group connectors and transmit messages by using
those connectors to other routing groups. Routing group connectors are
components that are used to link routing groups.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Discussion question 2 You are an administrator in an Exchange organization that has six servers in
three routing groups:
! ServerA and ServerB are in the Birmingham routing group.
! ServerC and ServerD are in the Montgomery routing group.
! ServerE and ServerF are in the Mobile routing group.
The following routing group connectors are configured:

! Birmingham to Montgomery with a cost of 10.
! Montgomery to Mobile with a cost of 10.
The routing group bridgehead servers are ServerB, ServerD, and ServerF.
A user sends an e-mail message from ServerA to a recipient with a mailbox on
ServerE. Which servers will be used during the delivery of the message to the
final recipient? Explain your solution.
ServerA, ServerB, ServerD, ServerF, and ServerE will be used during the
delivery of the message. Because ServerA, the sender’s server, is not the
bridgehead server for the Birmingham routing group, ServerA will send
the message to ServerB, the local bridgehead server. ServerB will
determine the best route for the message and forward the message to the
bridgehead server, ServerD, in the Montgomery routing group. ServerD
will determine the best route for the message and forward the message to
the bridgehead server, ServerF, in the Mobile routing group. ServerF will
determine that the recipient’s server, ServerE, is part of the same routing
group and forward the message to ServerE.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
Lesson: Configuring Routing in an Exchange

Organization

Introduction This lesson explains how to configure and manage routing in an Exchange
organization. You will get to make decisions about which connectors to use,
create a routing group and a routing group connector, and then monitor routing
group connectors.
! Describe the connectors that Exchange supports.
! Decide when to use Routing Group connectors, when to use Simple Mail
Transfer Protocol (SMTP) connectors, and when to use X.400 connectors.
! Create a routing group.
! Create a routing group connector.
! Monitor routing group connectors by using the Monitoring and Status tool
in Exchange System Manger.
The Connectors That Exchange Supports

Exchange supports three connectors:
! The Routing Group connector. This connector is the simplest connector to
configure, which makes it the recommended tool for connecting routing
groups that are in the same Exchange organization. This connector uses
SMTP to transfer messages to other Exchange servers. Although the
Routing Group connector is unidirectional and must be configured in pairs
(inbound and outbound), Exchange System Manager simplifies the process
by automatically configuring the required second connector when the first is
set up.
Tip Routing Group connector is the name of a type of connector. Because

of its name, it is easy to confuse with the generic routing group connector,
or connector, which are terms that refer to any component used to link
routing groups to improve the reliability and efficiency of message travel
between groups.
! The SMTP connector. Establishes an SMTP messaging route between two

routing groups or between a routing group and an SMTP host. Although the
Routing Group connector and the SMTP connector use SMTP as the
transport protocol, the SMTP connector provides the following additional
capabilities:
• It connects an Exchange organization with an SMTP host that is not an
Exchange system.
• It connects independent Exchange organizations.
• It creates more finely tuned connections between Exchange routing
groups. For example, SMTP connectors can enable encryption and
authentication of remote domains. You can also configure an SMTP
connector to retrieve (or pull) e-mail from a remote SMTP server at
specified intervals.
! The X.400 connector. Establishes an X.400 messaging route between two

routing groups or between a routing group and an X.400 system. Like the
Routing Group connector and the SMTP connector, an X.400 connector can
be used to link Exchange routing groups. But unlike the Routing Group
connector and the SMTP connector, the X.400 connector provides the
following capabilities:
• Establishes an X.400 messaging route between a routing group and an
X.400 system.
• Provides an efficient method for sending large messages when the
connection between routing groups is very slow but reliable.
• Creates a network connection when the connection between routing
groups is X.25.
Considerations for Using Routing Group Connectors

Before you decide to use Routing Group connectors, consider the following
characteristics of Routing Group connectors. Routing Group connectors:
! Can be configured to use zero, one, or multiple local bridgehead servers.
Use the following list to determine the number of bridgehead servers you
should configure when using a Routing Group connector:
• No bridgehead server is used. Use this configuration when you want all
the servers in the routing group to act as local bridgehead servers.
• One bridgehead server is used. Use this configuration when you want all
e-mail to flow through one computer for the purpose of tracking or
archiving messages.
• Multiple bridgehead servers are used. Use this configuration when you
want to provide fault tolerance. When multiple bridgehead servers are
used and one bridgehead server becomes unavailable, Exchange sends
all messages over the available bridgehead server. Using multiple
bridgehead servers also enables you to choose which servers send and
receive messages between routing groups.
Note Local bridgehead servers are instances of SMTP virtual servers

hosted on Exchange servers within that routing group.
! Must be used in conjunction with TLS or a security policy to provide

security. Servers running Exchange provide authentication when performing
message routing, but they do not provide message encryption. If you require
message encryption, consider using one of the following options:
• Configure TLS. You can provide message encryption by configuring
Transport Layer Security (TLS) on the SMTP virtual server. A virtual
server is a server that allows you to host different protocols or protocol
settings on the same physical server. However, if you configure TLS on
one virtual server, you must configure all bridgehead servers to use TLS
for both inbound and outbound security, and you must install a security
certificate.
• Create a security policy. You can provide message encryption by
creating a security policy in Active Directory that requires that all IP
traffic be secured with Internet Protocol Security (IPSec).
! Must resolve the IP address of the target bridgehead server. When a local
bridgehead server that hosts the Routing Group connector receives a
message to transmit across the connector, it selects a target bridgehead
server at random and must resolve the target IP address by using the
following method:
a. The local bridgehead server attempts to resolve the target bridgehead
server address defined on the routing group connector by querying
Domain Name System (DNS) for mail exchanger (MX) records. DNS
stores an SMTP domain name and name of the host that manages e-mail
for that domain in an MX record.
b. If, as is usually the case, MX records do not exist for the target
bridgehead server, the local bridgehead server queries Active Directory
for the fully qualified domain name (FQDN) of the target bridgehead
server.
c. The local bridgehead server then queries DNS for the IP address of the
FQDN of the target bridgehead server.
d. If the DNS query for the FQDN of the target server is not found, the
local bridgehead server attempts to resolve the IP address by using the
standard host name resolution process.
Considerations for Using SMTP Connectors

Before you decide to use SMTP connectors, consider the following
characteristics of SMTP connectors. SMTP connectors:
! Can be used to identify multiple local bridgehead servers. The SMTP
connector delivers all messages between routing groups by using the local
bridgehead server. Unlike your configuration options for the Routing Group
connector, you cannot configure a bridgehead server in a remote routing
group.
! Can be configured to use outbound TLS. Security configured on the SMTP
connector overrides the security settings configured on the virtual server
that is used by the SMTP connector. This security override is useful when a
domain requires TLS for message transfers. When you configure an SMTP
connector that has been TLS-enabled with an address space specific to the
remote domain, Exchange transfers the messages intended for that domain
over the encrypted SMTP connector.
! Must resolve the target bridgehead server by using DNS MX or A records:
• When connecting routing groups, the SMTP connector resolves the IP
address of the target bridgehead server by using DNS MX records.
• You cannot select specific target bridgehead servers. Instead, the SMTP
connector first attempts to resolve the IP address of the destination
server.
• If an MX record does not exist, the sending server attempts to resolve
the destination server by using the host name resolution process, which
includes querying DNS for a Host (A) record.
! Must configure with address spaces that you can use to control which
messages travel over which SMTP connector. Each SMTP connector has at
least one address space and can have one or more connected routing groups
associated with it. When you use multiple connectors, you can use address
spaces to provide load balancing. For example, if you have two SMTP
connectors for transferring e-mail to the Internet, you can designate one
connector to process messages destined for the *.com address space and
another connector to process messages destined for the *.edu address space.
You can also use multiple local bridgehead servers to provide load
balancing and fault tolerance.
Considerations for Using the X.400 Connector

Before you decide to use X.400 connectors, consider the following
characteristics of X.400 connectors. X.400 connectors:
! Require you to configure a message transfer agent (MTA) service transport
stack for the connector. You must create an X.25 X.400 or Transmission
Control Protocol/Internet Protocol (TCP/IP) X.400 Service Transport Stack
for X.400 connectors before you create and configure the X.400 connector.
The Service Transport Stack defines the type of network that the X.400
connector will use to communicate with the remote host.
! Do not support multiple bridgehead servers. A single X.400 connector
cannot support multiple bridgehead servers at either end of the connection.
To provide load balancing and fault tolerance between two routing groups,
you must configure multiple X.400 connectors.
! Require address space to control message routes. You define address space
to control which messages travel across the X.400 connector. Configuring
the address space on X.400 connectors is the same as it is with SMTP
connectors.
Practice: Deciding on the Best Way to Connect Routing Groups

Read the following scenarios, determine solutions, and then discuss your
solutions with the class.
Scenario 1 You are the messaging administrator for an Exchange organization. Your
company has grown rapidly, but the network has not been upgraded to keep
pace with the company’s growth. E-mail message delivery has become
intermittent, and you have decided that creating multiple routing groups will
allow you to better control message delivery over the less-than-reliable links.
Your goal for choosing a connector is that it must have the ability to schedule
delivery and limit public folder access. You also want to be able to control
which users can use the connector, what messages will be routed across the
connector, and support multiple local bridgehead servers. Which connector
should you choose to connect your routing groups? Why?
The SMTP connector. Each of the routing group connectors allows for
scheduling delivery, limiting public folder access, and controlling which
users can send e-mail messages across the connector. But only the SMTP
and X.400 connectors allow you to control which messages are routed
across the connector. Because the X.400 connector does not support
multiple bridgehead servers, you should choose the SMTP connector. It
will give you the control that you need and it will be easier to configure.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Scenario 2 Given the previous scenario, you have determined that controlling the type of
message that is sent across the connector is not as important as you originally
thought and controlling what messages will be sent across the connector does
not need to be configured for all your routing group connectors. The standard
connector that you will use when new routing groups are created must have the
following capabilities:
! Scheduling delivery
! Limiting public folder access
! Controlling which users can send messages across the connector
You would also like to be able to create as few connectors as possible but
provide the most fault tolerance between routing groups.
Which connector should you choose to connect your routing groups? Why?
The Routing Group connector. This connector is the simplest connector to
configure to meet your requirements. It provides all the requirement
features and allows you to configure multiple local and remote bridgehead
servers on one connector.
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
How to Create a Routing Group

Exchange automatically creates a routing group called First Routing Group
when you install the first server that runs Exchange into an administrative
group. All subsequent servers that run Exchange are installed into this default
routing group until you create a new routing group. You can create a new
routing group by using Exchange System Manager and then installing new
servers or moving existing servers into this group.
To create a routing The high-level steps for creating a routing group by using Exchange System
group Manager are as follows:
1. In the Exchange System Manager console tree, browse to Routing Groups.
2. Right-click Routing Groups, click New, and then click Routing Group.
Detailed steps for creating a routing group by using Exchange System Manager
are included in the practice that follows.
Practice: Creating a In this practice, you will create a routing group and move one of your Exchange
routing group servers into the new routing group.
Important This practice is required to complete subsequent practices in this

module.
! To prepare for this practice

1. Start 2400_London-Virtual PC, if it is not already started.
2. Log on as NWTraders\LondonAdmin with a password of P@ssw0rd.
3. Run the script entitled “2400B_09_Setup.vbs” located in the
C:\MOC\2400\practices\Mod09 folder.
4. If it is not already open, open Outlook Web Access by using Microsoft

Internet Explorer to open the URL http://london/exchange/londonadmin.
When prompted for credentials, use nwtraders\londonadmin with a
password of P@ssw0rd.
5. Read the message with the subject “Managing routing” from your team
lead, Samantha Smith.
6. Start 2400_Miami-Virtual PC.
7. Log on as NWTraders\LondonAdmin with a password of P@ssw0rd.
Note This procedure may take five minutes to complete before you can
continue.
! To create a routing group

1. From 2400_London-Virtual PC, verify that messages can be sent between
London and Miami by sending a message to Miami User from London
Admin. Miami User is a user with a mailbox on the Miami server. Verify
that the message is delivered by viewing the number of items in Miami
User’s mailbox as displayed at Administrative Groups\First Administrative
Group\Servers\Miami\First Storage Group\Mailbox Store (MIAMI)\
Mailboxes.
2. In Exchange System Manager, browse to Administrative Groups\
First Administrative Group.
3. In the console tree, right-click First Administrative Group, point to New,
and then click Routing Groups Container.
4. In the console tree, expand Routing Groups, expand First Routing Group,
and then click Members. Verify that both London and Miami are members
of the First Routing Group.
5. In the console tree, right-click Routing Groups, point to New, and then
click Routing Group.
6. In the Properties dialog box, type Miami Routing Group and then click
OK.
7. In Exchange System Manager, in the console tree, expand Miami Routing
Group.
8. In the console tree, in the First Routing Group container, click Members,
and then in the details pane, click and drag Miami from the Members
container of the First Routing Group to the Members container of the
Miami Routing Group.
9. Click each Members container to verify that the London server remains a
member of First Routing Group and that the Miami server is a member of
the Miami Routing Group.
10. In the console tree, expand First Administrative Group\Servers\
London\Protocols\SMTP.
11. In the console tree, right-click Default SMTP Virtual Server and then
click Stop. After the virtual server is stopped, right-click Default SMTP
Virtual Server and then click Start.
12. In Outlook Web Access, verify that messages can no longer be sent between
London and Miami by sending a message to Miami User from London
Admin. Verify the message is not delivered by viewing the number of items
in Miami User’s mailbox as displayed at Administrative Groups\
First Administrative Group\Servers\Miami\First Storage Group\
Mailbox Store (MIAMI)\Mailboxes.
Why can messages not be delivered between London and Miami

anymore?
Because Exchange uses routing group connectors to route messages
between routing groups. Even though London and Miami are on
the same subnet and have permanent network connectivity to each
other, Exchange cannot route messages to servers in other routing
groups until a connector is created between the routing groups.
How to Create a Routing Group Connector

To create a routing The high-level steps for creating a routing group connector by using Exchange
group connector System Manager are as follows:
1. In the Exchange System Manager console tree, browse to Connectors.
2. Right-click Connectors, click New, and then click Routing Group
Connector.
3. In the Properties dialog box, specify the local and remote bridgehead
servers.
4. Configure any delivery options, delivery restrictions, or content restrictions
on the appropriate tab.
Detailed steps for creating a routing group connector are included in the
practice that follows.
Practice: Creating a In this practice, you will create a routing group connector to connect the two
routing group connector routing groups in your organization.
Important You must complete this practice to be able to complete subsequent

practices in this module. To complete this practice, a second routing group must
exist in your organization. If a second routing group does not exist, you must
create one by completing the practice titled Practice: Creating a Routing Group
earlier in this lesson.
To create a routing group connector:

1. From 2400_London-Virtual PC, in Exchange System Manager, browse to
Administrative Groups\First Administrative Group\Routing Groups and
click First Routing Group.
2. In the console tree, right-click Connectors, point to New, and then click
Routing Group Connector.
3. In the Properties dialog box, in the Name box, type London-Miami RGC
and then click the Remote Bridgehead tab.
4. On the Remote Bridgehead tab, click Add.
5. In the Add Bridgehead dialog box, click Miami, and then click OK.
6. In the London-Miami RGC Properties dialog box, click OK.
7. When prompted to create a routing group connector in the remote routing
group, click Yes.
8. Click the Connectors container for both the First Routing Group and Miami
Routing Group to verify that the connector exists for each direction.
9. Verify that messages can be sent between London and Miami by sending a
message to Miami User. Verify that the message is delivered by viewing the
number of items in Miami User’s mailbox as displayed at
Administrative Groups\First Administrative Group\Servers\Miami\
First Storage Group\Mailbox Store (MIAMI)\Mailboxes.
What is the purpose of the bridgehead server?

The bridgehead server transfers messages between routing groups.
Each routing group must have at least one bridgehead server.
How to Monitor Server, Connector, and Resource Status

What is the Monitoring The Monitoring and Status tool is an administrative tool built into Exchange
and Status tool? System Manager that you can use to monitor the status and performance of
servers, connectors, and resources. The Monitoring and Status tool has two
components:
! Notifications. Use this component to create e-mail or script notifications that
are triggered when the status of a server or connector changes.
! Status. Use this component to view the status of servers, connectors, and
resources.
Note For more information about notifications, see Module 2, “Configuring

and Managing Exchange Server 2003,” in Course 2400, Implementing and
Managing Microsoft Exchange Server 2003.
To use the Monitoring To monitor server, connector, and resource status:

and Status tool to
monitor server, 1. In the Exchange System Manger console tree, expand Tools, expand
connector, and resource Monitoring and Status, and then click Status.
status
2. In the details pane, view the status of servers, connectors, and resources.
The following status states apply to servers:

! Available indicates that the server is online and functioning normally.
! Unreachable indicates that one of the main services on the server is down.
Note If a server is unreachable and is in a different routing group, it may

indicate that a connector between routing groups is down or does not exist.
! In Maintenance Mode indicates that monitoring is temporarily disabled due

to maintenance, backup, repair, or some other reason.
! Unknown indicates that System Attendant cannot communicate with the
local server.
The following status states apply to connectors:

! Available indicates that the connector is functioning properly.
! Unavailable indicates that a communication service, such as the routing
service, is not functioning on this connector.
If you have configured monitors for specific resources such as SMTP queue or
X.400 queue growth, when the threshold for either a warning or a critical error
is exceeded, the state change will be displayed in the Status container. For
example, when an SMTP queue grows continuously and reaches a critical state,
the status container will display “Critical: SMTP queue growth” for the server
object that is experiencing the problem.
Practice: Using the In this practice, you will use the Monitoring and Status tool to monitor your
Monitoring and Status routing group connector status.
tool to monitor routing
group connector status
Important To complete this practice, a second routing group and at least one
routing group connector must exist in your organization. If a second routing
group does not exist, you must create one by completing the practice titled
Practice: Creating a Routing Group earlier in this lesson. If at least one routing
group connector does not exist, you must create one by completing the practice
titled Practice: Creating a Routing Group Connector earlier in this lesson.
To monitor routing group connector status:

1. From 2400_London-Virtual PC, in Exchange System Manager, expand
Tools, and then expand Monitoring and Status.
2. In the console tree, click Status, and then verify that LONDON and
London-Miami RGC have Status set to Available.
Lesson: Explaining Internet Connectivity Concepts and

Protocols

Introduction This lesson introduces Internet connectivity concepts and protocols. You must
understand these concepts to be able to effectively manage Internet connectivity
in an Exchange organization.
! Explain how an SMTP connection works.
! Describe common SMTP commands and reply codes.
! Explain how a SMTP Service Extensions (ESMTP) connection works.
! Describe common ESMTP commands.
! Explain the purpose of MX records.
! Describe how to configure DNS to support an Exchange organization.
! Create an MX record for the Exchange server.
How an SMTP Connection Works

When an Exchange host communicates with another host, it sends standard
SMTP commands over TCP port 25 to communicate with the host.
Communication between SMTP hosts occurs by using an asymmetric request-
response protocol, a protocol through which one host sends a command and
then waits for a reply from the other host before sending the next command.
The following steps outline the SMTP command and reply codes that are used
when a user, susanf@nwtraders.msft, on server1.nwtraders.msft, sends a
message to stefank@contoso.msft on smtp1.contoso.msft:
1. The sending host initiates a TCP connection to the receiving host. The
receiving host must return a 220 (Ready) response, indicating that it has
opened a connection.
2. The sending host requests that an SMTP session be initiated by sending a
HELO command. The receiving host returns a 250 response, indicating that
the requested action is okay.
3. The sending host identifies the sender of the message by using the MAIL
FROM command. The receiving host returns a 250 response.
4. The sending host identifies the recipient of the message by using the RCPT
TO command. The receiving host returns a 250 response.
5. The sending host indicates that is it ready to send the message by using the
DATA command. The receiving host returns a 354 response indicating the
start of the message input.
6. The sending host sends the message and indicates the end of the session by
using the QUIT command. The receiving host returns a 221 response
indicating the service is closing the connection.
Note For more information about SMTP, see Requests for Comments (RFC)
2821 and 2822. RFCs can be found at http://www.rfc-editor.org/rfc.html.
Common SMTP Commands and Reply Codes

Common SMTP SMTP uses a series of plain-text commands that are passed from a sending host
commands to a receiving host. The following table lists and describes some common
SMTP commands.
SMTP command Description
HELO fqdn Identifies the sending SMTP host.

MAIL FROM:<sender> Identifies the sender of the message.
RCPT TO:<recipient> Identifies the recipient of the message. This
command is used for each message recipient.
DATA Indicates that the sending host is ready to send the
message.
RSET Cancels the current mail transaction.
VRFY <string> Allows the sending host to verify that the recipient is
valid before sending the message.
HELP Lists the SMTP commands supported on the
receiving host.
QUIT Disconnects the TCP session.
TURN Triggers the recipient server to send queued messages
destined for the sending server. This command is
used in dial-up environments to poll a host for
queued messages.
Common SMTP reply When the sending host issues SMTP commands to the receiving host, the
codes receiving host responds to these commands with one of several reply codes.
The following table lists and describes some common reply codes.
SMTP reply code Description
220 fqdn Service is ready.

221 fqdn Service is closing transmission channel.
250 Requested action is okay, and has been completed.
354 Start message input; end with <CRLF>.<CRLF>.
450 Requested action not taken: mailbox busy.
451 Requested action aborted: local error in processing.
452 Requested action not taken: insufficient system storage.
500 Syntax error, command unrecognized.
550 Requested action not taken: mailbox unavailable or not found.
552 Requested action aborted: exceeded storage allocation.
554 Transaction failed.
How an ESMTP Connection Works

What is ESMTP? ESMTP is a protocol that extends SMTP functionality by providing additional
capabilities, such as delivery notification. ESMTP also supports several
advanced messaging commands, such as host authentication and encryption.
ESMTP enables a receiving host to inform a sending host of the extensions it
supports. ESMTP does not require modification to the sending host or receiving
host configurations. Some SMTP hosts, such as Microsoft Windows® 2000 and
Microsoft Windows Server™ 2003, support ESMTP.
How an ESMTP The following steps outline a successful ESTMP connection:
connection works
1. The sending host initiates a TCP connection to the receiving host. The
receiving host must return a 220 (Ready) response, indicating that it has
opened a connection.
2. The sending host requests that an SMTP session be initiated by sending an
EHLO command instead of a HELO command. Then, one of two things
happens:
• If the receiving host supports ESMTP, the receiving host returns an OK
by sending a code 250 response, which indicates that it has accepted the
session and that the sending host can continue. The receiving host then
sends the list of SMTP extensions that it supports.
- or -
• If the receiving host does not support ESMTP, it returns a code 500
(Error) response. In such a case, the sending host issues a HELO
command to initiate a normal SMTP connection sequence.
Note For more information about ESMTP, see RFC 1869. RFCs can be found
at http://www.rfc-editor/rfc.html.
Common ESMTP Commands

The following table lists and describes some common ESTMP commands.
ESMTP command Description
ATRN Authenticated TURN runs only if the session has been

authenticated. This command is described in RFC 2645.
ETRN Similar to TURN, but it specifies the remote host to which
the mail is to be delivered. This command is described in
RFC 1985.
PIPELINING Allows SMTP commands to be sent in batches without
waiting for a response from the receiving host. This makes
the protocol more efficient.
CHUNKING Enables the sending of large Multipurpose Internet Mail
Extensions (MIME) messages more efficient by chunking the
data together as it is transported between SMTP hosts.
X-EXPS GSSAPI Uses an authentication mechanism that supports Kerberos and
NTLM LOGIN NTLM. This command supports the same authentication
mechanisms as AUTH.
X-EXPS=LOGIN Uses an Exchange Server 5.5–specific authentication
mechanism that supports NTLM for compatibility with
Exchange Server 5.5.
X-LINK2STATE Specifies support for the Exchange 2000 links state command
verb.
XEXCH50 Used when establishing a connection with another server
running Exchange. The XEXCH50 command is used for
transferring Exchange-specific content in messages.
STARTTLS Provides a Secure Sockets Layer (SSL) connection between
the SMTP client and server. The client system must initiate
the TLS connection.
(continued)
ESMTP command Description
AUTH SASL Provides a form of Simple Authentication and Security Layer

mechanism (SASL) SMTP authentication that uses Kerberos and NTLM
protocols to authenticate SMTP hosts.
AUTH=LOGIN Provides a form of SASL for clients such as Netscape and
Exchange Server 5.5 that require this basic SMTP
authentication.
HELP Outputs a list of commands supported by the SMTP host.
This command is described in RFC 2821.
VRFY Determines whether an e-mail account exists and if it is
disabled by default. Many administrators consider it a
security risk if this command is enabled. This command is
described in RFC 2821.
DSN Generates and sends a delivery status notification to the
sending host in case of delivery failure. This command is
considered an improvement over the current non-delivery
report (NDR) mechanism. This command is described in
RFC 1891.
SIZE Determines the size of a message prior to its acceptance.
Previously, a message had to be transmitted to the receiving
system in whole or part before it could be rejected for
exceeding a size limitation. This command is described in
RFC 1870.
Practice: Explaining Internet Connectivity Concepts and Protocols

Read the following scenarios, determine solutions, and then discuss your
solutions with the class.
Scenario 1 You want to test connectivity between your Exchange server and a remote
SMTP host. You establish a connection over port 25. After the connection is
established, what must you do to identify your Exchange server to the remote
host?
You need to issue the HELO command with the FQDN of your server.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Scenario 2 You want to test connectivity between your Exchange server and a remote
SMTP host. You also want to be sure that when your two hosts exchange
information, they can use encryption. After the connection is established, what
must you do to identify your Exchange server to the remote host to support this
requirement?
You must issue the EHLO command with the FQDN of your server. If the
remote host responds with a 250 reply, the host supports ESMTP
commands, which will allow you to configure an encrypted session between
the hosts.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
What Are MX Records?

A mail exchanger (MX) record is a DNS record that tells other computers your
e-mail server IP address and name so that you can receive SMTP e-mail.
Transferring messages between SMTP hosts is dependent on DNS. When an
SMTP host sends an e-mail message to another SMTP host, DNS resolves the
domain name of the receiving host to its TCP/IP address by using MX records.
How MX records provide A typical company has multiple MX records registered in DNS to provide fault
fault tolerance tolerance if an SMTP host becomes unavailable. If the SMTP host becomes
unavailable:
1. The sending SMTP host retrieves all MX records for the receiving domain
from DNS, and then resolves the lowest-preference SMTP host name to an
IP address. If the SMTP host with the lowest preference is not available, the
SMTP host with the second-lowest preference is used.
2. After the SMTP host’s IP address is resolved, an SMTP session is
established with the receiving SMTP host.
Examples: MX record You can configure Exchange for a variety of different SMTP environments.
configurations Exchange recipients can have a single SMTP address or multiple SMTP
addresses. Exchange can segregate recipients into virtual organizations, each
with its own SMTP address space. How you configure DNS to support your
Exchange organization will depend on how many address spaces are used, how
your Exchange organization is connected to the Internet, and who is responsible
for managing your DNS entries.
The following examples show how MX records in DNS would be configured
for your company based on whether you manage your own DNS or you have
your Internet service provider (ISP) manage DNS for you.
Note There should be A (Address) records in DNS for each SMTP host listed
in the following examples.
Example 1
The following table shows an example of MX records in DNS when you are
managing your own DNS and have a single DNS namespace.
Record Preference SMTP host
MX 10 Smtp1.nwtraders.msft
Example 2
The following two tables provide an example of MX records in DNS when you
are managing your own DNS and you have two DNS namespaces: contoso.msft
and nwtraders.msft.
The following records are added to the contoso.msft DNS namespace in your
DNS server.
The following records are added to the nwtraders.msft DNS namespace in your
DNS server.
By adding the MX records for the nwtraders.msft e-mail servers to the

contoso.msft domain, you are telling the sender that e-mail sent to contoso.msft
will be handled by the nwtraders.msft e-mail server, smtp1.nwtraders.msft or
smtp2.nwtraders.msft.
Example 3
The following table shows an example of MX records in DNS when your ISP is
managing your DNS and you have a dial-up connection. In this situation, the
ISP must create an MX record that points to the ISP’s smart host. For your
domain, nwtraders.msft, this record uses the following format.
MX 10 Smarthost1.ispdomain.com
Example 4
The following table shows an example of MX records in DNS when your ISP is
managing your DNS records and you have a permanent connection. If your
connection is down, your messages are delivered to the ISP’s smart hosts, and
you can pick up your messages from the smart host. To configure your MX
records, the ISP adds the records in the following table.
How to Configure DNS to Support an Exchange Organization

To configure DNS to The high-level steps for configuring DNS to support an Exchange organization
support an Exchange are as follows:
organization
1. Configure Exchange to meet your SMTP requirements.
2. Provide DNS with the MX records necessary to support your SMTP address
space. For example, when you configure Exchange recipients with two
SMTP addresses, user@nwtraders.msft and user@contoso.msft.
3. Add MX records to each DNS namespace that point to your Exchange
SMTP hosts. After you add the MX records, an Internet e-mail user can
send a message to a single recipient at user@nwtraders.msft or
user@contoso.msft and the message will reach the intended recipient.
Detailed steps for creating an MX record for the Exchange server are included
in the following practice.
Practice: Creating an MX In this practice, you will create an MX record for your Exchange server in
record for the Exchange DNS. To create an MX record:
server
1. From 2400_London-Virtual PC, on the desktop, click Start, point to
Administrative Tools, and then click DNS.
2. In dnsmgmt-[DNS], in the console tree, expand LONDON, expand
Forward Lookup Zones, and then expand nwtraders.msft.
3. In the console tree, right-click nwtraders.msft, and then click New Mail
Exchanger (MX).
4. In the New Resource Record dialog box, in the Fully qualified domain
name (FQDN) of mail server box, type London.nwtraders.msft and then
click OK.
5. Verify that a new record of type Mail Exchanger (MX) exists for
London.nwtraders.msft.
6. To verify that the record is resolvable, on the desktop, click Start, click
Run, type cmd and then click OK.
7. At the command prompt, type nslookup –querytype=mx nwtraders.msft

and then press ENTER. Information about the primary name server
London.nwtraders.msft DNS settings should be returned.
8. Close the command prompt window and close DNSMgmt.
In previous practices, you did not have an MX record defined; however,

Acapulco, London, and Miami have all been able to handle e-mail. In
what scenario do you need an MX record?
For external e-mail clients to send messages to internal users across
the Internet, they must be able to locate the server that handles
SMTP messages for your SMTP domain. To do this, clients query
DNS for an MX record for your domain, which is then used to
locate the A record for the server that they will connect to. Without
an MX record, clients cannot determine which server to use to send
e-mail into your Exchange organization.
Lesson: Managing Connectivity to the Internet

Introduction This lesson explains the tasks involved in managing connectivity to the Internet
and then asks you to perform the tasks.
! Describe the steps that you can take to control Internet e-mail access.
! Create and configure an SMTP connector.
! Describe methods for securing SMTP traffic.
! Restrict user accounts from sending Internet e-mail.
! Configure SMTP relays in Exchange.
! Explain when to use and when to restrict open relaying in Exchange.
! Describe how to prevent and restrict open relaying in Exchange.
! Describe how to connect Exchange servers to the Internet by using Routing
and Remote Access.
! Configure Exchange to retrieve e-mail from an ISP.
! Describe how to identify problematic e-mail domains.
Steps You Can Take to Control Internet E-Mail Access

You do not have to configure an SMTP connector for e-mail to function, nor to
connect an Exchange server to other servers in an organization, nor to connect
an Exchange server to the Internet. The default SMTP virtual server manages
all these connections. You can choose, however, to control how the Exchange
server connects to the Internet if you want to change how messages flow in and
out of your Exchange organization. You can:
! Create an additional virtual server and configure an SMTP connector to use
it as a bridgehead server. You can do this domain by domain to control
filters, relay restrictions, message formats, outbound security, and smart
host options. Although you can use the default virtual server to configure
these items, if you want to control these items domain by domain, you
should create an additional virtual server and then configure an SMTP
connector to use the virtual server as a bridgehead server. When you
configure the virtual server this way, the SMTP connector overrides any
settings that the SMTP virtual server and SMTP connector share. For
example, you can create an SMTP connector with an address space for a
specific e-mail domain, such as *.contoso.com, and configure that connector
to use a virtual server that does not have any filters configured for sending
messages to one of your associate companies.
! Limit the scope of the SMTP connector to the routing group. For example, if
you do not want messages from other routing groups to be delivered by the
SMTP connector, select Routing group as the connector scope. However, if
you want the SMTP connector to act as a backup to other similarly
configured SMTP connectors in other routing groups, leave the scope as the
Entire organization.
! Configure the credentials on an SMTP connector if the connector is
configured to deliver messages to a domain and the SMTP server in that
domain requires authentication. This configuration does not affect the
virtual server, which can be configured with no outbound security, so that
clients can connect to other domains anonymously.
! Configure the SMTP connector only to receive e-mail or send e-mail. For
example, if your Exchange server cannot successfully perform DNS lookups
for Internet addresses, and you want to designate the server as your gateway
to the Internet, you may need to configure an SMTP connector and then
designate a bridgehead server for the connector to use, along with
configuring the connector scope, message routing, and address space.
! Configure Internet message formats and message delivery parameters.
Internet message formats enable you to configure the encoding, format, and
type of messages (such as out-of-office or NDRs) that you send to a specific
domain. The domain can then reference a specific destination, such as
nwtraders.msft, or it can use a wildcard, such as *.edu, to reference a large
group of destinations. You can define the message format for all SMTP
domains or for specific domains.
Tip You can also use the Internet Mail Wizard to help you create the SMTP
connector. Internet Mail Wizard helps you to configure Exchange server to send
and receive Internet mail. This wizard is intended primarily for small to
medium-sized companies with less complex environments than large enterprise
companies. Internet Mail Wizard creates the SMTP connector for outgoing
Internet e-mail and then configures the SMTP virtual server to accept incoming
e-mail. If you have already set up SMTP connectors or created additional
SMTP virtual servers on your Exchange server, you cannot run the wizard
unless you reset your server configuration to its default state.
How to Create and Configure an SMTP Connector

To create and configure The high-level steps for creating a new SMTP connector are as follows:
an SMTP connector
1. In the Exchange System Manager console tree, browse to the Connectors
container.
2. In the console tree, right-click Connectors, point to New, and then click
SMTP Connector.
3. Provide a name for the connector, define the local bridgehead server, and
configure the address space for the connector.
Detailed steps for creating and configuring an SMTP connector are included in
the practice that follows.
Practice: Creating and In this practice, you will create and configure an SMTP connector. You must
configuring an SMTP complete this practice to complete subsequent practices in this module.
connector
Administrative Groups\First Administrative Group\Routing Groups\
First Routing Group\Connectors.
2. In the console tree, in First Routing Group, right-click Connectors, point to
New, and then click SMTP Connector.
3. In the Properties dialog box, in the Local bridgeheads area, click Add.
4. In the Add Bridgehead dialog box, click Default SMTP Virtual Server,
and then click OK.
5. In the Properties dialog box, in the Name box, type General SMTP
Connector and then click the Address Space tab.
6. On the Address Space tab, click Add.
7. In the Add Address Space dialog box, click SMTP, and then click OK.
8. In the Internet Address Space Properties dialog box, verify that E-mail
domain is set to * to indicate that all outbound SMTP e-mail uses this
connector, and then click OK.
9. In the General SMTP Connector Properties dialog box, click OK.

10. Verify that the General SMTP Connector object exists in the First Routing
Group\Connectors container.
The connector that you created in this practice will transfer all messages
sent to Internet clients. What would you configure differently to allow
the connector to only handle messages sent to contoso.msft?
When configuring the address space, instead of entering *, you
would enter contoso.msft. Only messages addressed to users at
contoso.msft will be eligible for delivery by using this connector.
Methods for Securing SMTP Traffic

You can secure SMTP traffic by using authentication, encryption, and reverse
DNS lookup.
Authentication Authentication is the process of ensuring that users are who they claim to be.
Exchange supports three authentication methods. The method that you choose
for SMTP depends on your environment:
! Anonymous authentication. This method provides limited access to specific
public folders and directory information. This method is supported by all
clients and is an easy way to allow users to access unsecured content in
public folders.
! Basic authentication. Basic authentication is supported by most client
computers. This method provides the simplest level of security. Because a
user’s name and password are sent as clear text (not encrypted), this method
is not very secure.
! Integrated Windows Authentication. This method offers the best security,
efficient communication, and transparency. When you use Integrated
Windows Authentication, the password is sent as an encrypted value.
Encryption Encryption is a technique through which the contents of an e-mail message are
scrambled into a code that can only be read by a person who has the key to
decode it on his or her computer. Because authentication does not encrypt
message data, to make your data truly secure, you must use TLS to encrypt
e-mail messages transferred between the client and the server. Because TLS
encrypts the entire TCP/IP session between the client and the server, the session
is secure even if you chose a logon authentication method that does not encrypt
the user name and password. To use TLS, the server must have an X.509 SSL
certificate issued by a trusted certification authority (CA).
Note For more information about TLS, see RFC 2487. RFCs can be found at
http://www.rfc-editor.org/rfc.html.
Reverse DNS lookup A common problem associated with Internet e-mail is IP spoofing. IP spoofing
is an attack on a network in which an attacker impersonates a trusted host by
using its IP address in an attempt to gain unauthorized access to a computer
network. To prevent IP spoofing, you can enable reverse DNS lookup. Reverse
DNS lookup is a technique through which you set up your computers to use the
sender’s SMTP domain name to carry out a DNS lookup to confirm that the IP
address of the sending host is from the same network that is registered in DNS.
The result of the reverse lookup is written into the SMTP header of the message
indicating whether the lookup matched.
Caution Reverse DNS lookup can severely impact the performance of

transferring messages and prohibit the relaying of messages through multiple
hops.
How to Restrict User Accounts from Sending Internet E-Mail

Why restrict users from Some companies may have a large number of employees but allow only a few
sending Internet e-mail? employees to send and receive Internet e-mail. This restriction may be due to a
stringent corporate security policy that, for example, restricts Internet e-mail
access only to full-time employees. The company may employ only a limited
number of full-time employees and use temporary staff for day-to-day
operations, so it does not want to extend Internet e-mail capabilities to the
temporary staff. The administrator can configure the SMTP connector so that
only specific users or groups can send e-mail outside of the company.
To restrict user Administrators can control how messages are sent from a specific recipient to
accounts from sending specific connectors. You can use the options on the Delivery Restrictions tab
Internet e-mail of the properties of a connector to accept or reject e-mail messages from any
sender listed in the directory. For example, if the address of a sender is in the
Reject messages from list, any messages from that sender are returned to the
sender.
Note Delivery restrictions are optional. The default is to accept all messages
from all senders.
The high-level steps for restricting user accounts from sending Internet e-mail
are as follows:
1. In the Exchange System Manager console tree, browse to Connectors.
2. Right-click the connector that you want to restrict, and then click
Properties.
3. On the Delivery Restrictions tab, specify the name of the sender or senders
in the Accept messages from or Reject messages from area.
Detailed steps for restricting user accounts from sending Internet e-mail are
included in the practice that follows.
Practice: Restricting In this practice, you will configure users so that they are not able to send
user accounts from Internet e-mail.
sending Internet e-mail
Important To complete this practice, an SMTP connector must exist in your
organization. If an SMTP connector does not exist, you must create one by
completing the practice titled “Creating and configuring an SMTP connector”
earlier in this module.
To restrict user accounts from sending Internet e-mail:

1. In Exchange System Manager, browse to Administrative Groups\
First Administrative Group\Routing Groups\First Routing Group\
Connectors.
2. In the details pane, right-click General SMTP Connector, and then click
Properties.
3. In the General SMTP Connector Properties dialog box, click Delivery
Restrictions.
4. On the Delivery Restrictions tab, in the Reject messages from area, click
Add.
5. In the Select Recipient dialog box, type GregoryAlder; MichaelAlexa;
MichelleAlexa; SeanAlexa; MichaelAllen; NancyAnder; PamelaAnsma;
KarenArche, and then click OK.
6. In the General SMTP Connector Properties dialog box, click OK.
You have two SMTP connectors in your environment. You have just
denied Gregory Alderson (GregoryAlder) permission to send messages
across the default SMTP connector. What will occur when Gregory
attempts to send a message to an SMTP recipient?
If Gregory has permission to use the remaining SMTP connector,
the message will be delivered. If he does not have permission on
either SMTP connector, the message will be returned to Gregory as
undeliverable.
How to Configure SMTP Relays in Exchange

What is SMTP relaying? When one SMTP host forwards SMTP e-mail to another SMTP host without
resolving the recipient addresses, the process is called relaying. You can deploy
an SMTP connector to relay e-mail message between Exchange and other
SMTP-compatible messaging systems such as UNIX Sendmail or other SMTP
hosts on the Internet. The bridgehead server or servers that are defined on the
SMTP connectors will relay e-mail messages directly to a smart host or to a
remote server on which recipient addresses are stored.
Note Sendmail is an SMTP-compatible messaging system available in

commercial and freeware. For information about Sendmail, see
http://www.sendmail.org.
How to configure SMTP There are six different ways to configure SMTP relays in Exchange. The
relays in Exchange following list describes these configurations and the logic behind them. You
can:
! Configure an SMTP virtual server to use a smart host. By default, an SMTP
virtual server uses DNS to resolve the recipient’s SMTP address to deliver
messages. You can also configure the virtual servers in your organization to
forward all outbound e-mail to a smart host. When a virtual server is
configured to use a smart host, the virtual server does not try to resolve the
SMTP domain name with DNS; rather, it sends the message to the smart
host for delivery. Common reasons for using a smart host include:
• Provides an entry and exit point for all Internet messages or messages to
a foreign messaging system. This allows you to manage Internet
message traffic.
• Provides dial-up solutions. Clients can periodically dial up to send and
receive messages from the permanently connected SMTP smart host.
This dial-up solution reduces connection time, because the clients need
not be constantly connected to the Exchange server.
Note The smart host setting for SMTP virtual servers is similar to the smart
host setting on SMTP connectors. It is recommended that you configure
smart hosts on the connector, because connectors can handle message
delivery on a per-domain basis.
You can identify the smart host by FQDN or by an IP address (however, if

you change the IP address, you also have to change the IP address on every
virtual server). If you use an IP address, you must enclose it in square
brackets ([ ]). Exchange checks first for a server name, and then it checks
for an IP address. The brackets identify the value as an IP address; therefore,
the DNS lookup is bypassed. You configure the virtual server to use a smart
host by entering the smart host in the Smart host box in the Advanced
Delivery dialog box of the virtual server.
! Configure the SMTP virtual server to forward unresolved messages to a
smart host. Some organizations may have other SMTP messaging systems
in addition to Exchange. It is possible to forward all unresolved SMTP
messages from Exchange to a smart host. If the smart host cannot resolve
the recipient’s name, the message is returned with an NDR. You configure
the SMTP virtual server to forward unresolved messages to a smart host by
entering the smart host in the Forward all mail with unresolved recipients
to host box on the Messages tab of the virtual server.
! Configure an SMTP connector to use a smart host. By default, an SMTP
connector uses DNS to resolve the recipient’s SMTP address to deliver
messages. You can also configure the connector to forward all outbound
mail to a smart host. You configure the SMTP connector to use a smart host
by entering the smart host in the Forward all mail through this connector
to the following smart hosts box on the General tab of the Properties
dialog box of the SMTP connector.
! Configure an SMTP virtual server as a relay host. Configuring an SMTP
virtual server as an inbound relay host gives Exchange smart host
capabilities. You can configure other SMTP servers to use the Exchange
virtual server as their smart host, forwarding all outbound messages to the
virtual server. The virtual server then resolves the recipient’s SMTP domain
name by using DNS and delivers the messages. You configure the virtual
server as a relay host by configuring Relay restrictions on the Access tab of
the virtual server.
! Configure the SMTP virtual server to limit which servers can relay e-mail
messages. To avoid unwanted SMTP hosts using your SMTP host as a relay
agent for bulk unsolicited commercial e-mail (or junk e-mail), you should
limit who or what can relay e-mail messages through your organization.
You can specify which computers, groups of computers, or domains should
be allowed to relay e-mail messages by configuring the SMTP virtual
server. You configure the SMTP virtual server to limit which servers can
relay e-mail messages through your organization by configuring Relay
restrictions on the Access tab of the virtual server.
! Configure domains that you want to relay messages to. You may not want
to limit the domains from which you relay messages, but you may want to
limit the domains to which you relay messages. This restriction may be
useful when your organization has multiple SMTP messaging systems that
operate under different SMTP domain names. You may want your SMTP
host to accept messages from any domain, but then only forward those
messages to specific domains—for example, to the other domains in your
organization. Domains to which you want to relay messages can be
configured on the Address Space tab of an SMTP connector.
Practice: Configuring In this practice, you will configure your SMTP connector to use a relay host for
Exchange to use an outbound SMTP messages.
SMTP relay host
completing the practice titled “Creating and configuring an SMTP connector”
earlier in this module.
To configure Exchange to use an SMTP relay host:

First Routing Group\Connectors, and then expand Connectors.
2. In the console tree, right-click General SMTP Connector, and then click
Properties.
3. In the General SMTP Connector Properties dialog box, on the General
tab, click Forward all mail through this connector to the following
smart hosts, type SMARTHOST and then click OK.
4. To verify that the SMARTHOST configuration is set properly, from
Outlook Web Access, send a test message to
samsmith@nwtraders99999.msft, and then check the Queues object
located in Exchange System Manager at Administrative Groups\First
Administrative Group\Servers\London\Queues. Verify the existence of the
General SMTP Connector – SMARTHOST (SMTP Connector) object.
The presence of the word SMARTHOST indicates that the connector is
configured correctly. The connector is not truly functional because no
SMARTHOST computer and no network connectivity exists to outside
computers in this virtual environment.
When to Use and Restrict Open Relaying in Exchange

Why restrict or prevent Open relaying can cause your Exchange server to be used in ways you do not
open relaying? intend for it to be used. Exchange servers connected to the Internet are
vulnerable to an attack called mail relaying. Mail relaying is a practice in which
an unauthorized user sends e-mail messages from the e-mail server of another
system to use the resources of that server or to make it appear that the messages
originated from the other system. This practice is often used to send unsolicited
commercial e-mail, commonly referred to as junk mail or spam. When an
unauthorized user uses your Exchange server to send out unsolicited
commercial e-mail, this is what happens:
1. The unauthorized user sends a single e-mail message to your SMTP server
and addresses multiple recipients in the message. The recipients defined in
the message have e-mail addresses that are in domains external to your
Exchange organization.
2. Because the default setting for SMTP servers is set to use anonymous
authentication, the system that propagates the unsolicited commercial e-mail
messages accepts the inbound message as typical.
3. After the message is accepted, the SMTP server recognizes that the message
recipients belong to external domains, so it delivers the messages.
The unauthorized user needs to send only one junk e-mail message to your
SMTP server, but the message can then be delivered to thousands of recipients.
This distribution slows down your Exchange server, congests queues, and
upsets people who receive the junk e-mail message. This may also cause other
legitimate servers to block e-mail from your Exchange server.
When to use and restrict Because mail relaying attacks are a common occurrence, you should consider
open relaying in preventing or restricting open relaying on any Exchange server connected to the
Exchange Internet. There are times, however, when relaying is required. For example, you
may have Post Office Protocol version 3 (POP3) and Internet Message Access
Protocol version 4, revision 1 (IMAP4) clients who rely on SMTP for message
delivery and who have legitimate reasons for sending e-mail messages to
external domains. You can work around this issue by creating a second SMTP
virtual server that is dedicated to receiving e-mail messages from POP3 and
IMAP4 clients. This additional SMTP virtual server can use authentication
combined with SSL-based encryption and can be configured to allow relaying
for authenticated clients.
Note For additional information about how to encrypt SMTP message delivery
for POP3 and IMAP4 clients, search for articles 319267, “HOW TO: Secure
Simple Message Transfer Protocol Client Message Delivery in
Exchange 2000,” and 821603, “HOW TO: Configure Security Settings for
Internet Message Access Protocol Client Access in Exchange Server 2003,” on
the TechNet page of the Microsoft Web site at http://support.microsoft.com/.
How to Prevent or Restrict Open Relaying in Exchange

The primary method for restricting relaying in Exchange is by not granting
relay permissions to any other hosts. Relaying can also be restricted to a limited
number of users or groups though the standard Windows discretionary access
control list (DACL). By using DACLs, you can specify the groups of users who
can relay e-mail messages through an SMTP virtual server. This is useful if you
have a select group of users whom you want to allow to relay e-mail messages
to the Internet but another set of users whom you do not want to permit to do
so. You can still grant relaying to an IP address, domain, and subnet in
Exchange.
To prevent open To prevent Exchange from being used for open relaying by all hosts, including
relaying authenticated hosts:
1. In the Exchange System Manager console tree, browse to Servers, and then
expand the Exchange Server computer that you want to configure.
2. Expand Protocols, and then expand SMTP.
3. Right-click the SMTP virtual server that you want to configure, and then
click Properties.
4. To display the options for restricting relay, on the Access tab, click Relay.
5. In the Relay Restrictions dialog box, ensure that the selection for those
computers that may relay e-mail messages is set to Only the list below and
make sure that the list is blank. This is the default setting.
6. Unless you are using POP3 and IMAP4 clients with this virtual server, clear
the Allow all computers which successfully authenticate to relay,
regardless of the list above check box, and then click OK.
Note If you configure All except the list below and anonymous access is
allowed as an authentication method, any computer on the Internet that is not on
the list can relay e-mail messages though the virtual server. This condition is
called anonymous relay and can result in unauthorized users relaying junk
e-mail or other unwanted messages through your server. Additionally, operating
an anonymous relay may be in violation of your ISPs terms of service.
To restrict relaying based on a security group:

To restrict relaying
based on a security 1. In the Relay Restrictions dialog box, clear the Allow all computers which
group successfully authenticate to relay, regardless of the list above check box,
and then specify a subset of users to whom you want to grant relay
permission on the SMTP virtual server.
2. Click Users.
3. To remove a group, select the group, and click Remove.
4. To add a group or user, click Add, and then select the group or users for
which you want to specify permissions on the SMTP virtual server.
5. In the Select Users, Computers or Groups box, in the Enter the object
names to select box, type the name of the user or the group or click
Advanced to search for the user or group.
6. Click OK to return to Permissions for Submit and Relay.
7. In the Group or users names list, select the group.
8. Under Permissions for <selected group>, next to Submit Permission,
click Allow to allow the selected user or group to submit e-mail through the
SMTP virtual server or click Deny to prevent this group from submitting
e-mail through the SMTP virtual server.
9. Next to Relay Permission, click Allow to permit the selected object to relay
through this SMTP virtual server or click Deny to prevent the selected
object from relaying through this connector. Then, click OK.
Note You must allow Submit Permissions if you want to allow Relay
Permissions.
To override relay You can also configure an SMTP connector to override the relay settings of
restrictions for specific your SMTP virtual server. You may decide to configure the SMTP connector
domains this way if there is a specific domain that you want to allow e-mail to be relayed
to, such as an affiliate company, while restricting all other relaying.
To configure relaying for a specific domain, you create an address space for the
domain and select the Allow messages to be relayed to these domains check
box on the Address Space tab of the SMTP connector.
Practice: Configuring In this practice, you will configure Exchange to allow SMTP relaying for both
the SMTP connector to authenticated and unauthenticated users.
override relay settings
on the SMTP virtual
server Important To complete this practice, an SMTP connector must exist in your
completing the practice titled Practice: Creating and Configuring an SMTP
Connector earlier in this lesson.
To configure the SMTP connector to override relay settings on the SMTP

virtual server:
First Routing Group\Connectors, and then expand Connectors.
Properties.
3. In the General SMTP Connector Properties dialog box, click Address
Space.
4. On the Address Space tab, select the Allow messages to be relayed to
these domains check box and then click OK. Click OK when warned that
this overrides the default restrictions for relaying on the SMTP virtual
server.
You just configured your SMTP connector to allow messages to be

relayed to all domains. What does this mean? Should you configure
your SMTP connector to relay in your production environment?
All users, whether they are internally authenticated users or not,
can now relay messages to SMTP users over the Internet by using
your server. This is not something that you should allow in your
production environment, because it makes you vulnerable to
denial-of-service attacks and unwanted use by commercial interests
distributing unsolicited commercial e-mail.
How to Connect Exchange Servers to the Internet by Using Routing

and Remote Access

To connect Exchange servers to the Internet by using Routing and Remote
Access, you must configure the on-demand dial-up connection in Routing and
Remote Access, and then configure the smart host for the Exchange SMTP
virtual server or SMTP connector.
Note If you use Exchange to receive e-mail messages from the Internet by
using SMTP, you will lose most of your e-mail messages because of the
intermittent dial-up connection.
To connect to the To connect to the Internet by using Routing and Remote Access:
Internet by using
Routing and Remote 1. After a modem is added to the computer, ensure that it is displayed as a port
Access in Routing and Remote Access under Ports. On the desktop, click Start,
and then click Administrative Tools.
2. Click Routing and Remote Access, and select the server you want to
configure.
3. To configure the modem port, right-click Ports, and then click Properties.
4. In the Ports Properties dialog box, click Configure, select the Demand-
dial routing connections (inbound and outbound) check box, and then
click OK.
5. To create a demand-dial interface and configure it to use the modem to dial

up to the ISP.
• Right-click the server, click Properties, verify that the router flag is on
and that LAN and demand-dial routing are selected, and then click
OK.
• Right-click Network Interfaces, and then click New Demand-dial
Interface.
6. Add a default network route that uses the newly created demand-dial
interface.
How to Configure Exchange to Retrieve E-Mail from an ISP

You can use an SMTP connector when you require a pull relationship between
servers. A pull relationship is a relationship in which one computer queues
messages and the other computer pulls them by using the TURN or ETRN
commands. You can also configure the SMTP connector to retrieve e-mail in a
queue from a remote SMTP server at specified intervals. This means that you
can configure a remote domain to receive and hold e-mail on behalf of the
destination domain. Messages sent to the remote domain are held until the
SMTP ETRN or TURN command is received from an authorized account on
your local server running Exchange.
To configure Exchange The high-level steps for configuring Exchange to use ETRN commands to pull
to retrieve e-mail from e-mail are as follows:
an ISP
1. In Exchange System Manager, browse to the Connectors container for the
routing group.
2. In the console tree, right-click the SMTP connector, and then click
Properties.
3. In the Properties dialog box, click Advanced, and then click Request
ETRN/TURN when sending messages.
4. Select the Additionally request mail at specified times check box if you
want to specify the times at which you want the SMTP connector to contact
the remote domain and trigger the delivery of queued e-mail.
Detailed steps for configuring Exchange to use ETRN commands to pull e-mail
are included in the following practice.
Practice: Configuring In this practice, you will configure Exchange to use ETRN to pull queued
Exchange to pull e-mail messages from another server.
from another server by
using ETRN
completing the practice titled Practice: Creating and Configuring an SMTP
Connector, earlier in this lesson.
! To configure Exchange to pull e-mail from another server by using

ETRN
First Routing Group\Connectors and then expand Connectors.
Properties.
3. In the General SMTP Connector Properties dialog box, click Advanced.
4. On the Advanced tab, click Request ETRN/TURN from different server.
In the Server box, type ISPQUEUE and then click OK.
By default, ETRN will pull messages from a remote server every day at
11:00 P.M. You would like to pull messages every 4 hours. How can
you configure that?
On the SMTP connector, on the Advanced tab, select Run every 4
hours in the connection time box.
! To prepare for the next module

1. In 2400_Miami-Virtual PC, on the menu, click PC, and then click Shut
Down.
2. In the Shut Down dialog box, click Save PC state and keep changes,
verify that the Commit hard drive changes now check box is selected, and
then click OK.
3. In 2400_London-Virtual PC, on the menu, click PC, and then click Shut
Down.
4. In the Shut Down dialog box, click Save PC state and keep changes,
verify that the Commit hard drive changes now check box is selected, and
then click OK.
5. Restart 2400_London-Virtual PC.
How to Identify Problematic E-Mail Domains

A failure may occur at several points when a message is delivered from one
host to another. Identifying where the failure occurred is the first step in
troubleshooting the problem. Use one or both of the following commands to
identify problematic e-mail domains:
! Telnet. SMTP opens a TCP port from the sending host to the receiving host.
If your SMTP host is unable to deliver messages, you can use Telnet to
confirm whether a TCP port can be opened to a receiving host, and whether
the receiving host is responding. You can use the following command to
specify the TCP port to open to a destination host:
telnet fully_qualified_domainname_of_the_host 25
! Nslookup. You can use the nslookup command to query DNS to confirm
whether DNS is working properly, and whether the necessary MX and A
records exist for domains. For example, you can use the nslookup command
to confirm whether DNS has the proper MX and A records for a particular
SMTP domain. Nslookup is a command-line utility. You can use the
following nslookup command to return all the DNS MX records for
domainname:
Nslookup –querytype=mx domainname
Discussion: Managing Routing

Instructions Read the following three scenarios and then discuss possible solutions with the
class.
Scenario 1 You are an administrator in an Exchange organization that has six servers in
three routing groups:
! ServerA and ServerB are in the Birmingham routing group.
! ServerC and ServerD are in the Montgomery routing group.
! ServerE and ServerF are in the Mobile routing group.
The routing group bridgehead servers are ServerB, ServerD, and ServerF. All
three routing group connectors have a cost of 10.
A user sends a message from ServerA to a recipient with a mailbox on ServerE.
The intended recipient reports that the message was not yet received. You
determine that the network between ServerB and ServerF is down, but the link
state table has not been updated to indicate that the status of the connector has
changed. You need to locate the lost message. Where is the lost message?
On Server B. Because there are three routing groups, the sender’s server
will route the message to the local bridgehead server. The message will be
in a retry state for the Birmingham-Mobile routing group connector until
the link state is updated, and then it will be rerouted through the
Birmingham-Montgomery routing group connector. Because the recipient
has not yet received the message, it is most likely still queued on ServerB.
When the message is rerouted, it will be sent to ServerD, and then routed
to ServerF before final delivery at ServerE.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Scenario 2 Your company has never had the ability to send or receive Internet e-mail. You
install an Exchange server, and you configure your server to point to the DNS
server at your ISP. Messages are flowing successfully out of your organization,
but none of the messages that are addressed to recipients in your organization
are being received. What must you do to enable your server to receive Internet
e-mail?
Add an MX record and an A record to DNS that points to your Exchange
server. Exchange is configured to point to the DNS server at your ISP,
allowing it to send SMTP e-mail out. For an external sender to send e-mail
into Exchange, they must be able to resolve the Exchange server as an
e-mail exchanger in DNS. To enable this, you must configure DNS with an
MX record and an A record that points to your Exchange server.
________________________________________________________________
________________________________________________________________
________________________________________________________________
Scenario 3 You have an Exchange server with a dial-up connection to an ISP. You want
your e-mail to be held at the ISP until your Exchange server connects, and then
you want all queued e-mail to be downloaded to your Exchange server. What
must you do to configure this?
Configure your SMTP connector to request ETRN/TURN from the ISP
server. The request ETRN/TURN from a different server will cause
Exchange to send the ETRN command to the ISP upon connection. ETRN
and TURN both pull queued e-mail from a server configured to hold it.
________________________________________________________________
________________________________________________________________
________________________________________________________________
THIS PAGE INTENTIONALLY LEFT BLANK

0989709

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

0989709

Hochgeladen von

Copyright:

Verfügbare Formate

Module 9: Managing

 2003 Microsoft Corporation. All rights reserved.

Important It is recommended that you use PowerPoint 2002 or later to display

Preparation tasks To prepare for this module:

How to Teach This Module

Lesson: Explaining How Message Routing Works in an Exchange

Lesson: Configuring Routing in an Exchange Organization

Lesson: Explaining Internet Connectivity Concepts and Protocols

Lesson: Managing Connectivity to the Internet

Discussion: Managing Routing

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Lesson: Explaining How Message Routing Works in an

*****************************ILLEGAL FOR NON-TRAINER USE******************************

What Are Routing Groups?

*****************************ILLEGAL FOR NON-TRAINER USE******************************

What Are Routing Group Connectors?

*****************************ILLEGAL FOR NON-TRAINER USE******************************

! Cost. Enables an administrator to assign a value between 1 and 100 that

When Is More Than One Routing Group Necessary?

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Multimedia: How Messages Are Routed Within and Between

*****************************ILLEGAL FOR NON-TRAINER USE******************************

The following routing group connectors are configured:

Lesson: Configuring Routing in an Exchange

*****************************ILLEGAL FOR NON-TRAINER USE******************************

The Connectors That Exchange Supports

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Tip Routing Group connector is the name of a type of connector. Because

! The SMTP connector. Establishes an SMTP messaging route between two

! The X.400 connector. Establishes an X.400 messaging route between two

Considerations for Using Routing Group Connectors

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Note Local bridgehead servers are instances of SMTP virtual servers

! Must be used in conjunction with TLS or a security policy to provide

Considerations for Using SMTP Connectors

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Considerations for Using the X.400 Connector

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Practice: Deciding on the Best Way to Connect Routing Groups

*****************************ILLEGAL FOR NON-TRAINER USE******************************

How to Create a Routing Group

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Important This practice is required to complete subsequent practices in this

! To prepare for this practice

4. If it is not already open, open Outlook Web Access by using Microsoft

! To create a routing group

Why can messages not be delivered between London and Miami

How to Create a Routing Group Connector

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Important You must complete this practice to be able to complete subsequent

To create a routing group connector:

What is the purpose of the bridgehead server?

How to Monitor Server, Connector, and Resource Status

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Note For more information about notifications, see Module 2, “Configuring

To use the Monitoring To monitor server, connector, and resource status:

The following status states apply to servers:

Note If a server is unreachable and is in a different routing group, it may

! In Maintenance Mode indicates that monitoring is temporarily disabled due

The following status states apply to connectors:

To monitor routing group connector status:

Lesson: Explaining Internet Connectivity Concepts and

*****************************ILLEGAL FOR NON-TRAINER USE******************************

How an SMTP Connection Works

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**