Copyright
©1996, Que Corporation. All rights reserved. No part of this book
may be used or reproduced in any form or by any means, or stored in a database
or retrieval system without prior written permission of the publisher except
in the case of brief quotations embodied in critical articles and reviews.
Making copies of any part of this book for any purpose other than your
own personal use is a violation of United States copyright laws. For information,
address Que Corporation, 201 West 103rd Street, Indianapolis,
IN 46290 or at support@mcp .com.
Notice: This material is excerpted from Special Edition Using Microsoft Exchange Server, ISBN: 0-7897-0687-3. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
Microsoft Exchange Server is designed on a three-tiered model. The entire collection of Microsoft Exchange servers within a company is called the organization. To facilitate administration and maximize performance, the organization is separated in distinct groups of servers called sites. Each site consists of what are called site resources, which are the individual Exchange servers themselves and the recipients who reside on those servers. Understanding this hierarchy and the underlying network architecture that supports it is crucial to the implementation of Exchange in any company. This chapter is designed to provide an overview of these concepts in order for you to start thinking about how each element will apply in your specific situation.
By the end of this chapter you will be familiar with the following:
Exchange and A Company's Organization
The largest administrative unit in Microsoft Exchange is the organization. All Exchange servers in an association or company are included under the heading of organization. An Exchange organization can be a single-room office with a couple of servers or a huge, multi-national facility with dozens of servers at great geographical distances (see fig. 2.1). Regardless of the situation, often there will be other types of messaging systems to which Exchange must communicate. These systems are not considered part of the Exchange organization, though they may play an integral part in your company's overall messaging scheme.
A Sample Microsoft Exchange Organization.
Exchange Server Sites
Sites are Exchange's second tier. They represent a logical grouping of several Microsoft Exchange Server computers. Servers in a site work together to provide messaging services to a set of users. Within a site, all servers can easily share information and can also be managed as a collection.
There are several other advantages to having multiple servers grouped into one site:
With all of these benefits, you might be inclined to put every Exchange server in one site. For several reasons this is not always the best solution. Therefore, defining where one site ends and one site begins is worthy of some serious consideration (see fig. 2.2). Variables such as network bandwidth, physical links, protocols, network traffic, operating systems, and, of course, cost will affect where site lines are defined in your enterprise. Also, it is important to plan your site boundaries well because it is difficult to reassign them once they are created.
Sample Site Boundaries.
There are some general requirements that must be met by all servers within a site:
There are many other elements to consider when planning Microsoft Exchange Server sites (administration schemes, number of users, integration of other messaging protocols, additional network traffic, etc.). Chapter 10, "Installing Exchange in a Netware Environment," will provide a much more in-depth look at such considerations.
Once site boundaries are determined, further assessment is required to establish the network architecture that will join each one. Again, this requires extensive study of messaging usage across your entire organization and any specific needs determined by your application of the technology.
The boundaries between sites will usually sustain a considerable amount of traffic due to the following types of information traversing site links:
There are two primary Exchange components used to connect sites:
This connector is designed for sites located on the same LAN. A site connector is a Microsoft Exchange built-in connector to facilitate the transfer of messages between two Exchange servers. This connector is an integrated software component to the server. The site connectors use RPC calls to communicate with the other Exchange servers. Site connectors are unlike the Internet or x.400 connectors, in that they will support any Microsoft networking protocol or any Exchange messaging address space or directory services. The key is that the Exchange servers have connectivity between the sites.
The site connector is the most efficient method of site interconnection, but the sites must be able to communicate at high bandwidth using remote procedure calls. Also, because the sites must authenticate each other during communication, they must belong to the same Windows NT domain (or be part of a trusted domain).
There are two major advantages to using a site connector instead of an X.400 connector:
Conditions often mandate the use of the X.400 connector for site links. X.400 connections are used for several reasons. One reason is that your enterprise has a connection to a Value Added network provider in order to send secure messges to a business partner. X.400 is the standard protocol for the VAN connections. The other reason is if your enterprise is quite large, you may configure Exchange to use the x.400 address space as the directory service for the messaging backbone. X.400 provides a standards based address space, ensuring longevity of messaging system in the large enterprises. Microsoft itself uses Exchange with an x.400 backbone to support all 20,000 of its users.
Generally, if any of the following conditions apply, you will need to opt for the X.400 connector:
Messages routed through an X.400 connector must be converted to X.400 standard for messaging interchange. However, the wide range of connectivity options provided more than make up for the slight loss in network efficiency.
Site Resources
Site resources are the third tier in the Microsoft Exchange hierarchy. This tier consists of two main elements:
Server machines may wear many hats in an Exchange environment. An Exchange server can at the same time perform any number of the following tasks:
Also, the server might hold the following additional Windows NT supporting tasks:
To avoid overloading any one server, an optimal situation would be to have a dedicated server for each of the preceding tasks. However, in real-world situations this is often neither practical, nor cost effective. A major goal in planning an Exchange hierarchy is to master the art of load balancing across several machines. Subsequent chapters will discuss these techniques more closely.
It is important in a discussion of Exchange hierarchy to consider the very entities of which directories are created. Recipients are the foundation of an Exchange messaging system. We are the reason that messaging technology exists in the first place. Microsoft Exchange server defines the following four types of recipients:
Hidden recipients can send and receive mail but they do not show up in the address book. Naturally, hidden recipients are not propagated in directory replication.
Each recipient is handled as an individual object by Microsoft Exchange Server during directory replication/synchronization. Each can be assigned individual trust levels (see discussion in Chapter 6, "Planning Connections to Microsoft Mail Systems,") to determine whether its directory entry will be replicated to other sites in an organization.
Each recipient has many different properties and details which can be set by the administrator, but such discussion will occur somewhat later in this book (see chapter 15, "Creating and Configuring Recipients").
Exchange System Naming Conventions
A good naming strategy is crucial to the efficient operation of a Microsoft Exchange system. Each object in a Microsoft Exchange directory is identified by a unique name. This is called the Distinguished Name and it is set when the object is first built; i.e., when you create a new mail box, install a new server, add a new connector, etc. With a good naming strategy you will be able to quickly pinpoint the object anywhere in your organization.
Good references on which to build names are traditionally as follows:
Cute or comical names get old quickly and generally do not provide sufficient information for the widest possible range of personnel to understand your structure.
Microsoft Exchange Message Route
A well-designed Microsoft Exchange system within a reasonably large organization will be skillful interweaving of various messaging technologies. Message routing is the process through which a message eventually reaches its intended recipient. Because of Exchange's connector and gateway options, efficient message routing can and will be an intricate process throughout your enterprise. This section will cover basic routing concepts in order to start giving you a feel for how Exchange handles messages.
Fortunately for the end-user, the complex message routes are abstracted into the single inbox metaphor. As a system administrator, however, it is essential for you to understand all the possible instances of message routing in order to be able to create the most efficient routes in your Microsoft Exchange Organization.
The key elements involved in a routing process are as follows:
How Routing Works
To route a message correctly to an intended recipient, Exchange needs to know not only the address of the intended recipient, but also information that describes the path to that destination. This is accomplished by two crucial pieces of addressing data:
1. Recipient Address
The name of the specific mailbox toward which a message is intended.
It must be in the standard of the recipient system; e.g., an Internet SMTP
address would be 'user@domain'.
2. Address Space
Address space entries identify a certain type of message that a connector
is responsible for routing. Typically, these entries are a subset of a
complete address, identifying the route a certain message will take. Exchange
takes each address space entry as a filter to determine whether a message
should be sent through a connector or gateway.
Directory Names and X.400 Originator/Recipient Addresses
Microsoft Exchange uses a subset of the X.400 Originator/Recipient (O/R) to identify individual recipients. The X.400 O/R address is comprised of attributes that define a specific recipient by country, organization, common name, and a variety of other information.
A Routing Overview
Here is the step-by-step logic taken during routing of a message within an Exchange site:
1. The routing process commences when an Exchange Server's MTA receives a message. The message can be derived from a user's mail box, a connector, or another MTA.
2. If the message's destination is specified by a Directory Name, then the MTA compares the site information of the message (part of the directory name) to the local site. If they do not match, then the recipient is on a different site and the message routed by the process described in the following section.
3. If the message's destination is specified by an O/R address, then the MTA compares the site information of the message (part of the O/R address) to the local site. If they are not the same, then routing proceeds to another site (next section).
If the recipient is a distribution list, the list is separated into its component recipients. Each recipient then enters this routing process independently
1. If the DN or the O/R address matches the local site, then delivery commences. For recipients on the local server, the MTA ensures delivery directly to the information store.
2. For recipients on a different server in the site, the local MTA transfers the message to that server's MTA, which then ensures delivery to the information store.
If at any time an MTA encounters a connection problem with a connector, it will retry the transmission periodically until delivery is successful or until the time-out limit is exceeded. If the time-out limit is exceeded, then the message is returned as non-deliverable (NDR).
Routing Between Microsoft Exchange site and Foreign systems
Here is the step-by-step logic taken during routing of a message within an Exchange site:
1. The routing process commences when an Exchange Server's MTA receives a message. The message can be derived from a user's mail box, a connector, or another MTA.
2. The recipient's address is compared to the local site. If they match, the message is delivered as in the previous list.
3. If the sites do not match, MTA will match the recipient's address space to an available connector or gateway.
4. For example, if the recipient has an SMTP address, the MTA knows how to route it through an Internet Mail connector.
5. If more than one such connection is available, then one is selected based on routing costs.
6. The MTA sends the message through the selected gateway.
7. The message is delivered according to the process of the receiving system. If the receiving system is an Exchange site, the message will be routed as noted in the previous list. Every other messaging system will have its own delivery methods.
Often there may be multiple message routes to a particular destination. In this case, the appropriate route is chosen by the routing cost of that destination (see following section).
Understanding Routing Tables
Routing tables contain all the information a message transfer agent needs to determine where to send messages. Every time you make a change that affects message routing, you will be prompted to rebuild the routing table in order for the change to be saved. Routing tables can be rebuilt manually though a button on the MTA property sheet.
Routing Attachments with Messages
Attachments are routed simultaneously with a message. All necessary file format conversions are handled by the appropriate MTAs through which the message passes. Exchange does have intelligent attachment handling when dealing with distribution lists. Only one instance of an attachment is sent to each mailbox. This eliminates wasted disk space to maintain exact duplicates of an attachment for several users in a same site.
Using Distribution Lists
Distribution lists allow a group of recipients to be addressed by sending one message. For instance, sending a message addressed to a distribution list named "accounting" would be received by all members of that list. Lists are established and modified by the administrators.
See Chapter 15, "Creating and Configuring Recipients," for more information on creating distribution lists.
An individual user can also join appropriate lists from within their Exchange Client.
From the Exchange server standpoint, lists themselves are individual directory objects. This means they can each have specific properties attached to them and are replicated by directory replication and synchronization.
A message sent to a distribution list is treated as a single entity until it is split into its component recipients. When configuring a distribution list's properties, you define an expansion server where the list splits into its components.
Here is the process:
1. A user addresses and sends a message to a distribution list.
2. The message is routed as normal to its intended recipient (in this case, the distribution list).
3. The list object is routed to an Exchange server set as this list's Expansion server. At this point, the list is broken down into its component recipients.
4. Each message to the component recipients is routed individually.
Redundant Site links, Routing Cost, and Load Balancing
For large organizations it is often efficient and safe to establish multiple links between certain sites. This not only increases the system's fault tolerance, but also can be used to balance messaging traffic between sites. Often there will be specific links which receive an extraordinary amount of large traffic. Message routing in this situation demands establishing a priority for whatever connections will receive the traffic. This will be discussed more in depth in the site planning section of this book. There are some general considerations for situations where alternate routes should be established.
A variable called Routing Cost is assigned to each connection (in its property sheet) and used by Exchange message transfer agents to determine the path of a message. The cost of each route can by any number between 0 and 100. A route with cost 0 will always be used first if it is available, and a route with cost 100 will only be used if no other routes are available. Default values for all connectors is one. If two or more connections have the same routing cost, then messaging load will be roughly split equally among them.
In the DGENESIS organization, for example, a number of connectors are set up to connect servers in site LOSANGELES to site BOSTON. In the connectors' property sheets we establish links between the following Microsoft Exchange servers:
1. A site connector over a T-1 line between servers BOSTON01 and LA01. We assign this link a routing cost of 1.
2. A site connector over the same T-1 line between servers BOSTON04 and LA07.
3. We also assign this link a routing cost of 1.
4. An X.400 connector over a private network between server BOSTON02 and LA02.
5. We assign this link a routing cost of 2.
6. Finally, we have one last resort Dynamic RAS X.25 connection between BOSTON01 and LA07. We assign this link a routing cost of 100 due to its inherent monetary cost of message transfer and limited bandwidth.
Messages will normally traverse the first and second site connections. Their routing cost is equal, so Exchange will attempt to distribute message load across both connectors evenly. Under heavy message loads where message cues on both site connectors 1 and 2 are long, Exchange will commence to utilize connector number 3 (X.400). In the rare situation where all three above connectors are disabled (e.g., the T-1 link is down and the BOSTON02 is off-line for repair), Exchange will engage connection number 4 as a last resort.
Load Balancing is the fine art of crafting your system's connections to best handle your diverse system traffic. By considering the above and many other variables, you will able to design an efficient and fault-tolerant system for your enterprise.
Address List and Directory Management
A listing of all available recipients; i.e., a global address list) is of great value to a user. From the standpoint of a network administrator, however, maintaining an accurate and timely address list can be one of the greatest challenges. Traditionally, Microsoft Mail has had a history of difficulties in implementing such functionality, and not since the arrival of Exchange has there been a bigger push for excellence in this area.
This section will overview the essential components of Exchange's directory architecture. Additionally, you will learn important concepts about directory synchronization that will aid in planning and implementing Exchange in your enterprise.
The Directory Service is the primary component responsible for directory manipulation in Microsoft Exchange. The Directory Service uses Directory System Agents (DSAs) that are the sub-programs responsible for executing specific changes to a directory structure.
Maintaining a useful, up-to-date directory involves managing user addresses within an Exchange site, between sites, and between your enterprise and the other systems with which you pass information. If, for example, a user is added on one server, you as the administrator need to decide which other site directories should reflect that change and configure appropriate connectors to facilitate the process. By administrating a combination of system processes you will be able to detail how directory information propagates through your system.
There are two principle Exchange operations that carry out directory management tasks:
Directory Replication
Directory replication is the process by which all the Microsoft Exchange servers in an enterprise will share directory information. To maintain a useful user directory, updates must be accurate, timely, and available to all appropriate users.
Directory replication between servers in the same site is automatic (see fig. 2.3). Each server holds a local copy of the directory for that site. When you as the administrator modify a mailbox at one server, that change is automatically distributed to all servers in that site. Usually it takes about five minutes for new information to propagate across a site.
Directory Replication Within a Site
By default, all directory information is included in replication. This means an exact duplicate of each server's entire directory structure is exchanged during replication. This is efficient within a site due to the high bandwidth network connections typically found between servers. By the same token, network connections between sites are typically much lower bandwidth, so passing entire directory lists is not the most efficient method of maintaining timely address lists.
Directory Replication between Sites is not an automatic process. For two distinct sites to share directory information, there needs to be a specific connector established. This gives you the option to filter what data is actually replicated and what remains unique to that site.
Directory replication between sites can occur if the sites are on the same logical LAN, WAN links, or public and private messaging links (see fig. 2.4). Therefore, public X.400 systems, or even the Internet, can be the transport for your directory replication information between sites.
Directory Replication Between Sites
Directory replication across sites occurs asynchronously and is scheduled in the administrator program. Only one server in each site can be configured to either send or receive replication information. However, one server can be set up to both send and receive the data. Servers that act as the connection boundaries for directory replication are known as the "bridgehead servers."
There are two steps to resolve before directory replication occurs across site boundaries.
1. Decide what specific directory information you wish to exchange with other sites.
2. Act upon that decision and configure each site so only the desired information is replicated.
Each directory object (such as mailboxes, public folders, or distribution lists) can be individually assigned a parameter called replication trust level or sensitivity level. These trust levels determine whether or not a certain object will be replicated to a certain site.
Example: The trust level for replication from the Boston site to the Melbourne site is set to 50. You can create a user mailbox in Boston and set its trust level to 51 and information about that recipient will not be propagated to the Melbourne site in the directory replication process.
Directory Replication Tables are maps that describe the replication links between servers in a site. This is useful mainly when adding new servers. For instance, you bring up Server XYZ in a site, then the Directory Replication Tables are updated to include this server. The next time replication occurs, server XYZ can send and receive updates to all other servers in the site.
Directory replication tables also map links between servers in a site and the bridgehead server. This server is the one machine responsible for receiving directory updates from remote sites.
Directory Synchronization
Perhaps a greater challenge than replicating directory data between Exchange servers is synchronizing directory data with other messaging systems. Typically, this situation arises when linking Exchange to an existing Microsoft Mail network or to a foreign system through an external gateway. Exchange Server supports synchronization with any mail system that uses the Microsoft Mail for PC Networks version 3.x directory synchronization protocol.
Directory synchronization (dir-sync) is optional and it ensures that each directory (or post office for MS Mail) has an up-to-date address list. The dir-sync process is streamlined by propagating only the changes between systems and not the complete address lists.
Because Exchange's directory synchronization is based on the MS Mail dir-sync protocol, let us first examine the architecture of that system before proceeding (see fig. 2.5). MS Mail directory synchronization involves the following core components:
Directory Synchronization Within a Microsoft Mail System.
On a dir-sync server, the master address list is stored separately from local address information. Therefore, when a local address is changed on the machine operating as the dir-sync server, it will communicate that change to itself as would any other requestor.
Microsoft Exchange server contains a component, the Microsoft directory synchronization agent (DXA), that can function in either the server or the requestor role (see fig. 2.6). As with MS-Mail networks, you can set up only one directory synchronization server in each Exchange site. Instead of having a server address list, Exchange uses its standard server directory.
Microsoft Exchange Directory Synchronization Agent
Microsoft Mail for Appletalk networks can participate in directory synchronization with the Microsoft Exchange Connection Gateway installed on the appropriate MS Mail (Appletalk) server. This connection includes a requestor program that will function exactly as any other MS Mail requestor.
Foreign mail systems can also participate in directory synchronization provided they can import and export addressing information using the Microsoft Mail 3.x directory synchronization protocol.
In essence, the foreign system then becomes another requestor and is seen as such by the directory synchronization server.
The following is a description of how a foreign requestor participates in directory synchronization:
1. The foreign requestor creates its own list of address updates and puts them into system messages.
2. The address updates are submitted to the dir-sync server via the appropriate gateway or transport.
3. The dir-sync server receives and incorporates the updates into its master directory list. A new message reflecting address changes is generated.
4. The message containing the updates is transmitted once again via the appropriate gateway to the foreign requestor.
5. The foreign requestor processes the changes into its local address list.
This tool is necessary for adjusting inconsistencies between the Directory and the Public Information Store. The challenge arises when there is a directory entry for a particular folder in the store, yet the folder no longer exists; or the opposite situation where a folder exists, but there is no corresponding directory entry. Typically, this is due to information restored from a backup that is out of sync with current records. The consistency checker is run by the system administrator to adjust such irregularities.
The consistency checker will create a directory entry only if a folder exists in the public information store. However, never will it create an entry in the public information store if an entry exists in the directory.
Understanding the X.500 Directory Service
Microsoft Exchange server directory architecture is based on the 1988 X.500 directory service recommendations. The X.500 directory structure outlines a logical directory object organization scheme, each object's attributes, and how they relate to one another. X.500 is a widely accepted standard, and with its application Exchange can participate in directory data sharing with many different systems.
Exchange defines additional object classes and attributes beyond X.500 standards in order to provide users more descriptive directory entries. For example, Exchange directories can support the following attributes which X.500 does not:
From Here...
This chapter has introduced you to some concepts surrounding the use of organizations and sites in Microsoft Exchange. These concepts included:
Grasping conceptual aspects of Exchange discussed in this chapter will help you understand the installation and configuration examples discussed in later chapters. The following chapters contain related information to some of the items talked about in this chapter:
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation
