Tải bản đầy đủ (.pdf) (30 trang)

Tài liệu Module 9: Message Flow in Microsoft Exchange 2000 pdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.31 MB, 30 trang )





Contents
Overview 1
Message Flow Architecture 2
Working With Failed Links 9
Message Tracking 14
Lab A: Analyzing Message Flow in
Exchange 2000 16
Review 23

Module 9: Message
Flow in Microsoft
Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

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



 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, BackOffice, Jscript, NetMeeting, Outlook, Windows, and Windows
NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or
other countries.

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

Program Manager: Steve Thues
Product Manager: Megan Camp
Instructional Designers: Bill Higgins (Volt Technical), Jennifer Morrison, Priya Santhanam
(NIIT (USA) Inc), Samantha Smith, Alan Smithee
Instructional Software Design Engineers: Scott Serna
Subject Matter Experts: Krista Anders, Megan Camp, Chris Gould (Global Logic Ltd),
Janice Howd, Elizabeth Molony, Steve Schwartz (Implement.Com), Bill Wade (Wadeware LLC)
Technical Contributors: Karim Batthish, Paul Bowden, Kevin Kaufman, Barry Steinglass,
Jeff Wilkes
Graphic Artist: Kimberly Jackson (Independent Contractor)
Editing Manager: Lynette Skinner
Editor: Kelly Baker
Production Manager: Miracle Davis
Build Manager: Julie Challenger
Production Support: Marlene Lambert (Online Training Solutions, Inc)
Test Manager: Eric Myers
Courseware Testing: Robertson Lee (Volt)
Creative Director, Media/Sim Services: David Mahlmann
Web Development Lead: Lisa Pease
CD Build Specialist: Julie Challenger

Localization Manager: Rick Terek
Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Lead Product Manager, Messaging: Dave Phillips
Group Manager, Courseware Infrastructure: David Bramble
Group Product Manager, Content Development: Dean Murray
General Manager: Robert Stewart

Module 9: Message Flow in Microsoft Exchange 2000 iii

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Instructor Notes
This module provides students with an understanding of the architecture upon
which messaging is built, how messages arrive at their destinations when they
are sent from various clients, how to work with failed links, and how to track
messages. After completing this module, students will be able to:
!
Describe the mail flow architecture in Exchange 2000, including how
messages flow.
!
Describe how Exchange handles failed links, including how Exchange
recovers a link and how Exchange reroutes messages.
!
Outline how the Message Tracking Center tracks messages, and enable
message tracking as well as subject logging.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach

this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft
®
PowerPoint
®
file 1572A_09.ppt

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the labs.
!
Practice the presentation with the PPT slides, noting the animation slides
especially.
!
Review the multimedia.

Presentation:
90 Minutes

Lab:
30 Minutes
iv Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


Module Strategy
Use the following strategy to present this module:
!
Message Flow Architecture
This topic focuses on the architecture used to send and receive messages.
Make sure students understand the difference between intraserver message
flow, inbound message flow, and outbound message flow.
Much of the material in this section, and several of the following sections, is
theoretical because the system performs most of the work. It is important
that students understand how the system functions to be able to optimize
usage.
!
Working With Failed Links
This topic focuses on how Exchange handles failed links, including the
factors causing a DOWN link state connector status, the process of restoring
links, and rerouting messages.
Expect students to want to discuss situations in which messages are blocked
because connectors are down. It is important to pace this section so that you
can address these questions without disrupting the overall flow of the
module.
!
Message Tracking
This topic focuses on the details of message tracking. Explain what
information is available about tracked messages, how to enable message
tracking, and how to enable subject logging and display.

Module 9: Message Flow in Microsoft Exchange 2000 v

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.

The lab in this module is also dependent on the classroom
configuration that is specified in the Customization Information section at the
end of the Classroom Setup Guide for course 1572A, Implementing and
Managing Microsoft Exchange 2000.

