Special Edition Microsoft Exchange Server 5.5

Previous chapterNext chapterContents


- 5 -
Designing Exchange Topology



A successful Exchange implementation requires planning for a proper fit into your organization. This chapter outlines an iterative, ten-step process that is scalable for all company sizes. Of course, smaller companies can choose a smaller, more appropriate set of steps, while larger, international companies probably benefit from the entire process. Many of the steps, however, are valuable for all types of businesses. In addition, you may use this plan or create your own strategy based on another planning strategy.


NOTE: The examples presented may not completely match your environment. Make sure that you recognize your environment's unique elements, especially when installing and naming the organization, site, primary domain, and server. You cannot change these names without reinstallation.

Step 1  Understanding Your Users

The first step in designing your enterprise is identifying your users' messaging needs. After you identify their needs, you can then match those needs to Exchange's features. This information also guides you when examining hardware purchases, training procedures, network upgrades (due to increased traffic), increased support needs, and total cost of ownership. Additionally, by understanding your users' needs, you can develop solutions on top of the Exchange platform that further leverage your organization's investment and add value to the user population. An example of this is to use Exchange as a key component of a knowledge management solution. See Table 5.1 for an example of how one company met their messaging needs with Exchange.

Table 5.1  User Needs

Company Role Needs Exchange Function
All departments Connectivity to other platforms standard interface across heterogeneous desktops. Web Outlook View. Share and organize information (email,documents, schedules, images, reports, form).
Guarantee message confidentiality even when traveling. Encryption and Person-to-Person key exchange. E-mail response.
E-mail response when out of the office. Out of Office Assistant.
Reserve conference room. Delegate feature.
Management Enable secretary to respond to email received by manager. Send on behalf; delegate access
Distribute company report Custom Solutions database. Public folder (like an electronic bulletin board) Help Desk Solutions database
Email connectivity to Internet. Internet Mail Service(IMS).
Field Sales Remote Email access. Remote connectivity; Web Outlook View.
Legal Connectivity to existing mail system. MS Mail and Lotus cc: Connector.
Manufacturing Migration from legacy mail system (e.g., PROFS). Source extractor and migration tools.
Engineering Research latest technical developments. NNTP to retrieve and post to live Internet newsgroups.

The following section presents one of the many ways in which organizations of any size can take advantage of Exchange as a true solutions platform. The key point is that when planning for Exchange, you must understand your users needs, and you must leverage Exchange to provide value to your organization.

Exchange as a Component of a Knowledge Management Solution

Knowledge is the only enduring asset of an organization. The ability to capture and manage that knowledge is critical to the survival and success of any corporation. Historically, some organizations have done an effective job of capturing and managing business related data and information. When it comes to knowledge management, however, very few organizations have developed a strategy or dedicated the resources to provide an effective mechanism through which to capture and to leverage corporate knowledge, which can help a company gain a competitive advantage. Knowledge and knowledge management are quickly emerging as the next paradigm shift in computing following data processing, 1945-1965, and information management, 1966-1995.

Exchange Server provides robust functionality, which organizations can leverage as a key component of an enterprise-wide knowledge management architecture. The following sections provide definitions of knowledge and knowledge management, as well as point out how you can use Exchange as a part of a knowledge management system.

Introduction to Knowledge and Knowledge Management  Before we can define knowledge management, it is important to define what is meant by knowledge. Mr. Denham Grey (a subject matter expert) defines knowledge, as follows:

Knowledge is the full utilization of information and data, coupled with the potential of people's skills, competencies, ideas, intuitions, commitments and motivations. In today's economy, knowledge is people, money, leverage, learning, flexibility, power, and competitive advantage. Knowledge is more relevant to sustained business than capital, labor or land. Nevertheless, it remains the most neglected asset. It is more than justified true belief and is essential for action, performance and adoption. Knowledge provides the ability to respond to novel situations. A holistic view considers knowledge to be present in ideas, judgments, talents, root causes, relationships, perspectives and concepts. Knowledge is stored in the individual brain or encoded in organizational processes, documents, products, services, facilities and systems. Knowledge is the basis for, and the driver of, our post-industrial economy. Knowledge is the result of learning, which provides the only sustainable competitive advantage. Knowledge is action, focused innovation, pooled expertise, special relationships and alliances. Knowledge is value-added behavior and activities. For knowledge to be of value it must be focused, current, tested and shared.

The following key concepts in Mr. Denham's definition of knowledge are important to emphasize:

Understanding the Value of Knowledge  Large amounts of knowledge enter and exit organizations on a daily basis. This occurs primarily by hiring new employees and through staff attrition. Many organizations may not fully appreciate the significant amounts of knowledge that the organization never uses on a regular basis. That is, many organizations do not fully understand the magnitude of the opportunity cost they incur by not leveraging existing knowledge. Before organizations consider exciting new ways to create new knowledge, they should examine the knowledge that currently exists, but they currently have not tapped. After they identify this knowledge, they should use the knowledge to achieve improved competitive advantage. After all, if a primary role of a manager is to optimize the use of resources, the manager should be very interested in a key resource that already exists and is underutilized. Many managers don't give the proper level of importance to the most important asset in the organization today--knowledge.

