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.

5 - Designing Exchange Topology

A successful Exchange implementation requires the proper fit into your organization. This chapter outlines an iterative, eight-step process that is applicable for all company sizes. Of course, smaller companies can choose a smaller, more appropriate set of steps, while larger, international companies will probably benefit from the entire process. However, many of the steps will provide value for all types of businesses. In addition, you may use this plan or create your own.

The examples presented may not completely match your environment. It's extremely important you recognize your environment's unique elements, especially when installing and naming the organization, site, primary domain, and server. These names cannot be changed without re-installation.

Your topology will have three layers. In this chapter, explanations of those layers and how they interconnect will be discussed. Specifically, the following topics are covered:

Step 1: Understanding Your Users

The first step in designing your enterprise is effectively soliciting your organization's information requirements from users and management. Once identified, you can then connect those needs to services offered by Exchange. This step illustrates types of services users require and allows you to match those needs to features within Exchange.

Table 5.1

User Needs

For example:

Company Role Needs Exchange Feature
All functions Share and organize information (e-mail, documents, schedules, images, reports, forms); Guarantee message confidentiality; E-mail response when out of the office. Connectivity to other platforms; Standard interface across heterogeneous platforms; Encryption. Out of Office Assistant.
Management Allow secretary to respond to e-mail schedule for others Distribute company report. Send on behalf; Delegate access. Public Folder (BBS).
MIS Support Solution database Email connectivity to Unix systems. Custom electronic forms, public folders. Internet Mail Connector.
Field Sales Remote E-mail access. Remote connectivity.
Manufacturing Connectivity to legacy mail system. MS Mail connector.

Step 2: Knowing Your Network

Your network topology has the greatest influence on Exchange's topology and boundaries. This step identfies the major characteristics of networks and maps some of Exchange's needs to your network's strengths. Contact your network administrator or architect and gather the following bulleted information regarding your network.

Each bulleted section will be described in detail and summarized on a table. If you are already familiar with networking concepts, you can reference the section entitled "Selecting Sites based on Network Type" and summary table before moving to the next step.

Network Types & Links

There are several types of networks and network links today. When you understand the specific characteristics of your network and its associated links, you'll be able to accurately determine if a particular link is adequate for Exchange's needs.

Selecting Sites Based on Network Type

The following tables list all of the network types and links and group them according to bandwidth. As a rule of thumb for the average organization, you'll want to design sites so Exchange servers can communicate over a Type B (Table 5.3) or Type C (Table 5.4) link.

Generally, links having 64 Kbps or less of bandwidth have been classified by this guide as Type A. Type B links range up to 1.544 Mbps. All links with bandwidth over the 1.544 Mbps mark are considered Type C.

In certain cases, you may want to examine a smaller bandwidth link over a larger one if reliability is a factor. For example, some high (Type C) bandwidth links may not be as reliable as the low (Type A) links. Because Exchange servers in the same site need a permanent link to communicate, it may be wiser to choose the more reliable Type A link if messaging volume is light.

Keep in mind this is only one piece of information in selecting a site. You will need to analyze other factors such as the number of users per server, message traffic, the volume of public folder replication, and so on. Review the appropriate sections of this guide to gather all necessary information before making your final site selection.

Table 5.2

Type A Network Links

Type Bandwidth
Dial-up phone lines 2.4 to 57.6 Kilobits per second (Kbps).
Frame Relay 64 to 512 Kbps; Newer implementations go to 1.544 Megabits per second (Mbps).
Fractional T-1 Each channel is 64 Kbps. Additional channels can be added up to 24, which equals a full T-1 line.

Table 5.3

Type B Network Links

Integrated Services Digital Network (ISDN) 64 to 150 Kbps
T-1 1.544 Mbps
Satellite Communication 128 Kbps to 1.544 Mbps
Microwave Communication 1.544 Mbps

Table 5.4

Type C Network Links

