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:

• Understanding your Users' and Organization's needs
• Understanding your network type and operating structure
• Understanding Exchange sites and e-mail addresses
• Combining all the layers into an Exchange Topology

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:

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.

• Types and links
• Size
• Bandwidth
• Protocols

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.

• Dial-up phone lines are comprised of copper wire mainly used for single users to remotely connect to existing LANs and WANs. They provide an inexpensive, but periodic connection.
• X.25 lines are permanent, leased lines proving a connection between LAN segments; i.e., WANs. X.25 is an international standard for packet communication over public data networks.
• Frame Relay is similar to X.25, but provides better performance than X.25 due to decreased overhead. Frame relay is a method to send packets over private and public data networks to connect LAN segments; i.e., WANs.
• Fractional T-1 - Since T-1 lines can be divided into 24 separate lines or channels, fractional T-1 lines make connecting LAN segments; i.e., WANs, more affordable than using a full T-1. Bandwidth can be expanded all the way to a full T-1 by adding additional channels.
• Integrated Services Digital Network (ISDN) is digital communication over dial-up lines using the ISDN standard. ISDN eliminates the need for a voice digitizer (analog to digital conversion unit) in the telephone company's central office, thus allowing faster throughput than a modem over dial-up phone lines. Typically, ISDN is used by personal computer users at home and some LAN segment connections.
• T-1 is a digital link carrying voice or data transmissions and is usually used to connect LAN segments. It also can be used to create private data and voice networks within a company.
• Satellite Communication is a wireless communication scheme that provides global data access. Typically used to interconnect LAN spread over a wide, geographic area and/or used to provide a redundant link when land-based lines are unavailable.
• Microwave Communication is a wireless link that uses microwaves to connect LANs that are typically on a business campus or industrial park.
• ArcNet networks utilize a star or bus topology with a token-passing access scheme over coaxial cable (RG-62 or RG-59).
• T-3 is similar to T-1, but has a higher bandwidth equal to 28 T-1 lines. Each of these channels can be divided and grouped into smaller portions. Typically, T-3s are used as high-speed WAN links.
• Thin Ethernet uses a linear bus topology with Carrier Sense Multiple Access with Collision Detection (CSMA/CD) over thin coaxial (10Base2) or twisted-pair (10BaseT) cable.
• Thick Ethernet - Same topology and access method as thin Ethernet, but over thick coaxial cable (10Base5).
• On a Token Ring network, all the computers are connected physically as a star and electrically as a ring. It uses a token-passing access scheme over shielded or unshielded twisted pair (UTP) wire.
• 100BaseT Ethernet (Fast Ethernet) uses the CSMA-CD communication scheme and comes in two flavors (100BaseT4 and 100BaseTX) depending on the type of UTP cable in place. Stations connect to 100BaseT hubs in the same way they connect to 10BaseT hubs. Typically, Fast Ethernet is used in LANs and WANs.
• 100VG-AnyLAN, proposed by IBM and Hewlett-Packard, 100VG-AnyLAN uses the same Ethernet frame format but replaces CSMA-CD with a deterministic protocol called the Demand Priority Access Method (DPAM). DPAM is conceptually similar to the token-passing method in Token Ring networks. 100VG-AnyLAN is used in the same types of networks and linking as Fast Ethernet.
• Fiber Distributed Data Interface (FDDI) - Communication over a fiber optic cable usually uses the FDDI standard. This standard is similar to the token-passing technique of Token Ring but operates at a much higher speed. Typically, FDDI is used as a backbone interconnecting lower speed LAN; e.g., Ethernet or Token Ring; connections to WANs; or to provide direct, high-speed attachments for routers and hosts.
• Synchronous Optical Network (SONET) is a standard for high-speed communications over fiber optic cable. It is a network transport (like Ethernet) and has a bandwidth equivalent to 48 T-3 lines. Like T-3, SONETis used to connect WANs together.
• Asynchronous Transfer Mode (ATM), from the standardization process of International Telecommunication Union (ITU) comes ATM, which was designed to handle voice, video, and data transmission over high-speed fiber optic links. ATM's strength is that it can transport multiple data streams on virtual circuits operating at different data rates. Initially used as a LAN backbone (like FDDI), ATM is also being used to connect WANs over fiber optic cable. ATM can use fractional T-1, T-1, T-3, and SONET as its physical medium.

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

Table 5.3

Type B Network Links

Table 5.4

Type C Network Links

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:

• Local groups, which are not accessible outside the home domain, but may have global groups from the home as well as other domains as members.
• Global groups, which contain users from the home domain and can be assigned access to resources within the home domain as well as away domains.

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:

• Primary domain controller (PDC)
• The PDC maintains the original user accounts database. This database contains all the security information for the domain. The PDC should be physically attached to the most central and high-speed network segment possible. Since the PDC authenticates users and receives updates to the user accounts database, it should never be on an unreliable or periodic network link, such as a wireless network or dial-up line.
• Backup domain controller (BDC)
• The BDCs receive a copy of the user accounts database from the PDC via replication. BDCs also authenticate users and can change their role to a PDC in case of PDC failure.
• If a BDC is replicating over a slow WAN link (less than 128 Kbps) and the PDC and BDC are at least NT Server version 3.5, you may want to examine the BDCs Replication Governor registry setting. This parameter tunes the load placed onto a WAN from replicating the user accounts database.
• Member server

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.

• Single domain model
• This model doesn't use trust relationships. It contains a single PDC and can contain multiple BDCs and member servers. It's the easiest model to manage since user accounts and all groups (global & local) are centralized. Unfortunately, performance may suffer as the size grows towards the domain's capacity (around 22,000 users)(see fig. 5.1).

Fig. 5.1

Single domain model.

• Single domain with complete trust model
• Here, each domain has a two-way trust relationship with every other domain in the enterprise. The total number of trust relationships that must be set up is equal to N*(N-1), where N is the number of domains. Each domain has its own user accounts and global groups.
• For organizations that use distributed management or function without a central MIS, this model provides the best fit. Each department within a domain can effectively manage its home domain as well as other domains. However, as the network grows so does the administrative burden of adding additional domains and managing multiple trusts.
• In figure 5.2, Digital Genesis has no central MIS and thus allows each functional department to manage its respective users and groups.

Fig. 5.2

Single domain with complete trust model.

• Single master domain model
• In this model, there are several domains but one serves as the central or master domain. All the other domains are resource domains that trust the master domain via a one-way trust. The resource domains do not trust each other. All user accounts and global groups are contained in the master domain, while the resource domains contain file, print, communication, and SQL servers as well as local groups.
• Due to its centralized nature, this model allows a network administrator to manage all the organization's user ids from one domain, while the local administrators of each resource domain can manage their home domains. One disadvantage is that the single master domain can support networks of only up to 22,000 users and thus may not support explosive growth within an organization.
• In figure 5.3, IBT/Digital Genesis Inc. has centralized its user accounts and global groups within one master domain while organizing its resource domain along geographical locations.

Fig. 5.3

Single master domain model.

• Multiple 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

Table 5.6

Discretionary Site Factors

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:

• One-to-One Strategy
• For a small organization, consider a one site to one domain approach. This means there is one site within every untrusted domain. A one to one strategy is similar to the single domain model. One advantage with the one to one approach is that it's one of the easiest to configure and manage. In addition, everything is centralized in one site and one domain. However, it is difficult to scale as you approach 50 servers per site unless you create additional domains/sites and use site connectors. Usually, as an organization grows or plans to rapidly grow, their mapping strategy moves towards a one to many technique.
• Many-to-One Strategy
• Another strategy you may consider is mapping many sites into one domain. This is useful when you want to segment a large network due to the fifty server rule or to group servers with similar bandwidths together. Although easy to configure, this strategy may have more management overhead if you choose to connect the sites via one of Exchange's site connectors.
• One-to-Many Strategy
• Larger organizations should consider moving to a one site for many domains strategy. This is equivalent to moving from a single domain to a single master or from a single master to a multiple master domain model. Since Exchange will replicate all changes to properly trusted domains, a one to many strategy is fairly easy to administer and removes the overhead of managing site connectors between untrusted domains. Still, you're limited to around fifty servers per site to maintain an effective Exchange system.
• Overall:
• It is not necessary to map all sites to all domains.
• It is best to consider a large site over a small one when mapping sites to domains.
• Only domains containing the Exchange service account need to be mapped.

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

Table 5.7

Effective site mapping.

Fig. 5.5

Single domain using a one-to-one strategy.

Fig. 5.6

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

Fig. 5.7

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

Fig. 5.8

Single domain using a many-to-one strategy.

Fig. 5.9

Single master using a one-to-many strategy.

Fig. 5.10

Multiple master using a one-to-many strategy.

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:

• It is not affected by a company's natural growth and reorganization. For example, base your naming conventions on geographic location, building numbers, and permanent floor locations. Avoid choosing company attributes that may change over time.
• It is easy to add additional items like sites, servers, users, and other directory objects.
• It is easy to use and administer the system.

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

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

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

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

g=Kent;s=Smith;o=Los-Angeles;p=dg;a=mci;c=us;

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:

• Microsoft Mail network name 10
• Post office name 8
• Mailbox name 8

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

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

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

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

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

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:

• Chapter 7, "Migrating to Microsoft Mail Systems," addresses the challenges and provides solutions for moving your MS Mail network to Exchange.
• Chapter 9, "Installing Exchange Server," will provide step by step instructions on installing Exchange in your environment.
• Chapter 27, "Installing and Configuring Exchange Clients," will lead you through the installation steps to set up Exchange clients.