Many organizations, for example, invest more in managing and maintaining a fleet of cars than they invest in leveraging internal knowledge. If nothing else motivates organizations to begin planning for the implementation of a knowledge management architecture, at least they must understand that if their competitors are not currently implementing knowledge management solutions, they soon will A recent survey performed by the Delphi Group indicates that 28 percent of the companies surveyed are currently using some form of knowledge management solution, and the figure is expected to leap to 77 percent within the next two years. In fact, 85 percent of respondents see knowledge management as an important or essential new focus in their efforts to become more innovative and responsive to turbulent market forces (Source: The Delphi Group, 1997 Knowledge Management Insight Research). In summary, the Delphi Group believes that knowledge management will define organizational IT investments over the next decade.

Knowledge Management  As the term implies, knowledge management means leveraging corporate knowledge to provide a competitive edge. To truly understand the concept, you must better understand the concept of knowledge in context. "Knowledge is not the same thing as data," says Carla O'Dell, president of American Productivity & Quality Center, an industry research consortium in Houston. In late 1997, American Productivity will release a study of the "knowledge management" practices of 23 companies. American Productivity concludes that companies manage the knowledge in their organizations best by using information technology as a platform to support a combination of IT and non-IT-based information-sharing practices. Knowledge management is the process by which companies can assess, reflect on, share, and utilize individual learning and experience in order to foster enhanced individual knowledge and, thus, organizational value.

You should understand that knowledge management is inherently a collaborative activity and the opportunity for knowledge management among groups of four or more can be realized only with collaborative technologies in some form. Exchange Server can serve as a platform to enable this type of solution. These technologies may be as simple as threaded email discussions or as sophisticated as workflow knowledge bases. Additionally, collaborative technologies alone do not enable knowledge management. Knowledge must be relevant to work and overall business goals and must be accessible in the right forms and at the right time.

Principles of Knowledge Management  Knowledge management is designed to support and enhance the human communication and knowledge sharing processes. Knowledge management is a team-enabling technology, which requires that organizations develop a strong and open team communications and knowledge sharing culture and support a coaching and facilitative management style. Knowledge management is the primary competence for the knowledge-based organizations today, and knowledge technology is the primary enabler. The following five knowledge management principles underpin the knowledge organization:

The implementation of an effective knowledge management solution within any organization depends on the existence of the following critical success factors:

Implementing an Effective Knowledge Management System

The implementation of an effective knowledge management system requires that organizations deploy tools and procedures to provide the following functionality:

In summary, global knowledge management possibilities now exist to transform national and international information-based organizations into global teams of knowledge-based workers. Large, dispersed, and international organizations can now make operations global and better operate as a single operation. Small organizations with global vision now have the technology available to grow their organization to trade globally--faster than ever before.

Mapping Exchange Functionality to Knowledge Management

The robust messaging and collaborative capabilities of Exchange Server make it an attractive platform on top of which organizations can implement specific components of their enterprise-wide knowledge management solution. The following are some of the specific Exchange Server features which facilitate knowledge management:

If you review the key functionality components of an effective knowledge management system from the preceding list, you can identify those areas where Exchange Server can provide a solution.

Knowledge Creation  You can create Exchange folder-based forms to capture corporate knowledge. The form design and functionality varies depending on the type of knowledge you need to capture. You can develop the following four main types of forms:

Knowledge Retention  Exchange Server provides a robust, secure, and scaleable data store for the retention of key organizational information. The nature of the information to be captured helps determine whether it should reside in a public folder or in a relational database.

Knowledge Sharing  Exchange Server's public folders enable the easy sharing of information. Additionally, Exchange Server's capability to replicate public folders enables organizations to distribute knowledge to geographically dispersed users.

Knowledge Accounting  In this area, Exchange Server's functionality provide only limited capabilities. Through the Exchange admin you can determine the amount of disk space that any given public folder utilizes. Additionally, by using Crystal Reports for BackOffice, you can define the utilization load and the frequency and rate of access to the folder. From an accounting perspective, you have no simple way to perform charge back operations.

Knowledge Association  Knowledge association is perhaps one of the most complex and important aspects of creating a true knowledge management system. True knowledge is the more complex task of making connections among information. Consider how much tougher it is to create elaborate systems that contain public folder entries with links to other information sources or documents on the World Wide Web. These links form the essence of the navigation through a knowledge base, yet they also compound the problem of navigating because they significantly increase the possible interpretations of any single document. Cataloguing information previously meant searching and finding a set of documents. With knowledge links, any single document can lead to an indeterminate number of other links, making navigation nearly impossible. In addition, the links themselves must change, as must the documents, if you want to keep the knowledge base up-to-date. Not only is the job of the knowledge user made more difficult, but the maintenance of the knowledge requires additional resources. To resolve the problem, you must rely on intelligent inventory systems that catalog knowledge as it is needed and not in advance. Again, recall that you are not categorizing information that you can store in predefined categories and standard hierarchies, but you are organizing knowledge that is changing continually (excerpts from Corporate Instinct: Building a Knowing Enterprise for the 21st Century copyright 1997, Thomas M. Koulopoulos).