Lab Setup
The following list describes the setup requirements for the lab in this module.
Setup Requirement 1
The lab in this module requires Exchange 2000 and a custom MMC. To prepare
student computers to meet this requirement, perform one of the following
actions on each server in the organization:
!
Complete the labs for Module 2, “Installing Microsoft Exchange 2000,” in
course 1572A, Implementing and Managing Microsoft Exchange 2000.
!
Install Exchange 2000 at D:\Program Files\Exchsrvr on each server into an
organization named Northwind Traders. Components installed are Microsoft
Exchange Messaging and Collaboration Services, Microsoft Exchange
System Management Tools, and Microsoft Exchange Instant Messaging
Service. Have the students create a custom MMC in the C:\Documents and
Settings\All Users\Desktop that is saved as your_firstname Console. The
MMC contains the Active Directory Users and Computers snap-in and the
Exchange System snap-in.


Setup Requirement 2
The lab in this module requires a custom OU, a user account for each student, a
mailbox for each student, an Outlook profile, and for the Domain Admins group
to be delegated full control of the organization. To prepare student computers to
meet this requirement, perform one of the following actions on each server in
the organization:
!
Complete the labs for Module 3, “Administering Microsoft Exchange
2000,” in course 1572A, Implementing and Managing Microsoft Exchange
2000.
!
Create an organizational unit in Active Directory that is named
your_servernameOU for each server in the classroom. Create a user account
in each server’s OU for each student. The account is a member of the
Domain Admins group and has a mailbox on the student’s Exchange server.
Create an Outlook profile for each student on their own server that opens
their mailbox. Delegate the full administrator role on the Northwind Traders
organization.

Importan
t

vi Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Setup Requirement 3
The lab in this module requires a second routing group and a routing group
connector to be created. To prepare student computers to meet this requirement,

perform one of the following actions on each server in the organization:
!
Complete the labs for Module 8, “Message Routing,” in course 1572A,
Implementing and Managing Microsoft Exchange 2000.
!
For each organization in the classroom, create a routing group named
Second Routing Group that contains all member servers of the applicable
domain. Then, choose a bridgehead server in the second routing group and
create a routing group connector between the two routing groups.

Lab Results
Performing the lab in this module introduces the following configuration
changes:
!
All servers are moved to the first routing group.
!
The routing group connector and second routing group are deleted.
!
Message tracking and subject logging are enabled for all servers.

Module 9: Message Flow in Microsoft Exchange 2000 1

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Overview
!
Message Flow Architecture
!
Working With Failed Links
!

Message Tracking


Several components in Exchange 2000 work with components in Windows
2000 to provide message flow. Understanding how these components work
together enables you to understand the underlying architecture, how messages
flow between their sources and their destinations, how to work with failed links,
and how to track messages along their routes.
After completing this module, you will be able to:
!
Describe the message flow architecture in Exchange 2000.
!
Describe how Exchange handles failed links, including recovering a link
and rerouting messages.
!
Enable message tracking as well as subject logging, and explain how to use
tracking to troubleshoot message delivery.

Topic Objective
To provide an overview of
the module topics and
objectives.

Lead-in
In this module, …
2 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

#

##
#

Message Flow Architecture
!
Message Mail Flow Architecture
!
Intraserver Message Flow
!
Outbound Message Flow
!
Inbound Message Flow


There are several components in Exchange 2000 and Windows 2000 that work
together to send and receive messages. These components run on each server
running Exchange 2000. After you understand the underlying architecture, you
will be able to describe intraserver, outbound, and inbound message flow.
Topic Objective
To introduce the
components and functions
of message flow
architecture.
Lead-in
Several Exchange 2000 and
Windows 2000 components
comprise message flow
architecture.
Module 9: Message Flow in Microsoft Exchange 2000 3


BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Message Mail Flow Architecture
IIS
SMTP
Advanced
Queuing Engine
Message
Categorizer
Routing
Information
Information
Store
Store
EXIPC