ArcNet 2.5 Mbps
T-3 44.148 Mbps
Thin Ethernet 10 Mbps
Thick Ethernet 10 Mbps
Token Ring 4 or 16 Mbps
100BaseT Ethernet (Fast Ethernet) 100 Mbps
100VG-AnyLAN 100 Mbps
Fiber Distributed Data Interface (FDDI) 10 to 100 Mbps
Synchronous Optical Network (SONET) 51.8 Mbps to 2.5 Gigabits per second (Gbps)
Asynchronous Transfer Mode (ATM) 100, 200, 400 Mbps up to 9.6 Gbps

Network Size

Although this may seem obvious, it's important to determine if you have a small or large network. In basic terms, a small network consists of one or two servers, a few clients, and a single domain or site. A large network contains multiple servers, clients, domains, and sites.

Second, it's important to know how quickly your network is growing and to what extent Exchange is being adopted. In many organizations, e-mail is the universal application that everyone seems to want. The need to exchange information, schedule meetings, and "be in the loop" will overcome even the most technically stubborn user. Along the same lines, the quick adoption of e-mail will sometimes force a reluctant organization to grow its network to reach the needs of its users.

Given this information, it's helpful to draw up a low, medium, and high Exchange adoption or migration plan and include its impact on your network's current size. Manage to the medium, but prepare for the high.

Network Bandwidth

Through careful examination of the underlying physical network, you may determine that existing network connections and bandwidths appear adequate to meet your organization's needs. For the purposes of this design guide, network bandwidth is defined as the amount of data per second that can be transmitted over a communication link. However, it is crucial not only to take into account the size of your links, but also to carefully look at the link's utilization. You may find your network has very large and fast connections; however, they may already be inundated with other network traffic which impedes overall performance of the network link. This is called Net Available Bandwidth (NAB). If your NAB falls to the same capacity as a Type A network link, it may be necessary to increase bandwidth in areas of heavy network traffic.

Another area to monitor is traffic bursts. Traffic bursts are short bursts of data transmission that utilize a majority of the bandwidth for short periods of time. You may find that overall, some network links appear to have low overall utilization; however, during peak periods of the day these connections experience traffic bursts that impede performance.

Knowing or predicting network traffic patterns through a network link allows you to determine whether your link has enough NAB to support additional Exchange traffic.

To predict traffic patterns and prevent them from affecting your network, measure the network bandwidth utilization (how close a network link is to full capacity) and total packets per second (how close bridges and routers are to reaching full capacity).

Monitoring network traffic requires specialized tools such as dedicated network monitoring software like Microsoft System Management Server, packet sniffer, or NT's Performance Monitor. For more information on the specific Performance Monitor counters, please refer to the Performance tuning and capacity planning chapter in this book.

Network Protocols

For an effective Exchange topology, you should know which network protocols are used on your network. Exchange offers several types of connectors, but each of them has unique requirements.

For example, configuring a site connector in the Administrator program does not require knowledge or configuration of network transports because all communications happen over Remote Procedure Calls (RPCs). The X.400 connector, on the other hand, requires the existence of TP0/X.25, TP4/CLNP, or TCP/IP.

Another consideration is support for remote clients; e.g., field sales needing remote e-mail access, for which Remote Access Server (RAS) can be used. RAS supports the point-to-point (PPP) protocol that enables any client to use the TCP/IP, IPX, or NetBEUI protocol.

Step 3: Determining a Windows NT Domain Model

This step describes local and global groups, trust relationships, server roles, and domain models. A domain is a grouping of computers and users that eases administration of the computers and user accounts. Windows NT Advanced Servers all share a common user account and security database, thus enabling each user to have a single account that is recognized on all servers in the domain. The domain can also contain other Network Operating Systems (NOSs) such as Lan Manager 2.x and a variety of clients like DOS, Windows, Windows for Workgroups, Windows 95, and NT Workstation.

You can examine the domain models below to create your own domain or examine your existing one. Or you may use Microsoft's Domain Planner Wizard, which is available in the Resource Kit, or call Microsoft.

Once a domain has been created, you will typically need to reinstall NT to make any changes.

Local and Global Groups

Similar in structure to user accounts, groups allow efficient assignment of access privileges to multiple users within the domain. The two classes of group accounts are:

Trust Relationships

Windows NT Server supports the ability for one domain to "trust" another domain, thus giving users of the trusted (or account) domain the ability to act as authorized users on the trusting (or resource) domain. It also allows users in the trusted domain to access resources in the trusting domain without recreating their user ID and other security information a second time. Keep in mind that no matter where network resources are located, users will always log into their home (trusted) domain.

For example, let's say that you own a VCR and your neighbor would like to borrow it and watch a video of Bill Gates speaking about Exchange and the future of messaging technologies. You "trust" your neighbor (a user from a trusted domain) enough to allow him or her entry into your house (resource domain) to use your VCR (a network resource) without making a second key (recreating security information).

In addition, trust is one-way and not transitive. If domain A trusts domain B, it does not imply domain B trusts domain A. This two-way trust must be explicitly established by a domain administrator. Also, if domain A trusts domain B and domain B trusts domain C, it does not imply that domain A trusts domain C.

While trust relationships are very useful capabilities, they also involve the setup and maintenance. It is best to limit trust relationships to a number that satisfies the organization's requirements without creating unnecessary complexity.

If an Exchange site spans multiple domains, there must be a trust relationship in place so that the servers can establish synchronous Remote Procedure Call (RPC) connections.

Server Roles

A Windows NT Server computer can have one of three roles in the domain:

Member servers are not tasked with authenticating users and thus servers are deployed as dedicated file, print, application (e.g. SQL Server), communication (e.g. RAS server) or messaging (e.g. Exchange) machines. Depending on their function, member servers can be connected over all (Type A to Type C) links.

Exchange should be installed on a machine serving either a BDC or member server role. You will not want to place Exchange on your PDC except in special circumstances; e.g., extremely small networks with very light mail volume.

Domain Models

Since Exchange needs a trust relationship to communicate between sites, you'll want to evaluate each domain model based on its implementation of trusts. If a domain model is already in place, evaluate its current trust capacity for an Exchange rollout. To monitor the status of your domain trusts, use the Domain Monitor for Windows NT.

Fig. 5.1

Single domain model.

Fig. 5.2

Single domain with complete trust model.

Fig. 5.3

Single master domain model.

This model is organized into two tiers and combines the features from the second and third domain models already mentioned. There are two or more master domains on tier one. Each master domain has a two-way trust to all other master domains. Thus, a user need be defined only once. Each resource domain on the second tier trusts all master domains with a one-way trust. The second tier domains do not trust each other.

The multiple master domain model scales easily to an organization's growth and works well when a company has a centralized MIS department. In addition, each master domain can support up to 22,000 users each. However, the administrative burden is heavier than the other models due to multiple trust relationships and user accounts dispersed through several master domains.

In figure 5.4, Digital Genesis has organized its first tier domain structure along geographically independent lines of business. It has offices in Boston, Los Angeles, Melbourne, and Athens. This strategy allows each office to administer its own security database while controlling access to the resource domains. Each of the resource domains is organized along functional departments allowing access to specific departmental resources.

Fig. 5.4

Multiple master domain model.

Microsoft Corporation uses this model with one special addition for Exchange. A special, global domain has been defined in the second tier. All Microsoft Exchange servers are located here allowing easy identification of messaging servers and providing consistently applied "global groups" to make server management easier.

Step 4: Selecting Your Sites

This step explains the difference between the critical and discretionary factors for a good Exchange site.

When determining which servers belong to which sites, you must consider two sets of qualifying factors. The first set includes permanent, RPC-compliant connections, plenty of NAB (Net Available Bandwidth), and proper security context. All of these factors must be present to group servers together in one site. The second set of factors are discretionary. They include the fifty server rule, connection cost, connection performance, replication, and company organization. Please refer to the next table for details.

These examples may not completely apply to your environment. Please carefully consider all pertinent factors before selecting a site and choosing site boundaries. Any changes will require a reinstallation.

Table 5.5

Necessary site factors

Permanent, RPC-compliant connection Servers within a site must communicate over a permanent network link that supports synchronous RPC.
Proper security context Within a site, all Exchange servers must run under the same security environment. Since all exchange servers' services use the service account, they must either share the same domain or belong to domains that have the proper trust relationships setup.
NAB (Net Available Bandwidth) The NAB must be equal to or exceed a Type A network link (>64 Kbps). In certain cases, you may want to examine a smaller bandwidth link over a larger one if reliability is a factor. For example, some high (Type C) bandwidth links may not be as reliable as the low (Type A) links. Because Exchange servers in the same site need a permanent link to communicate, it may be wiser to choose the more reliable, Type A link if messaging volume is light.

Table 5.6

Discretionary Site Factors

Fifty server rule As a rule of thumb, limit your site to contain no more than fifty servers apiece.
Consider large sites Since Exchange will automatically replicate all changes within a site, consider making your site as large as possible to ease the administrative burden. Remember: It is easier to split than to merge.
Directory Replication Since network bandwidth is is higher within a site than between separate sites, replication will automatically occur more often inside sites. If you wish to manually control replication, place the servers in separate sites.
Bandwidth If you have a group of servers connected at the same bandwidth, you should consider grouping those servers together in a common site. Place servers connected at a slower bandwidth in separate sites.
Company organization Naturally, you'll want to group users in the same department or functional unit together. This provides a more effective use of network and Exchange resources.

Step 5: Selecting a Mapping Strategy

Now that network structure has been outlined and you've identified your critical site factors, it's time to choose a mapping strategy. This step describes the major site strategies, basing them on several domain and network examples.

During Exchange's setup, the install program creates several services that start and run based on the context of a user account called the service account. This account is created on the first computer within a site. Other computers within the site are validated by the service account and thus are given access to Exchange's services. All Exchanges computers within the same site must use the same service account.

If you have one domain and one site, you'll want service accounts created in the only domain. For multiple domains within a single site, create the service account in the account domain or whichever domain is handling your administrative domain functions. In a master or multiple-master domain model, the master domain would contain the service account (see figure 5.10). In a single domain with complete trust model, any domain could contain the service account because it's accessible to all the other domains (see figure 5.6).

If two sites are in separate domains, one service account can be used for both domains if they trust each other. If they do not, you can use a site connector to serve as a link. In this case you must set up the site connector to connect to the untrusted domain's service account. For example, let's say Exchange Site 1 uses a service account called Service1 and Exchange Site 2 uses Service2. Site 2 must connect to Site 1 with Service1's account name and password. Likewise, Site 1 connects to Site 2 with Service2 (see figure 5.12).

When laying a site framework over your existing network foundation, consider the following strategies:

Review the following two tables to determine the best strategy for your organization.

Table 5.7

Effective site mapping.

Domain Model Mapping Strategy Description
Single One to One All servers within the site have access to the service account (see fig. 5.5).

Fig. 5.5

Single domain using a one-to-one strategy.

Single with complete trust One to One All domains and servers can access the service account (see fig. 5.6).

Fig. 5.6

Single domain with complete trust using a one-to-one strategy.

Two Single Domain Models with no trusts One to One A server in untrusted domain A can access the service account in the domain B via properly configured site connector (see fig. 5.7).

Fig. 5.7

Two single domain models with no trusts using a one-to-one strategy.

Single Many to One Each site can use its own service account or the service accounts in the other site via a properly configured site connector (see fig. 5.8).

Fig. 5.8

Single domain using a many-to-one strategy.

Single Master One to Many With the proper trusts in place, servers in domain B and C can use the service account because it's located in master domain A (see fig. 5.9).

Fig. 5.9

Single master using a one-to-many strategy.

Multiple Master One to Many As with the previous mapping, the trust relationships allow all first and second tier servers to access the service account in master domain B (see fig. 5.10).

Fig. 5.10

Multiple master using a one-to-many strategy.

Two Single Master models with no trusts One to Many The trust relationships allow the servers in each second tier domain (B, C, E, & F) to access the service account defined in their local master domains (A and D). With a site connector, both untrusted domains' service accounts are linked together (see fig. 5.11).

Fig. 5.11

Two single master models with no trusts using a one-to-many strategy.

Step 6: Selecting a Naming Strategy

This step will describe the format, use, and restrictions of e-mail addresses within Exchange.

Just as external messaging standards are necessary for different mail systems to communicate and share information, internal naming standards are just as vital to building a well-run, easily administered mail system. As with many items in this chapter, you must thoroughly plan before implementing a naming strategy because some changes will require reinstallation.

There are three elements of a sound naming strategy:

Keep these elements in mind as you progress through the different mail systems and standards below.

Organization Name

An organization name should comprise your entire company. When choosing an organization name, be aware that it can be used to generate e-mail addresses for non-Exchange systems. Some system standards restrict the number of characters in an address. In fact, Setup will remove unrecognized characters for the Internet and MS Mail (PC) addresses. The organization name will also be part of the directory names of all directory objects such as mailboxes, public folders, and distribution lists. Organization names can contain up to 64 characters, must be unique, and cannot be changed.

Site Names

A site name can be based on function (sales, distribution), geography (countries, regions, cities), or physical location (building). Site names can contain up to 64 characters, must be unique, and cannot be changed. In addition, they are used by Exchange when generating non-Exchange e-mail addresses.

Server Names

A network uses the server name to identify a particular NT machine. Server names must be unique, can contain up to 15 characters, and cannot include any of the following characters: bullet (¸), currency sign (¤), broken vertical bar or pipe (|), section sign (§), or end of paragraph sign (¶). In addition, do not put spaces in the server names if logon scripts are part of your environment.

Mailbox Names

A mailbox name should be easy to identify and similar in form to your organization's internal phone lists. Since mailbox names are listed in Exchange's address book, you may want to create mailbox names that sort properly when displayed. Review the following table for a breakdown of mailbox names.

Table 5.9

Guidelines and restrictions for mailbox names

Field Guideline Restrictions
First Name User's first name Up to 16 characters, can be changed.
Last Name User's last name Up to 40 characters, can be changed.
Alias Name To route messages to non-Exchange systems, an alias name is used. Identify the external mail systems within your organization; e.g., PROFS, MHS, MCI Mail, AT&T Mail, and determine their unique requirements; e.g., PROFS can accept up to eight characters for an e-mail address. For best results, the alias name should bear a recognizable resemblance to the original name; e.g., Kent Smith becomes KentSm.
Display Name Base this name on how you want it displayed in the Address book and Administrator window. Be sure to consistently use the same format for all names; e.g., Last Name, First Name. Up to 256 characters, can be changed.
Directory Name Exchange uses this name to route mail messages. This is an internal name and is not displayed to users or administrators. Exchange will set this to the first alias name specified, but you can use another. Up to 64 characters, must be unique, can't be changed.

E-mail Addresses

When Exchange communicates with other (or foreign) mail systems, like the Internet, it must have a valid address format the other mail system understands. A foreign user whose address exists both on a foreign network as well as in the Exchange directory is referred to as a custom recipient. Exchange recipients (including mailboxes, custom recipients, distribution lists, and public folders) that have addresses on foreign mail systems are known as foreign e-mail addresses.

Exchange automatically generates an e-mail address for the following mail systems: X.500, X.400, MS Mail (PC), and the Internet (SMTP). Exchange does this to provide the widest possible compatibility with other messaging systems. Keep in mind that other addresses may be generated if there is a PROFS or another third-party gateway installed.

X.500 Addresses

X.500 was designed to provide an international standard for enterprise-wide directory service access. The 1988 X.500 directory service guidelines form the basis of Exchange's directory service. It is in the directory that Exchange stores all X.500 object classes in an X.500 schema.

The directory objects are organized in a hierarchical structure known as the Directory Information Tree (DIT) and they are identified by a unique item called a distinguished name (see example).

The table below shows how the X.500 object name maps to an Exchange object.

Table 5.10

Mapping X.500 names to Exchange objects

X.500 name Attribute Exchange Server object
Country c= Country
Organization o= Organization
Organizational Unit ou= Site Name
Common Name cn= Exchange Server Recipient Container
Common Name cn= Exchange Server Recipient or directory name

For example, the distinguished name for Kent Smith who has a mailbox in Los Angeles within the Digital Genesis organization would be o=DG/ou=LosAngeles/cn=recipients/cn=KentSm. When you remove the naming labels, you receive the form that Exchange uses: DG/LosAngeles/recipients/KentSm.

Since X.500 doesn't support all object classes and attributes, Exchange also includes support for titles, organization charting information (who reports to whom in an organization), additional phone numbers, arbitrary attributes created by the administrator, and alternate recipients.

X.400 Addresses

X.400 is a widely recognized and accepted international standard by the messaging industry. Exchange's compliance with the X.400 standard is important for organizations that want to use e-mail with heterogeneous mail systems as well as those who want to communicate with external companies via public carriers.

X.400 addresses can contain all of the upper and lowercase letters, all numbers (0-9), a space, left and right parenthesis, the plus and equal sign, the comma and the period, the hyphen and the forward slash or solidus (/), and the colon and question mark. In addition, X.400 addresses can contain the following attributes which are listed in hierarchical order:

Table 5.11

X.400 Attributes

Description Attribute
Country c=
Administrative Management Domain (ADMD) a=
Private Management Domain (PRMD) (Exchange organization) p=
Organization (Exchange server site) o=
Organizational units ou1=;ou2=;ou3=; and ou4=;
Common name cn=
Generation qualifier q=
Initials i=
Surname (last name) s=
Given name (first name) g=

For example, a valid X.400 address for Kent Smith who has a mailbox in Los Angeles within the Digital Genesis organization would be:


This address also represents the minimum information you need to receive e-mail from someone else.

Microsoft Mail Addresses

If you will connect to Microsoft Mail for PC Networks or Microsoft Mail for AppleTalk Networks systems, character restrictions are:

A valid MS Mail address for Kent Smith who has a mailbox in Los Angeles within the Digital Genesis organization would be DG/LSANGLES/KENTSM. For more information on connecting to MS Mail, please see the "Planning Connection to MS Mail" section within this book. For information on migration from MS Mail to Exchange, please see "Migration from MS Mail."

SMTP Addresses

Exchange's SMTP connector is a dependable way to exchange mail transparently with SMTP users as well as with Mail users on other LANs over an SMTP backbone. It also enables Mail users to easily access mail networks such as UUCP, BITNET, and Internet.

When communicating with the Internet or other SMTP systems, look at their particular character or addressing limitations. In general, SMTP addresses can include all upper and lowercase letters (A-Z), all numbers (0-9), and the hyphen (-). However, spaces are not permitted.

A valid SMTP address for Kent Smith who has a mailbox in Los Angeles within the Digital Genesis organization would be KENTSM@LOS-ANGELES.DG.COM.

External System Addresses

If your organization has other mail systems (PROFS, SNADS, and so on), you will want to examine any conditions they place on usable characters and addressing. This way you can properly configure the Alias Name field (see the Mailbox name section) for your particular mail system.

Step 7: Linking Your Sites

Now that you have your sites laid out and the proper e-mail address to share information, the next question is: How do I link my sites? This step explains the methods you can use to link your sites, and discusses the pros and cons of different connectors and how this affects the Microsoft Exchange Server.

Site Connector

The site connector is the most efficient way to connect two sites if they are on the same logical LAN. It also offers the greatest performance because it uses RPC for communication.

Listed on the following table are the pros and cons when using the site connector.

Table 5.11

Pros and cons of using the site connector

Pros Cons
Provides automatic load balancing and fault tolerance. Requires a permanent, high bandwidth connection of at least 56 Kbps or higher (Type B or C link).
Easiest site connection option to configure and manage since a network transport is not involved. Transmits more frequently other site connection options. If you are charged for traffic; e.g., frame relay or packet network, you may want to examine another site connection option.
Messages don't need to be translated between sites. Cannot control message size.
Configures both sides of the connection at the same time. Cannot schedule connections.
Messages take fewer hops to reach their destination. Can overwhelm network link when multiple Exchange servers use the same link.

RAS Connector

The RAS connector is useful where there is no permanent LAN or WAN connection, but you can link up to another site remotely. This is usually the case with small branch offices where permanent links are expensive or not available.

You can also use the RAS Connector to provide a redundant connection for sites using one of the other site connection options. For example, you can configure the RAS connector to handle message routing in cases where the primary connector link becomes unavailable.

Table 5.12 reveals the pros and cons when using the RAS connector.

Table 5.12

Pros and cons of using the RAS connector

Pros Cons
Connections can be scheduled. Transfer is limited by speed of modem.
Can link sites over an asynchronous, periodic connection. Link saturation is more likely since all site message traffic is flowing through one dial-up link.

X.400 Connector

The X.400 connector is useful where you are connecting to other sites via slow network links or on private or public packet networks. In addition, the X.400 connector provides compatibility with 1984, 1988, and future MTAs. This means you can communicate via X.400 with companies that are at different stages of implementing X.400 technology.

Microsoft Exchange Server supports X.400 over these OSI transports: TP0/X.25, TP4/(CLNP), and TP0/RFC 1006 to TCP/IP. After configuring to a transport, Exchange routes the message with standard X.400 messaging protocols.

Table 5.13 reveals the pros and cons when using the X.400 connector.

Table 5.13

Pros and cons of using the X.400 connector

Pros Cons
Connects to foreign, non-Exchange systems that support X.400 standard. Must configure network transports.
Can schedule connections. Bottlenecks may appear since all mail traffic is flowing through one central server.
Can determine messaging routing through Exchange's topology. Must verify that the existing network infrastructure (bridges, routers) can support the required protocols.
Message size can be controlled.

Internet Mail Connector

Although the Internet mail connector can link two sites, its main purpose is to connect to the Internet using the SMTP (Simple Mail Transfer Protocol). Most Unix systems and any mail systems supporting plain text-RFC 822, MIME (Multipurpose Internet Mail Extensions)-RFC 1521, MS Mail server format, or Uuencode/Uudecode standards can be linked, too.

Listed on the table below are the benefits and drawbacks when using the Internet mail connector.

Table 5.14

Pros and cons of using the Internet mail connector

Pros Cons
Can forward all mail to a single host. Must configure a network transport (TCP/IP).
Can be configured to accept or reject host connections. Connections cannot be scheduled.
Can be configured to receive inbound or outbound messages or both.

Microsoft Mail Connector

The Microsoft Mail connector provides seamless connectivity to Microsoft Mail for PC Networks, Microsoft Mail for AppleTalk® Networks, and Microsoft Mail for PC Networks gateways (PROFS, SNADS, Netware, MHS, and FAX). It uses a "shadow" post office that is structured like a Microsoft Mail 3.x post office.

The Microsoft Mail connector runs over the following transports: TCP/IP, IPX/SPX, NetBEUI, X.25, Asynchronous, and Remote Access Service (RAS).

Listed on the table below are the benefits and drawbacks when using the Microsoft Mail connector.

Table 5.15

Pros and cons of using the Microsoft Mail connector

Pros Cons
Can connect directly to another Microsoft Mail post office, allowing you to replace it without additional software. In most cases, a network transport must be configured.
Allows you to migrate your MS Mail network in phases instead of all at once. Must verify that the existing network infrastructure (bridges, routers) can support the required protocols.

Step 8: Reviewing your Plan

Congratulations! You have all the necessary pieces to build a successful Exchange Topology plan that meets your and your organization's needs.

Keep in mind that every time you expand your network or Exchange site, you will need to enter a design phase again to create and implement a plan. Prepare for it by recording any important changes that may occur in the areas described.

From Here…

This chapter has provided a model for designing an Exchange Topology. Depending on your current phase of implementation, you may want to proceed to the following chapters:

Previous Chapter <-- Table of Contents --> Next Chapter

QUE Home Page

For technical support for our books and software contact

Copyright ©1996, Que Corporation