The knowledge association aspect of knowledge management is technically very complex and at some point requires that organizations consider the implementation of artificial intelligence technologies, such as case based reasoning (CBR). Exchange Server does not provide any tools for automating the process of information association. Artificial intelligence technologies offer a great opportunity for third party developers and integration services organizations.

Knowledge Leveraging  Exchange Server's functionality provides organizations with the capability to leverage in several different ways the information contained in the system. Exchange enables users to access its data stores via the Outlook or Exchange Clients, via a web browser (HTML), or via an IMAP client. The flexibility meets most organizations' information access needs.

Step 2  Knowing Your Network

Your network topology has the greatest influence on Exchange's design. This step identifies 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 section is described in detail and summarized in a table. If you are already familiar with networking concepts, you can reference the section "Selecting Sites Based on Network Type" and Table 5.2, 5.3, and 5.4 before moving to the next step.

Network Types and Links

Several types of networks and network links exist today. After understanding the Exchange features your company needs, you can determine whether your existing network and links are sufficient. For example, one dial-up phone line probably isn't sufficient to move messages for thousands of users throughout your company.

The following bulleted items present a brief description of the most common types of communications links that you can use for connectivity of an Exchange system:

Selecting Sites Based on Network Type

Generally, links that have 64Kbps or less of bandwidth are classified by this book as class A (see Table 5.2). Class B links range up to 1.544Mbps. All links with bandwidth over the 1.544Mbps mark are considered class C.

As a rule of thumb for the average organization, you want to design sites so Exchange servers can communicate over a class B (see Table 5.3) or better (for class C see Table 5.4) network links.

Table 5.2  Class A Network Links

Type Bandwidth
Dial-up phone lines 2.4 to 57.6 Kilobits per second (Kbps).
X.25 19.2, 56, and 64Kbps.
Frame Relay 64 to 512Kbps; newer implementations go to 1.544 Megabits per second (Mbps). At higher speeds, frame relay qualifies as a class B link.
Fractional T-1 Each channel is 64Kbps. Additional channels can be added up to 24, which equals a full T-1 line. At higher speeds, a fractional T-1 qualifies as a class B link.

Table 5.3  Class B Network Links

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

Table 5.4  Class C Network Links

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

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 (class C) bandwidth links may not be as reliable as the low (class A) links. Because Exchange Servers in the same site need a permanent link to communicate, choose the more reliable class A link if messaging volume is light.

Keep in mind, this is only one piece of information in selecting a site. You 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.

Network Size

You should know the topology and size of your network. In basic terms, a small network consists of a few physical locations, one or two servers, a few clients, and a single domain or site. A large network contains multiple locations, routers, servers, clients, domains, and sites.

Second, it's important to know how quickly your network is growing and to what extent users adopt Exchange. In many organizations, email is the universal application that everyone seems to want. The need to exchange information, schedule meetings, and "to be in the loop" overcomes even the most technically stubborn user. Along the same lines, the quick adoption of email and other client/server applications sometimes forces a reluctant organization to grow its network to meet the needs of its users.

After you have a good understanding of your network topology, estimate the impact the deployment of Exchange will have on your network's bandwidth and performance. You should perform the network impact study in close partnership with the network administrator(s).

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 transmit over a communication link. You must take into account the size of your links, however, and also carefully look at the link's utilization. You may find your network has very large and fast connections; however, they may already be congested with other network traffic, which impacts the overall performance of the network link. This is called Net Available Bandwidth (NAB). If your NAB falls to the same speed as a class A network link, you may need 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 some network links appear to have low overall utilization; however, during peak periods of the day, these connections experience traffic bursts that reduce performance.

Knowing or predicting network traffic patterns through a network link enables 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, you must measure the network bandwidth utilization (how close a network link is to full capacity) and the total packets per second (how close bridges and routers are to reaching full capacity) being transmitted. You can then use this baseline information to determine whether the network is operating normally or whether it is close to maximum utilization.

Monitoring network traffic requires specialized tools and dedicated network monitoring software, such as Microsoft's Network Monitor, included with System Management Server, packet sniffer, Network General's Sniffer, or Windows NT's Performance Monitor. For more information on the specific Performance Monitor counters you should monitor, please refer to Chapter 24, "Exchange Performance Tuning and Capacity Planning."

Network Protocols