Each component of the message flow architecture performs a specific function
when sending and receiving messages. Within Exchange, message flow
involves routing, queuing, categorizing, and communication between protocols
and the Information Store.
Information Store
The Exchange 2000 Information Store is the end point for messages sent to
users with mailboxes on the server running Exchange 2000.
The Information Store is also the starting point for messages that are sent by
Messaging Application Programming Interface (MAPI) clients, such as
Outlook, that connect directly to the Exchange 2000 Information Store.
EXIPC
The Exchange InterProcess Communication (EXIPC) provides a queuing layer
that enables IIS and store processes (Inetinfo.exe and Store.exe) to quickly

move data back and forth. The ability to move data quickly is required to
achieve the best possible performance between the protocols and database
services on a server running Exchange 2000.
IIS
The client access protocols in Exchange 2000 are part of Internet Information
Services (IIS). The IIS process is the protocol engine. Incorporating the
protocols into IIS enables you to host Exchange 2000 subsystems (protocol,
storage, and directory) on virtual servers on either the same computer or on
different computers, which makes Exchange 2000 more scalable.
Topic Objective
To describe message flow
architecture components
and functions.
Lead-in
Managing incoming and
outgoing message traffic is
important for effective
message handling.
4 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Advanced Queuing Engine
The Advanced Queuing Engine defines and manages queues for message
delivery, such as domain and link queues that you can query for transport
information. When the Advanced Queuing Engine receives an SMTP Mailmsg
object, it forwards the Mailmsg object to the Message Categorizer, which
returns the message destination. The Advanced Queuing Engine then queues
the Mailmsg object for delivery based on the routing information provided by
the routing engine.

Message Categorizer
The Message Categorizer is a plug-in to the Advanced Queuing Engine. It is a
collection of event sinks that perform advanced address resolution on every
Mailmsg object that travels through the Advanced Queuing Engine. It may also
perform bifurcation for messages with two types of recipients, RTF and MIME.
Bifurcation creates multiple Mailmsg objects, one for all RTF recipients and the
other for all MIME recipients. These messages may be intended for the local
information store, a remote host through the message transfer agent (MTA), or
a remote host through SMTP.
The Message Categorizer is turned off by default in Windows 2000. Installing
Exchange 2000 activates the Message Categorizer.
Routing
The routing engine adds link state routing capabilities by providing accurate
next hop information to the Advance Queuing Engine. The routing engine
creates and maintains link state information for the server running Exchange
2000.
SMTP
The SMTP service processes incoming traffic from SMTP clients, such as
Microsoft Outlook Express, and other SMTP hosts, such as another Exchange
server. Windows 2000 also uses this transport to perform certain operations,
such as directory replication in Active Directory.
Delivery Tip
Ask students to explain what
determines whether a
message is handed off to
the local Information Store
driver or the local SMTP
stack.
Module 9: Message Flow in Microsoft Exchange 2000 5


BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Intraserver Message Flow
IIS
SMTP
Advanced
Queuing Engine
Message
Categorizer
Routing
Information
Information
Store
Store
EXIPC
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5

6
6
6
Exchange Store
Driver
MAPI
Client

The Information Store receives messages
When users send messages to users on the same server, the Information Store
receives the messages and then passes them to IIS. IIS processes the messages
and returns them to the Information Store.
Exchange routes a message sent by a sender on the same server as the recipient
through the following steps:
1. A MAPI client, such as Outlook, sends a message to a local recipient. The
outbound message is first received in the Information Store.
2. The MailMsg object is passed to the Advanced Queuing Engine regardless
of the recipient.
3. The Advanced Queuing Engine places the MailMsg object in the pre-
categorizer queue.
4. The Message Categorizer retrieves the MailMsg object from the pre-
categorizer queue and processes the message. The Message Categorizer
expands groups when appropriate and checks sender and recipient limits.
5. Because the recipient is local, the Message Categorizer then places the
message in the local delivery queue.
6. The Exchange store driver associates a pointer from the message to the
recipient’s mailbox.


The MailMsg object is similar to a message header and does not contain

the body of the message.

