Special Edition Microsoft Exchange Server 5.5

Previous chapterNext chapterContents


- 2 -
Understanding Exchange's Organization and Sites



Exchange Server is designed on a three-tiered model. The entire collection of Exchange servers within a company is called the organization; i.e., the root or starting point of the Exchange Server directory hierarchy. To facilitate administration and maximize performance, the organization is separated in distinct groups of servers called sites, which are one or more Exchange Server computers connected together. Each site consists of 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 for you to start thinking about how each element will apply in your specific situation.

Understanding Exchange Organizations and Sites

The largest administrative unit in 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, multinational facility with dozens of servers at great geographical distances (see Figure 2.1). Regardless of the situation, often there will be other types of messaging systems with 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.

FIG. 2.1 A Sample Exchange Organization.

Sites are the second tier of Exchange's hierarchy. They represent a logical grouping of several Exchange Server computers. Servers in a site work together to provide messaging services to a set of users, unified administration and communication services. 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:

Defining Site Boundaries

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 serious consideration (see Figure 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 the number of sites and their boundaries because it is difficult to split or join other sites once they are created. Even moving users from one site to another is not a trivial task.

FIG. 2.2 Sample site boundaries. These are also the actual U.S. offices used as examples throughout this book.

There are some general requirements that must be met by all servers within a site:

There are many other elements to consider when planning Exchange Server sites-- administration schemes, number of users, integration of other messaging protocols, additional network traffic, and so on. Grouping users who work together on the same server and sites reduces network traffic and resource utilization. Chapter 10, "NetWare Considerations/ Migrating from Groupwise," provides a much more in-depth look at such considerations.

Linking Sites

Once site boundaries are determined, further assessment is required to establish the network architecture that will join each one. Routing within a site requires little planning; however, routing between sites or to another e-mail system requires detailed planning and configuration. 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:

Using Site Connector  This connector is designed for sites located on the same LAN. A site connector is an Exchange built-in connector used 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 as 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 a 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:

Using the 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 messages to a business partner. X.400 is the standard protocol for the WAN 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 the longevity of the messaging system in large enterprises. Microsoft itself uses Exchange with an X.400 backbone to support all 20,000 of its users. X.400 offers some advantages--you can define message size and schedule when connections happen, as well as see the message route. Some disadvantages include the X.400 is more complicated to configure and can be costly if there's a high volume of data. 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 makes up for the slight loss in network efficiency.

Exchange Site Resources

Site resources are the third tier in the Exchange hierarchy. This tier consists of two main elements:

Servers

Servers may wear many hats in an Exchange environment. An Exchange server can 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 mastering the art of load balancing across several machines. Other load balancing factors include the number of Exchange servers, the type of platform number of disks, CPU speed, amount of memory, public folder replication, and type of mailbox rules. Subsequent chapters discuss load balancing in detail.

Recipients

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. Exchange server defines the following four types of recipients:

Exchange Server during directory replication/synchronization handles each recipient as an individual object. Each can be assigned individual trust levels (see the discussion in Chapter 7, "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 that can be set by the administrator, but such discussion will occur later in this book (see Chapter 16, "Creating and Configuring Recipients").

Exchange System Naming Conventions

A good naming strategy is crucial to the efficient operation of an Exchange system. Each object in an Exchange directory is identified by a unique name. This is called the Distinguished Name and it is set when the object is first built--when you create a new mail box, install a new server, add a new connector, and so on. With a good naming strategy that uses meaningful and logical names, you will be able to quickly pinpoint the object anywhere in your organization.

Good references on which to build names are traditionally:

Other things you should consider are whether you have to be compatible with another mail system or other applications, and whether your organization may someday expand beyond the country. 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.

Exchange Message Routing

A well-designed Exchange system within a reasonably large organization will reflect 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 and 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 Exchange Organization.

The key elements involved in a routing process are:

Understanding Routing

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:

Recipient Address--the name of the specific mailbox to which a message is intended. It must be in the standard of the recipient system, meaning a recipient on your Exchange system will be addressed following your naming standard, such as users first name and last name. An Internet SMTP address would be (users@domain).

Address Space--identifies 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

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.

Understanding Routing

For routing of a mail message on the same Exchange Server, the Information Store is responsible for the delivery of a mail message when both the sender and receiver of a mail message are on the same Microsoft Exchange Server.

For routing of a mail message between two different Exchange Severs in the same Exchange site, the message transfer agent (MTA) is responsible for transferring a mail message when the recipient is not on the same Exchange Server as the sender. The MTA uses the recipient's distinguished name (DN) to determine the location of the server. It then routes the mail message to the other Microsoft Exchange Server's MTA.


NOTE: If the recipient is a distribution list, the list is separated into its component recipients. Each recipient then enters this routing process independently.

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 met. If the time-out limit is met, then the message is returned as a non-deliverable report (NDR).

For routing between different Exchange sites or foreign systems:

1. MTA provides the engine for routing and transferring data to other servers. The routing process commences when an Exchange Server's MTA receives a message. The message can be derived from a user's mailbox, 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.

For example, if the recipient has an SMTP address, the MTA knows how to route it through an Internet Mail connector.

If more than one such connection is available, then one is selected based on routing costs.

4. The MTA sends the message through the selected gateway.

5. 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.


NOTE: 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).

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, such as removing a site connector or site, you are prompted. The routing table will be rebuilt and saved. Routing tables also can be rebuilt manually through a button on the MTA property sheet, although in most cases the routing tables are built dynamically.

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 are groups of users that can be addressed as one by sending one message, such as sending a message addressed to a distribution list named "accounting." All members of that list would receive this message. Lists are established and modified by the administrators and can be replicated across servers and sites allowing recipients with access privileges to see the members and the messages to them.

An individual user can also join appropriate lists from within his or her 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 that is 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.

The process is as follows:

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 in-depth in the site planning section of this book. Some general considerations for situations where alternative routes should be established are:

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 be any number between 0 and 100. A route that costs 0 will always be used first if it is available, and a route that costs 100 will only be used if no other routes are available. Default value 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 Software Spectrum organization, for example, a number of connectors are set up to connect servers in site Los Angeles, California to site Garland, Texas. In the connectors' property sheets, we establish links between the following Exchange servers:

1. A site connector over a T-1 line between servers Garland01 and LosAngeles01. We assign this link a routing cost of 1.

2. A site connector over the same T-1 line between servers GARLAND02 and LOSANGELES02.

We also assign this link a routing cost of 1.

3. An X.400 connector over a private network between server GARLAND02 and LOSANGELES02.

We assign this link a routing cost of 2.

4. Finally, we have one last resort Dynamic RAS X.25 connection between GARLAND01, and LOSANGELES02. 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 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 GARLAND03 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 be able to design an efficient and fault-tolerant system for your enterprise.

Address List and Directory Management

A listing of all available recipients, such as a global address list, completes the corporate directory that contains the entire organization. Because the Global Address List is a list of individuals by name (not cryptic e-mail names), it 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 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.

These sections 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 subprograms 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 principal Exchange operations that carry out directory management tasks:

Directory Replication

Directory replication is the process by which all the 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 Within a Site  Directory replication between servers in the same site is automatic (see Figure 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.

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  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 Figure 2.4). Therefore, public X.400 systems, or even the Internet, can be the transport for your directory replication information between sites.

FIG. 2.3 Directory replication within a site.

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. They are:

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.

Directory Replication Trust or Sensitivity Levels  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.

For example: The trust level for replication from the GARLAND site to the Los Angeles site is set to 50. You can create a user mailbox in GARLAND and set its trust level to 51 and information about that recipient will not be propagated to the Los Angeles site in the directory replication process.

FIG. 2.4 Directory replication between sites.

Directory Replication Tables  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 Seattle01 in a site, and then the directory replication tables are updated to include this server. The next time replication occurs, server Seattle01 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.

Knowledge Consistency Checker

This tool is necessary for adjusting inconsistencies between the Directory and the Public Information Store. The challenge is 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 Systems Administrator needs to run the knowledge consistency checker. This will adjust such irregularities.

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 global or organization-wide address list. The dir-sync process is streamlined by propagating only the changes between systems and not the complete address lists.

Directory Synchronization Architecture  Because Exchange's directory synchronization is based on the Microsoft Mail dir-sync protocol, let us first examine the architecture of that system before proceeding (see Figure 2.5). Microsoft Mail directory synchronization involves the following core components:


NOTE: 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.

FIG. 2.5 Directory synchronization within a Microsoft Mail system.

Exchange server contains a component, the Microsoft directory synchronization agent (DXA) that can function in either the server or the requester role (see Figure 2.6). As with Microsoft 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.


NOTE: Microsoft Mail for AppleTalk networks can participate in directory synchronization with the Exchange Connection Gateway installed on the appropriate Microsoft Mail (AppleTalk) server. This connection includes a requester program that will function exactly as any other Microsoft Mail requester.

Directory Synchronization with Foreign Systems  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 requester and is seen as such by the directory synchronization server.

FIG. 2.6 Exchange directory synchronization agent.

The following is a description of how a foreign requester participates in directory synchronization:

1. The foreign requester 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 DirSync 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 requester.

5. The foreign requester processes the changes into its local address list.

Microsoft Exchange as the DirSync Requestor

The DirSync Requestor will periodically query the Exchange Server directory for any changes made to mailbox recipients directory information. The DirSync component sends an update mail message and a request for MS Mail updates to the MS Mail DirSync server post office.

Exchange as the DirSync Server

The DirSync server processes the incoming update messages from all MS Mail DirSync requestor post offices. It incorporates the updates in the directory as custom recipient objects. An update is also sent for the Exchange Server recipients. This is in response to an update request generated from the MS Mail requestor postoffice. There can only be one DirSync server in a site.


NOTE: The knowledge 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

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:

Expanded Address Book Features

Exchange 5.0 introduced us to Address Book Views. An Address Book View is a customized grouping of Address Book recipients (mailboxes, custom recipients, distribution lists, and public folders) with common attributes. These customized views allow for easier and quicker access to directory information for large or specific groups of users.

With Exchange 5.5, you can still group recipients with certain matching criteria together to create an Address Book View. These groupings now appear in a sub-container under the Address Book View in the Exchange Administrator program. These views will now be displayed in the Show Names from: box in the Outlook Address Book. Whenever an Address Book View is created, you may add up to four sub-container levels. By default, these sub- containers will be grouped according to the specifications of the parent Address Book View. The grouping of the sub-containers may be changed as needed.

Permissions can be set specifying the rights that users or groups have on the Address Book Views. Assigning NT roles is how you delegate permissions to users or groups. These roles are sets of rights that define how much and what type of access a user or group has. These roles can be comprised of the default settings or they can be customized.

Use the Permissions property page to specify user and group roles, access to what users can view, and Lightweight Directory Access Protocol (LDAP) access permissions. The LDAP protocol, which only works with TCP/IP connections, enables LDAP clients to perform searches when they are connected to a directory.

The Messaging Application Programming Interface (MAPI) is the standard interface that Microsoft Exchange server and client components use to communicate with each other. Essentially, it functions as the messaging infrastructure for Microsoft Exchange. MAPI also provides an asynchronous store-and-forward messaging environment that can support a range of applications, including group scheduling and electronic mail (email).

Multiple Offline Address Books can be configured so remote users can obtain information about other users in the organization. While remotely connecting to an Exchange server, users can download offline Address Books that contain lists of recipients specified by you. They also have the option to download only the changes that occurred since the last download.


NOTE: If multiple offline Address Books are required, you must set the offline Address Book server to a server running Exchange Server 5.0 or later. The offline Address Book server is the computer where the offline Address Book files are generated and stored.

The offline Address Books are configured from the Exchange Administrator program. While a user remotely downloads an offline Address Book to their local computer, connections are made to a hidden offline Address Book public folder from which the files are copied. The offline Address Book location can be changed so that the offline Address Book is generated and stored on a server other than the one originally specified. l


Previous chapterNext chapterContents