For an effective Exchange design, 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, the X.400 connector, requires the existence of TP0/X.25, TP4/CLNP, or TCP/IP. You also must consider support for remote clients such as field sales needing remote email access, for which you can use Remote Access Server (RAS) or Dial-up Networking (DUN). Both of these support 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 Servers that are members of the same domain share a common user account and security database, which enables each user to have a single account that all servers in the domain recognize. The domain can also contain other Network Operating Systems (NOS), such as LAN Manager 2.x, and a variety of clients, such as DOS, Windows, Windows for Workgroups, Windows 95, and Windows NT Workstation.

You can review the following domain models to plan your own Windows NT domain or examine your existing one. You may choose to use Microsoft's Domain Planner Wizard, which is available in the Resource Kit or by downloading it from Microsoft's Web page.


NOTE: After you create a domain, you need to reinstall Windows NT to make any changes relating to domain membership. (for example, moving a Backup Domain Controller to another domain). Be sure that you have properly planned your naming conventions and server roles before implementing them into a domain structure.

Local and Global Groups

Similar in structure to user accounts, groups enable you to efficiently assign access privileges to multiple users within the domain. The following are two classes of group accounts:

Trust Relationships

Windows NT Server supports the ability for one domain to "trust" another domain, which gives users of the trusted (or account) domain the ability to act as authorized users on the trusting (or resource) domain. Trust also enables users in the trusted domain to access resources in the trusting domain without re-creating for a second time their user IDs and other security information. Keep in mind that no matter where network resources are located, users always log into their home (trusted) domain.

For example, you own a VCR, and your neighbor wants to borrow it to 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 enable him or her entry into your house (resource domain) to use your VCR (a network resource) without making a second key (re-creating security information).

In addition, trust is one-way and not transitive. If domain A trusts domain B, the arrangement 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, the arrangement does not imply that domain A trusts domain C.

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


NOTE: If an Exchange site spans multiple domains, you must have 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 the following three roles in the domain:

You should install Exchange on a machine serving either in a BDC or a member server role. You do not want to place Exchange on your PDC, except in special circumstances, such as in extremely small networks with very light mail volume.

Domain Models

Because Exchange needs a trust relationship to communicate between sites, you 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 following models of the Domain Monitor for Windows NT.

FIG. 5.1 Single domain model.

FIG. 5.2 Complete trust model.

FIG. 5.3 Single master domain model.

FIG. 5.4 Multiple master domain model.

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 these factors must be present to group servers together in one site. Please refer to Table 5.5 for details.

The second set of factors are discretionary. They include connection cost, connection performance, replication, and company organization. Please refer to Table 5.6 for details.


NOTE: The following examples may not completely apply to your environment. Please carefully consider all pertinent factors before selecting a site and choosing site boundaries. Any changes require a reinstallation of Exchange Server. n

Table 5.5 ecessary Site Factors

Factor Requirements
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 context. Because 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.
NAB (Net Available Bandwidth) The NAB must be equal to or exceed 64Kbps. If reliability is a factor, you may want to consider a smaller bandwidth link rather than a larger one. For example, some high (class C) bandwidth links may not be as reliable as the low (class A) links. Because Exchange servers in the same site need a permanent link to communicate, you may be wise to choose the more reliable class A link if messaging volume is light.

Table 5.6  Discretionary Site Factors

Factor Requirements
Consider large sites Because Exchange automatically replicates all changes within a site, consider making your site as large as possible to ease the administrative burden. Remember that you can split more easily than you can merge.
Directory Replication Network bandwidth is higher within a site than between separate sites--replication automatically occurs within sites. If you want to manually control replication, place the servers in separate sites.
Performance If you have a group of servers connected via links with 64Kbps or more bandwidth, you should consider grouping those servers together in a common site. Place servers connected via slower bandwidth connections in separate sites.
Company organization Naturally, you want to group together users in the same department or functional unit. The grouping provides a more effective use of network and Exchange resources.
Cost If any of your servers are connected via a link whose charges are based on the amount of data transmitted or the duration of the connection, consider placing them in separate sites.

Step 5  Selecting a Site Mapping Strategy

Now that you defined your network structure and you identified your critical site factors, you must choose a site mapping strategy. This step describes the major mapping strategies and uses 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. The service account is created on the first computer within a site. The service account validates other computers within the site and gives the computers 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, the service account resides in the domain. For multiple domains within a single site, create the service account in the account domain or whichever domain handles your administrative domain functions. In a master or multiple-master domain model, the master domain contains the service account (see Figure 5.5). In a single domain with complete trust model, any domain can contain the service account because it's accessible to all the other domains (see Figure 5.6--the grayed computer contains the Exchange service account).

If two sites are in separate domains, you can use one service account 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, 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's account name and password (see Figure 5.7).

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

The following provides an overall summary of the important factors to consider:

Review Tables 5.7 and 5.8 to determine the best mapping 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 Figure 5.5).
Single with complete trust One-to-One All domains and servers can access the service account (see Figure 5.6--the grayed computer contains the Exchange service account).
Two Single One-to-One Servers in the single Domain Model can access the service account in domain B via a properly configured site connector (see Figure 5.7).
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 Figure 5.8).
Single Master One-to-Many With the proper trusts in place, both servers can use the service account because it's located in master domain A (see Figure 5.9).
Multiple Master One-to-Many As with the previous mapping, the trust relationships enable all first and second tier servers to access the service account (see Figure 5.10).
Two Single Masters One-to-Many The mapping enables the servers in the second tier to access the service account defined in their local master domains. With a site connector, both untrusted domains' service accounts are linked together (see Figure 5.11).

FIG. 5.5 Single domain using a one-to-one mapping.

FIG. 5.6 Single domain with complete trust using a one-to-one mapping.

FIG. 5.7 Two single domains with no trusts using a one-to-one mapping.

FIG. 5.8 Single domain using a many-to-one mapping.

FIG. 5.9 Single master using a one-to-many mapping.

FIG. 5.10 Multiple master using a one-to-many mapping.

FIG. 5.11 Two single master models with no trusts using a one-to-many mapping.

Step 6  Selecting a Naming Strategy

This step describes the format, use, and restrictions of email addresses within Exchange.

External messaging standards are necessary for different mail systems to communicate and share information, and 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 require reinstallation of Exchange Server.

The following 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 and should be a 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. When choosing an organization name, be aware that the name can be used to generate email addresses for non-Exchange systems, so it's recommended that you limit the name to 10 characters for compatibility.

Site Names

You can base a site name 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, Exchange uses them when generating non-Exchange email addresses.

Server Names

A network uses the server name to identify a particular Windows 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 on domain controllers 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. Because Exchange's address book lists mailbox names, you may want to create mailbox names that sort properly when they display. Review Table 5.8 for a breakdown of mailbox names.

Table 5.8  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, such as PROFS, MHS, MCI Mail, AT&T Mail, and determine their unique requirements, such as PROFS can accept up to eight characters for an email address. For best results, the alias name should bear a recognizable resemblance to the original name--Kent Joshi becomes KJOSHI. Up to 64 characters; can be changed
Display Name Base this name on how you want to display it in the Address book and Administrator window. Be sure to consistently use the same format for all names, such as 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 sets this to the first alias name specified, but you can use another. Up to 64 characters; must be unique; can't be changed.

Email Addresses

When Exchange communicates with other (or foreign) mail systems, such as the Internet, Exchange must have a valid address format the other mail system understands. A foreign messaging system user whose address exists both on a foreign mail 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 email addresses.

Exchange automatically generates an email address for the following mail systems: X.500, X.400, Microsoft 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 you have installed a PROFS or another third-party gateway.

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. Exchange stores in the directory 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 later in this chapter).

Table 5.9 shows how the X.500 object name maps to an Exchange object.

Table 5.9  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 Joshi, who has a mailbox in Los Angeles within the Software Spectrum organization, is o=SWS/ou=LosAngeles/cn=recipients/cn=KJOSHI. When you remove the naming labels, you receive the form that Exchange uses: SWS/LosAngeles/recipients/KJOSHI.

Because 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 email with heterogeneous mail systems, as well as those who want to communicate with external companies via public carriers.

X.400 addresses can contain all the uppercase and lowercase letters, all numbers (0-9), a space, left and right parentheses, the plus and equal signs, 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 in Table 5.10.

Table 5.10  X.400 Attributes

Description Attribute
Country c=
Administrative Management a= Domain (ADMD)
Private Management Domain p= (PRMD) (Exchange organization)
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, the following is a valid X.400 address for Kent Joshi, who has a mailbox in Los Angeles within the Software Spectrum organization:

g=Kent;s=Joshi;o=Los-Angeles;p=SWS;a=mci;c=us;

This address also represents the minimum information you need to receive email from someone else.

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

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

A valid Microsoft Mail address for Kent Joshi, who has a mailbox in Los Angeles within the Software Spectrum organization, is SWS/LSANGLES/KJOSHI. For more information on connecting to Microsoft Mail, please see Chapter 7, "Planning Connections to Microsoft Mail Systems." For information on migration from Microsoft Mail to Exchange, please see Chapter 8, "Migrating from Microsoft Mail Systems."

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. SMTP 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 char-acter or addressing limitations. In general, SMTP addresses can include all uppercase and lowercase letters (A-Z), all numbers (0-9), and the hyphen (-). However, spaces are not per-mitted.

A valid SMTP address for Kent Joshi, who has a mailbox in Los Angeles within the Software Spectrum organization, is KJOSHI@LOS-ANGELES.SWS.COM.

External System Addresses  If your organization has other mail systems (PROFS, SNADS, and so on), you want to examine any conditions they place on usable characters and addressing. This way you can properly configure the Alias Name field (see the section "Mailbox Names" earlier in this chapter) for your particular mail system.