Topic Objective
To describe how a message
originating on the same
server flows through the
architecture.
Lead-in
When a recipient of a
message is on the same
server as the sender, the
message is delivered
directly.
Delivery Tip
Ask students to describe the
purpose of the pre-
categorizer queue.
Note
6 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Outbound Message Flow
IIS
SMTP
Advanced
Queuing Engine
Message
Categorizer
Routing

Information
Information
Store
Store
EXIPC
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
6
6
6
Exchange Store
Driver
MAPI
Client
7
7
7

8
8
8
SMTP Host


When users send messages to users on a different server, Exchange routes the
outbound message from the Information Store to SMTP through IIS before
delivering it.
The following steps outline the message flow process for outbound SMTP
messages:
1. A MAPI client, such as Outlook, sends a message to a remote recipient. The
outbound message is first received in the Information Store.
2. The MailMsg object is passed to the Advanced Queuing Engine regardless
of the recipient.
3. In the Advanced Queuing Engine, the Message Categorizer processes the
MailMsg object, including bifurcation. If the message is addressed to both
RTM and MIME recipients, bifurcation will divide the message into
multiple identical MailMsg objects, one for each type of recipient.
4. The Message Categorizer expands groups when appropriate, checks sender
and recipient limits, and sets the appropriate content type for each recipient
that are defined on the Internet Message Formats object under global
settings. The MailMsg object is then passed to the appropriate destination
domain queue inside the Advanced Queuing Engine.
5. The Advanced Queuing Engine passes the destinations for the message to
the routing engine, which returns next-hop identifiers.
6. SMTP initiates an SMTP session with the remote SMTP hosts that are
identified by the routing engine.
7. After an SMTP session has been established with the remote host, the
Information Store driver retrieves the body of the message from the

Information Store, which converts the message as necessary for each
bifurcated message.
8. SMTP streams the message from the queue to the remote host.

Topic Objective
To describe how an
outbound message flows
through the architecture.
Lead-in
An outbound SMTP
message differs from an
instraserver message.
For Your Information
Bifurcation is the process of
dividing a message into two
identical messages of
different message formats.
Module 9: Message Flow in Microsoft Exchange 2000 7

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


Exchange 2000 converts the message to TNEF if destined for another
Exchange 2000 server, or MIME if destined for the Internet.

Outbound Messages to X.400 Recipients
Exchange routes outbound messages destined for X.400 recipients as local
recipients and places them into the MTS-OUT store folder. The MTA retrieves
the outbound X.400 messages and delivers them to their next hop.
Note

8 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Inbound Message Flow
IIS
SMTP
Advanced
Queuing Engine
Message
Categorizer
Routing
Information
Information
Store
Store
EXIPC
NTFS
NTFS
4
4
4
2
2
2
7
7
7
5
5

5
6
6
6
3
3
3
1
1
1
SMTP Host
Queue


SMTP receives inbound messages for local users and processes them through
IIS before they reach the Information Store for delivery.
The following steps outline the basic inbound message flow process in an
Exchange 2000 Server:
1. An SMTP server/client establishes an SMTP session with the SMTP host.
2. The SMTP host streams the message to the Queue directory on the NTFS
file system. Once complete, the message is committed, confirming that the
entire message was received.
3. The Advanced Queuing Engine then retrieves a portion of the message, the
MailMsg object, from NTFS and places it in the pre-categorizer queue.
4. In the Advanced Queuing Engine, the Message Categorizer retrieves the
MailMsg object from the pre-categorizer queue and processes the message.
The Message Categorizer also expands groups when appropriate, checking
sender and recipient limits, and determining mailbox locations.
5. The Message Categorizer then places the MailMsg object in a destination-
domain queue inside the Advanced Queuing Engine, or places the MailMsg

object in the local delivery queue if the recipient is local.
6. The routing engine creates a next-hop identifier for their destination for
messages being routed out through SMTP.
7. The Information Store retrieves messages intended for local recipients from
the local delivery queue.

Inbound Messages From X.400 Recipients
Messages sent from X.400 recipients arrive through the Message Transfer
Agent (MTA). When an X.400 system sends a message to Exchange 2000, the
MTA receives it and places the message in the MTS-IN store folder. This folder
is commonly referred to as a hidden mailbox. The Information Store then
handles the message exactly like all other messages.
Topic Objective
To describe how an inbound
SMTP message flows
through the architecture.
Lead-in
An inbound SMTP message
is processed almost in
reverse of an outbound.
Delivery Tip
Ask students to explain what
it means when a message is
committed.
Module 9: Message Flow in Microsoft Exchange 2000 9

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

#
##

#

Working With Failed Links
!
Determining Link Failure
!
Rerouting Messages
!
Recovering a Link


After Exchange determines that a link has failed, Exchange reroutes the
message and attempts to recover the failed link. Understanding the process
involved in each of these actions enables you to more effectively track
messages and troubleshoot message delivery issues.
Topic Objective
To outline this topic.
Lead-in
Failed links disrupt message
flow.
10 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Determining Link Failure
Routing Group B
Routing Group B
Routing Group A
Routing Group A
Routing Group A

Routing Group A
Down
Down
First Retry: 10 min
First Retry: 10 min
Call three tries and failures
Call three tries and failures
Second Retry: 10 min
Second Retry: 10 min
Call three tries and failures
Call three tries and failures
Third Retry: 10 min
Third Retry: 10 min
Call three tries and failures
Call three tries and failures
Subsequent Retry: 10 min
Subsequent Retry: 10 min
Call three tries and failures
Call three tries and failures
Delay Notification:
Delay Notification:
12 hours
12 hours
Expiration Timeout:
Expiration Timeout:
2 Days
2 Days
NDR
NDR
Down

Down
Glitch Retry
State
Glitch Retry
State
:60:60:60
691


Exchange determines that a link has failed when the following process occurs:
1. The network connection between routing groups fails.
2. A session cannot be established with any of the connector’s remote
bridgehead servers and the connector is marked as DOWN.
3. The connector enters a glitch retry state, and attempts to establish a session
three different times at 60-second intervals.
4. If unsuccessful, the connector continues to try to establish a connection at
the first, second, third, and subsequent retry interval that you configured
on the virtual server.
5. If the message has not been delivered by the time configured on the virtual
server’s Delay Notification parameter, the Exchange server returns a
warning message to the sender stating that the message has not yet been
delivered.
6. If the message has not been delivered by the time configured on the virtual
server’s Expiration Timeout parameter, the Exchange server returns the
message to the sender along with a non-delivery report (NDR).

When a connector fails to deliver a message because of a link failure, Exchange
tags the connector as DOWN and notifies the routing group master.
After marking the connector as DOWN, if another route is available, Exchange
will reroute the message and the bridgehead server will continue to try the

connection according to the subsequent retry interval until it is restored.
Topic Objective
To describe the factors
causing DOWN link state
connector status.
Lead-in
Link State will not consider a
particular connector if it is in
the DOWN status.
Module 9: Message Flow in Microsoft Exchange 2000 11

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Rerouting Messages
Routing Group C
Routing Group C
Routing Group D
Routing Group D
Routing Group A
Routing Group A
Routing Group B
Routing Group B
Cost = 1
Cost = 1
Cost = 1
Down
Down
Routing Group B
Routing Group B
Cost = 1

Down
Down
Glitch Retry
State
Glitch Retry
State
:60:60:60