Step 7  Linking Your Sites

Now that you have your sites laid out and the proper email 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 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 in the Table 5.11 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 tolerance. Requires a permanent, highbalancing and fault bandwidth connection of at least 56Kbps or higher (class B or C link).
Easiest site connection option to configure and manage because a site network transport isn't involved. Transmits more frequently than other connection options. If you are charged for network traffic, such as frame relay or packets, 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 destinations. Can overwhelm network links when multiple Exchange servers use the same link.

RAS Connector

The RAS connector is useful where no permanent LAN or WAN connection exists, 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
You can schedule connections Transfer is limited by speed of modem.
Can link sites over an asynchronous, periodic connection. Link saturation is more likely because 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.

Exchange Server supports X.400 over the following 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 Must configure network transports. systems that support X.400 standard.
You can schedule connections. Bottlenecks may appear because all mail traffic flows through one central server.
Can determine messaging infrastructure topology. Must verify that the existing routing through Exchange's network (bridges, routers) can support the required protocols.
You can control message size.

Internet Mail Service

Although the Internet Mail Service can link two sites, the main purpose is to connect to the Internet using the SMTP (Simple Mail Transfer Protocol). You can also link most UNIX systems and any mail systems supporting plain text-RFC 822, MIME (Multipurpose Internet Mail Extensions)-RFC 1521, Microsoft Mail server format, or Uuencode/Uudecode standards.

Table 5.14 lists the benefits and drawbacks when using the Internet Mail Service.

Table 5.14  Pros and Cons of Using the Internet Mail Service

Pros Cons
Can forward all mail to a single host. Must configure a network transport (TCP/IP).
Can configure service to accept or reject host connections. You cannot schedule connections.
Can configure service 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).

Table 5.15 lists 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, which enables you to replace it without additional software. In most cases, you must configure a network transport.
Enables you to migrate your Microsoft Mail network in phases instead of all at once. Must verify that the existing network infrastructure (bridges, routers) can support the required protocols.

Lotus cc:Mail Connector

The Exchange Connector for Lotus cc:Mail enables you to tightly integrate Exchange into existing cc:Mail environments. After you install the server, Exchange Server and cc:Mail systems can exchange messages and synchronize directories. The cc:Mail Connector supports both DB6 and DB8 cc:Mail post offices. Like the Microsoft Mail connector, you can take a phased approach to migration that causes minimal disruption in an organization.

Table 5.16 lists the benefits and drawbacks when using the Lotus cc:Mail connector.

Table 5.16  Pros and Cons of Using the Lotus cc:Mail Connector

Pros Cons
Can connect directly to another cc:Mail post office, which enables you to replace it without additional software. In most cases, you must configure a network transport.
Enables you to migrate from network in non-disruptive phases instead of all at once. Must verify that the existing cc:Mail network infrastructure (bridges, routers) can support the required protocols.

Lotus Notes Connector

The Exchange Connector for Lotus Notes enables you to tightly integrate Exchange into existing Lotus Notes mail environments. After you install the server, Exchange Server and Notes systems can exchange messages and synchronize directories. Like the Microsoft Mail connector, you can take a phased approach to migration that causes minimal disruption among your user population.

Table 5.17 lists the benefits and drawbacks when using the Lotus Notes connector.

Table 5.17  Pros and Cons of Using the Lotus Notes Connector

Pros Cons
Can connect directly to another Notes server, which enables you to replace it without additional software. In most cases, you must configure a network transport.
Enables you to migrate from Notes system in non-disruptive phases instead of all at once. Must verify that the existing network infrastructure (bridges, routers) can support the required protocols.
Can schedule connections

Step 8  Planning Your Public Folder Infrastructure

This step provides a high-level introduction to Exchange Public Folders, an approach to the selection of tools for building information sharing solutions, and finally, an approach that organizations of any size can take to develop a public folder infrastructure for collaborative solutions.

Every organization has documentation on procedures and processes, forms for services, bulletins, business processes, and other information that needs to be available to the organization employees or specific workgroups. To aid in the collaborative use, distribution, and sharing of this information, a number of different solutions have been developed and widely implemented. These solutions primarily fall into two categories: the Intranet and Groupware.

The Intranet has quickly become a popular mechanism through which to make information easily available to users through relatively low bandwidth connections. The browser has become a ubiquitous component of the corporate and home computer. As this technology matures and addresses some of the security issues with which it is still struggling, the browser will solidify its position as a mechanism for business transactions.

Groupware enables employees to communicate, collaborate, and share information through memos and files so that they all work more effectively. Exchange provides a messaging environment along with structured tools that enable group collaboration in different ways. The main tool Exchange provides for this is Public Folders.

Introduction to Public Folders

Public folders are repositories for information that different users can share and different types of clients can access. Public folders can contain many different types of information, from simple messages to complex multimedia clips. Public folders can also contain custom forms for contributing and reviewing information and rules, and views for finding and organizing information. Public folders provide an environment for all kinds of custom applications, such as bulletin boards, discussion forums, customer tracking systems, and workflow applications. Public folders reside in the public information store (\MDBDATA\PUB.EDB) on an Exchange Server computer. You can replicate (copy) individual public folders, if you desire, to one or more additional Exchange Server computers. When a change is made in a public folder, the change copies on a scheduled basis to every replica of the folder that exists throughout the Exchange Server organization. This replication is based on a multi-master architecture. This implies that a change on any instance of the public folder immediately replicates throughout the hierarchy.

Public folders are an important part of Exchange. They provide flexibility by using a variety of forms, views, access rights, and structures. You can also use public folders to replace or compliment distribution lists, reducing storage requirements and network traffic. More importantly, instead of just reducing network traffic and hard disk requirements, public folders can hold important background information on projects, customers or other business-related activities. Some of the ways in which public folders can be leveraged to improve business processes include the following:

Note that you can create, design, and view public folders only with an Exchange client. Use the Exchange Administrator program to configure public folder replication and a variety of other administrative options. In summary, folders are as follows:

Selecting Tools for Information Sharing Solutions

As an organization plans for the implementation of managed information sharing solutions, you must realize that an effective and successful collaborative system contains elements from several different environments and technologies in order to adequately meet both the business and end-user needs.

In recent years, another popular solution to disseminate information has emerged from what was the core set of Internet technologies. The intranet (Intra-organizational network) leverages the same software as existing Internet access applications. The software--coupled with the broad availability and distribution of the browser interface--led to its popularity.

When comparing the intranet to Exchange public folders, organizations must recognize that each solution has its strengths and weaknesses. Exchange is effective at enabling users to communicate and capture their discussions into public folders. Exchange also provides a secure repository where users can submit, update or delete documents they have provided for internal consumption. Additionally, Exchange provides power users the tools with which to develop and deploy electronic forms for general use. These grassroots efforts can form the foundation for more complex workflow forms-based applications. The strengths of the World Wide Web include its ability to integrate multimedia components such as audio, video, or images, into a web page. Additionally, you can enhance the web pages by adding additional information from virtually any source through the use of hyperlinks. Unfortunately, using an intranet may present some significant challenges including security, limited document management solutions, and a limited set of standard third-party tools for integration and other administrative tasks.

When deciding which information sharing technology is best for a particular application, you must consider the following two key factors:

Traditional client/server applications are effective in scenarios where both the data and the user interface are well-structured. The client/server applications tend to struggle when either the data or the GUI are unstructured. In the cases where the data is unstructured, Exchange provides a good solution. In contrast, the web's unstructured interface is a good fit when the data needs is structured, such as when you publish relatively static information.

In summary, you must analyze and define the user requirements in regards to the source and nature of the information that the application uses and the nature of the GUI that best meets the user needs. After you define these two items, you can select the right technical solution or develop a hybrid solution to meet your users' needs in the most effective and efficient manner. Finally, it is recommended that you develop your organization's intranet and Exchange public folder infrastructures in conjunction--with the objective that they compliment each other.

Building a Public Folder Infrastructure

The deployment of a public folder infrastructure requires that you understand your organization's business objectives and goals as well as understand the processes and information involved in the day to day operations of your business. Only after understanding these issues are you able to develop and deploy a public folder infrastructure that adds the following values to the organization:

When defining a public folder hierarchy, you must define key design principles that serve as the foundation for any design decisions you make. These principles can include items such as:

After you define the business objectives and opportunities that the Exchange public folders must address, you begin the detailed planning of the Exchange public folder infrastructure. An Exchange public folder infrastructure consists of the following components:

Defining the Public Folder Hierarchy  When planning a public folder hierarchy your primary design goal is to develop an environment that complements and enhances the day to day business tasks performed by your users. Four approaches are commonly used to develop a public folder hierarchy:

Organizational Model  The organizational model is based on the way in which your organization is structured. That is, the public folder hierarchy mirrors the way the organization is divided into business units and/or functional departments. The model works well for those organizations with a highly decentralized structure based on highly independent divisions or business units. The hierarchy under this model is as follows:

The organizational model enables you to create "corporate" folders, where information or automated processes, which apply to the entire organization can be located. One of the advantages of this model is that the administration of security is straightforward because the security closely resembles Windows NT user groups and/or Exchange distribution lists.

Geographical Model  The geographical model is based on the geographical distribution of an organization's user population. That is, the public folder hierarchy mirrors the way your organization is distributed on a national or international basis. The model, works well for international organizations, where you encounter diverse labor and business environments. The hierarchy under this model is as follows:

The geographical model enables organizations to present information that is tailored for users based on their common cultural or legal environment.

Business Process Model  The business process model is based on the business processes that are the basis for the day-to-day operations of your organization. That is, the public folder hierarchy mirrors the way your organization does business. The model works well for those organizations that have well-defined business processes, which are standardized throughout the organization. The hierarchy under this model is as follows:

The model also enables you to create "corporate" folders for non-business process specific information, such as human resources policies and procedures. The business process model reduces the probability of redundancy with information that might be best suited for publication on your intranet.

Hybrid Model  The Hybrid model is based on the combination of two or more of the previously discussed models. The following lists one example of how you can implement this model:

The main advantage of this solution is that it enables you to provide the most flexible solution to the potentially diverse needs of your user population.

Planning the Public Folder Servers  When planning for your public folder servers, make sure you understand that the physical location of public folder servers and the corresponding folders on them is different from the logical hierarchy presented to users. That is, the users have no idea where the public folders are located. The only difference they might notice is the access performance between a local and a remote public folder. In order to adequately size your public folder environment, you must answer the following questions:

Defining Public Folder Policies and Procedures  Historically, one of the main reasons why organizations have failed to deploy effective and manageable public folder systems is that they did not define, document, and implement the necessary policies and procedures. Additionally, for your policies and procedures to be truly effective, they must have the full support of top management and have been properly communicated to the appropriate IT (Information Technology) staff and all the user population. This is an educational process, which could potentially cause a cultural change as well.

Some of the issues you must address in defining public folder policies include the following:

In order for you to effectively monitor and maintain a public folder system, you must define, document, and implement administrative procedures. You should include the following procedures:

Step 9  Other Considerations

This step discusses other issues when planning for Exchange. This step is optional because it discusses advanced-planning items. You may want to fully complete all the other steps before beginning Step 9.

Estimating Hardware Requirements

Because Exchange is a transaction-based database, the proper server hardware is critical for a good Exchange system. The Exchange components (information store) first record a transaction, or create a message into a log file. During idle times, Exchange commits those changes into the proper component (for example, information store). If the Exchange server fails, it uses the log file to complete any missed transactions. Furthermore, Exchange heavily uses RAM to retain frequently accessed memory and address requests. A good rule of thumb is to invest in both additional memory and disk subsystem (hard drive, controller, and RAID/striping technology) for a high performance general-purpose Exchange server. Because every company has variables that may utilize hardware differently, use Performance Monitor to be certain your hardware investment provides the most value.

Also, dedicating an Exchange server (as a gateway, public folder, NNTP server, and so on) requires more testing for the best hardware mix. You also have the option of adding non- Exchange services, such as RAS, SQL, and domain controller roles onto an Exchange server. For the best performance, however, place Exchange functions onto their own servers.

For medium to large organizations, it is recommended that you define several different server hardware configurations to address the requirements of different numbers of users per location and the different roles a dedicated Exchange server has. Considering that Windows NT Server supports symetric multi-processing (SMP) systems, you can provide highly scaleable hardware configurations. Defining different Exchange server classes ensures that your are properly sizing a server for a specific role and a specific number of users. The classes assist you in planning your Exchange deployment as well as in defining an accurate project hardware budget. Finally, note that as your users' requirements grow you can increase the capacity of your systems by adding more memory (RAM) or additional processors. For specifics regarding capacity planning, please refer to Chapter 24, ""Exchange Performance Tuning and Capacity Planning."

Remote Users

With a little planning, mobile or remote user's needs can be met with the default communication packages delivered with Exchange or the operating system.

Client requirements  To connect remotely to Exchange, you need only the default communication package delivered with the Exchange Client or your particular operating system. The Exchange Client automatically detects the communication software and connects and disconnects as needed.

In Table 5.18, you find the default communication package included with different Microsoft desktop operating systems.

Table 5.18  Client requirements when connecting remotely to Exchange

Operating System or Browser Default communication package
MS-DOS, Windows (16-bit) Shiva--included with Exchange client
Windows for Workgroups, Windows NT Workstation Remote Access Server (RAS)--included with operating system
Windows 95 Dial-Up Networking (DUN)--included operating System
Web Browser (Internet Explorer) Active messaging using Internet Service Provider (ISP) or DUN

Server Requirements  The Remote Access Server service (RAS) included in Windows NT Server supports all the previously mentioned communication packages, including Shiva. Furthermore, you can use a modem, null-modem cable, X.25 (via the network or using PAD), ISDN, or security hosts and switches as connection methods. Note that you need to estimate the number of users dialing in and plan phone lines accordingly.

Usage Scenarios  You must define the different Exchange usage scenarios for your user population. The scenarios help you define the best Exchange client profile configuration for different groups of users. For example, a group of users who access Exchange Server only from a dial-up connection, are best served by using an offline storage file (OST), which synchronizes their local inbox with their inbox on the Exchange server. For this group of users, the client profile includes an OST file.

Step 10  Reviewing Your Plan

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

Keep in mind that every time you expand your network or Exchange site, you 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.

Additionally, you must view the Exchange design process as an iterative process, which you optimize as the business environment around your organization's changes. l


Previous chapterNext chapterContents