If a connection fails between routing groups, Exchange attempts to reroute the
message. For example, in the graphic on this page, a user in Routing Group A
sends a message to a recipient in Routing Group D. The least cost route
between Routing Group A and Routing Group D is through Routing Group B.
Failed Connector
If a sender in Routing Group A sends a message to a recipient in Routing Group
D and a connector fails, the message would be rerouted as shown below.
1. The message is sent from the bridgehead server in Routing Group A to the
bridgehead server in Routing Group B.
2. The bridgehead server in Routing Group B attempts to open an SMTP
connection to a bridgehead server in Routing Group D. The connection
between Routing Groups B and D fails.
3. If there are multiple remote bridgehead servers specified on the connector to
Routing Group D, the local bridgehead in Routing Group B attempts to open
a connection between each of these servers until it finds a connection or no
more servers are available.
4. If none of the bridgeheads in Routing Group D can be contacted, the
connection is marked as DOWN and goes into a glitch-retry state. The
connection is tried again three times at 60-second intervals.
5. Within five minutes, the bridgehead server in Routing Group B notifies the
routing group master of the failed connection and the link state is

propagated.
6. The bridgehead server in Routing Group B calculates that an alternate route
is available to Routing Group D through Routing Group C.
7. The message is rerouted from Routing Group B to Routing Group D
through Routing Group C.

Topic Objective
To describe the process
involved in rerouting
messages when links are
DOWN.
Lead-in
If a connection fails between
routing groups, messages
are rerouted.
Delivery Tip
Be sure to review the
animation sequences for
this slide. There are
numerous builds that
correspond to the numbered
paragraphs in the text.
12 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


A message routed to a connector with a Remote initiated activation
schedule is not rerouted by Exchange.


Unavailable Routes
If all routes to a routing group are unavailable, Exchange holds messages
intended for that routing group in the local message queue. Messages are not
sent through routing groups to a routing group that has no working connectors.
If the Expiration timeout specified on the Delivery tab of the SMTP virtual
server has passed (2 days by default), the messages are returned as non-
delivered to the originators.
Note
Module 9: Message Flow in Microsoft Exchange 2000 13

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Recovering a Link
Routing Group B
Routing Group B
Routing Group A
Routing Group A
Routing Group B
Routing Group B
Routing Group A
Routing Group A


When messages have been rerouted due to a DOWN link status, the bridgehead
server will continue to try to connect to the destination bridgehead server at the
subsequent retry interval configured on the virtual server. After a connection is
re-established, the following process occurs:
1. The sending bridgehead server in Routing Group A attempts a connection to
the first bridgehead server in Routing Group B over TCP port 25 and is
successful.

2. All messages queued on the bridgehead server in Routing Group A for
delivery to Routing Group B are delivered to the target bridgehead server
and the routing group master is notified the connector is UP within five
minutes.

Topic Objective
To illustrate how servers
restore recovered links.
Lead-in
When a connector is
DOWN, the bridgehead
server does not ignore it.
Delivery Tip
The slide animates to show
a DOWN link, and then how
it recovers when the
connection is made.
14 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Message Tracking
C
C.log
C.log
Message
Tracking Center
A
D
B

A.log
A.log
D.log
D.log
B.log
B.log
Message ID
Server B
Message ID
Server B
Server C
Server C
Server D
Server D
Message
Delivered
Message
Delivered


You can track messages in your Exchange 2000 organization by using the
Exchange 2000 Message Tracking Center. Message tracking works in
Exchange organizations that have either Exchange 5.5 or Exchange 2000
servers. Exchange message tracking will also track messages that are sent to
and received from foreign connectors, such as the cc:Mail connector.
The Message Tracking Center tracks and records messaging activity on the
Exchange 2000 servers as messages flow through the organization.
Enabling Message Tracking
You can enable message tracking on the general property page of the Exchange
2000 server or by using system policies.

After creating a system policy container in the administrative group, you can
create a system policy that enables message tracking and select the servers to
which you will apply the system policy.
Exchange 2000 adds all messages that are routed through the message tracking
enabled server to the message tracking logs stored in a directory on the server.
You can configure message tracking to record information about the sender, the
message, the recipient, and the subject line of the message. You may need this
information should you want to trace a message back to its source to determine
why it was not delivered appropriately.
When you enable message tracking on a server running Exchange 2000,
Exchange creates a set of logs in a shared directory named servername.log and
records:
!
Whether the message came from another server in the routing group, or if it
was received by a connector on the local server.
!
If the message was delivered to a local recipient.
!
If the message was forwarded to another server in the routing group or out
to a local connector.

Topic Objective
To describe how messages
are tracked as well as what
information is available
regarding messages
tracked.
Lead-in
For message tracking to
work, messaging activity

must be recorded on the
Exchange 2000 servers as
messages move through the
organization.
Delivery Tip
Demonstrate how to enable
the message tracking
process by creating a
system policy.
Module 9: Message Flow in Microsoft Exchange 2000 15

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

You can change the location of where message tracking logs are stored by
editing the Windows 2000 registry of the Exchange 2000 server.

By default, Exchange does not display message subjects in message logs.
If you want message subjects to be visible during message tracking and on both
the SMTP and MAPI queues, you can enable subject logging by using a system
policy. If you enable subject logging you may want to consider changing the
permissions on the servername.log share.

Tracking Messages
The Message Tracking Center can follow the message track from server to
server until either the message is delivered to the Exchange recipient or out to a
foreign connector. The following example illustrates this process:
1. The Message Tracking Center searches through the logs on Server A to
locate the message ID of the message to be tracked. After the message is
located, the Message Tracking Center deciphers the next hop for the
message, which is Server B.


If you don’t start the search at the sender’s mailbox server, you may
not know if the resulting search is a full or partial message track.

2. Exchange 2000 accesses Server B’s message tracking log share and the
message ID is located. Server C is identified as the next hop.
3. Exchange 2000 accesses Server C’s message tracking log share and the
message ID is located. Server D is identified as the next hop.
4. Exchange 2000 accesses Server D’s message tracking log share and the
message ID is located. The message is delivered to a recipient on Server D,
which is indicated in the log.


If a server along the message track does not have message tracking
enabled, the message track will end there and the message track will be
incomplete.

Tracking Undelivered Messages
When a message is tracked to a server, but not all the way to its intended
destination, you can review the queues of the server and troubleshoot why that
particular server is not delivering the message to its next hop.
Note
Note
Note
16 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Lab A: Analyzing Message Flow in Exchange 2000



Objectives
After completing this lab, you will be able to:
!
Track messages by using the Message Tracking Center and view link status
by using WinRoute.

Prerequisites
Before working on this lab you must have:
!
Knowledge of Windows 2000.
!
Knowledge of Exchange System Manager.
!
Knowledge of Outlook 2000.
!
Knowledge of WinRoute.

Lab Setup
To complete this lab, you need:
!
To have Microsoft Exchange 2000 installed at D:\Program Files\Exchsrvr
into an organization named Northwind Traders. Components installed are
Microsoft Exchange Messaging and Collaboration Services, Microsoft
Exchange System Management Tools, and Microsoft Exchange Instant
Messaging Service on all servers in your domain.
!
To have a custom MMC in the C:\Documents and Settings\All
Users\Desktop that is saved as your_firstname Console. The MMC contains
the Active Directory Users and Computers snap-in and the Exchange

System snap-in.
!
An organizational unit is in Active Directory that is named
your_servernameOU.
Topic Objective
To introduce the lab.
Lead-in
In this lab, you will analyze
how messages flow in
Exchange 2000.
Explain lab objectives.
Module 9: Message Flow in Microsoft Exchange 2000 17

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

!
A user account in your_servernameOU. The account is a member of the
Domain Admins group and has a mailbox on the your Exchange server.
!
An Outlook profile on your server that opens your mailbox.
!
The Domain Admins group is delegated Full Administrator role on the
Northwind Traders organization.
!
A user account and mailbox on each of the remaining three Exchange 2000
servers in the domain.
!
To have two routing groups, one containing at least the domain controller
and another containing at least two member servers.
!

To have a routing group connector between the two routing groups.
!
To identify the values for the variables listed in the following table:
Variable Value

your_domain
your_servername
your_firstname
your_username


Estimated time to complete this lab: 30 minutes
18 Module 9: Message Flow in Microsoft Exchange 2000

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Exercise 1
Using Message Tracking and WinRoute
In this exercise, you will use message tracking, the status tool, and WinRoute to analyze message
flow and system status before, during, and after a network interruption.
Scenario
Your company requires that you be able to determine the point at which message delivery fails. To
accomplish this, you enable message tracking so that you can identify the point at which message
transfer fails. You then use the status tool and WinRoute to identify connector and server status.

Tasks Detailed Steps
1.
Enable message tracking
and subject logging and
display on your server.

a.
Log onto Windows 2000 as your_username.
b.
Open your_firstname Console.
c.
Expand Northwind Traders (Exchange), and then expand Servers.
d.
Right-click your_servername, and click Properties.
e.
On the General tab, select the Enable subject logging and display
and Enable message tracking check boxes, and then click OK.
2.
Identify the bridgehead
server for the routing group
connector that connects the
Second Routing Group to
the First Routing Group.
Verify that this bridgehead
is not the routing group
master for the Second
Routing Group, and select a
different master if
necessary.
a.
Expand Routing Groups, expand Second Routing Group, expand
Connectors, right-click the routing group connector that connects to
the First Routing Group, and then click Properties. Write down the
name of the bridgehead server that is listed in the These servers can
send mail over this connector window, and then click Cancel.
________________________________________________

b.
In the Second Routing Group, click Members.
c.
Verify that the bridgehead server you identified above in Step a for the
Second Routing Group is not listed as a Master. If the bridgehead
server is listed as the master, work with your domain team to determine
which of the two remaining servers in your routing group will become
the new routing group master. If your server is identified as the new
routing group master, right-click your_servername and click Set as
Master.
3.
Send a message with a
delivery receipt requested to
a user in the remote routing
group.
a.
Start Outlook.
b.
Click New, click To, and then select a mailbox that is in the other
routing group.
c.
Type a short subject and a short message.
d.
Click Options, select the Request a delivery receipt for this message
check box, and then click Close.
e.
Click Send and wait for the delivery receipt to appear in your Inbox.
Module 9: Message Flow in Microsoft Exchange 2000 19

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


Tasks Detailed Steps
4.
Track the message that you
just sent by using the
Message Tracking Center.
a.
Switch to your_firstname Console.
b.
Expand Northwind Traders (Exchange) and then expand Tools.
c.
Right-click Message Tracking Center, and then click Track
Message.
d.
Next to the From box, click Browse.
e.
Click your_username, and then click OK.
f.
Click Find Now.
g.
Click the link for the message that you sent to the other routing group.
h.
Review the contents of the Message History window to verify that the
message was transferred through the bridgehead servers in each routing
group.
i.
Click Close to close the Message History window.
j.
Click Close to close the Message Tracking Center window.
5.

Verify that all members,
connectors, and target
bridgeheads for the Second
Routing Group are detected
as available by using
WinRoute. Notify the other
students in your domain that
you have completed this
task.
a.
Click Start, and then click Run.
b.
In the Open box, type D:\exchange\support\utils\i386\winroute.exe
and then click OK.
c.
In the WinRoute window, click File, and then click New Query.
d.
In the Server Name box, type your_servername and then click OK.
e.
Expand RG: Second Routing Group (First Administrative Group)
(5.0.0).
f.
Expand RG Members to verify that all RG Members have a green
check mark to indicate that they are detected as UP.
g.
Expand Connectors to verify that the routing group connector has a
green check mark to indicate that it is detected as UP.
h.
Expand the routing group connector, expand Target Bridgeheads, and
then expand the bridgehead for the other routing group to verify that

the BH status information reads Remote Server Available
(CONN_AVAIL).
i.
Notify the students in your domain that you have completed this task.
Do not proceed until all members of your domain have completed the previous tasks.
6.
On the bridgehead server for
the Second Routing Group,
simulate network failure by
disabling your local area
network connection.
a.
On the bridgehead server for the Second Routing Group, click Start,
point to Settings, and then click Network and Dial-up Connections.
b.
Right-click Local Area Connection and click Disable.

×