A session summary from the Microsoft Exchange Planning Workshop heldSeptember 19-21, 1995, in Bellevue, Washington.
As you plan your Microsoft® Exchange system, two key areas you should consider are routing and public folders. Routing is the process of ensuring that a message is successfully delivered to a recipient. When a message is sent, the Microsoft Exchange Server computer decides which path the message will take until it reaches its destination. Because routing is such a critical component in getting information to the people who need it, it's important to plan a routing topology for your Microsoft Exchange system carefully.
It is also a good idea to make important decisions in advance about how public folders will be implemented and maintained on your Microsoft Exchange system. Public folders store several types of information that a group of users can share and access simultaneously. Documents, spreadsheets, fax messages, and many other types of information can be stored in public folders for easy retrieval. Public folders are also used along with custom electronic forms to create Microsoft Exchange Server applications.
This document provides overviews of the routing and public folder technologies, and gives you valuable information that can help you plan ahead for routing and public folder solutions that suit your organization's needs.Planning the Routing Topology
To simplify administration and message routing, Microsoft Exchange groups servers that are within a local geographical area into a unit called a site. Users and administrators within a site see it as a single entity because servers within a site share the same directory information, and they communicate quickly with one another without any special configuration. Because the servers maintain such close communication with one another within the site, message routing, directory updates, and administrative changes within the site occur immediately. Administrators do not have to manage how servers interact within the site; it is automatic.
Although in some cases all of the users in a company will be located in one building, most larger companies' users will be located in several locations around the country or the world. The computer network connectivity that exists between these locations varies widely, and in some cases may not exist at all. In these situations, it is efficient to group servers in each location into sites. Microsoft Exchange provides several ways to connect individual sites together easily so messages can be exchanged across the entire organization.The Site Connector
Microsoft Exchange provides several connectivity options for connecting distributed sites. The Site Connector uses the same high-speed protocol (remote procedure calls) to connect servers between sites as is used by servers within the same site. The Site Connector option is the easiest site connection option to configure and administer, and it offers several configuration options to give you greater control, as well as useful default settings. The Site Connector even configures both sides of the connection at one time.
The Site Connector does have some drawbacks, however. The Site Connector assumes that a relatively high-bandwidth network connection exists between the remote locations. Where low-bandwidth connections exist (for example, 56K/sec. leased lines), the Site Connector may consume too many resources to perform adequately, or may have a negative impact on the performance of other applications using the link. In addition, in situations where the cost of the network link is based on traffic, as in frame relay or other packet networks, you may prefer a connectivity option that transmits less frequently than the Site Connector. The X.400 Connector
The X.400 Connector delivers messages between sites according to the X.400 protocol. Microsoft Exchange Server computers can be configured to support one or more of the X.400 transports (TCP/IP, TP4, X.25), and then route messages using standard X.400 message protocols. The X.400 Connector is an efficient way to connect Microsoft Exchange sites across slower network links and on private or public packet networks. The X.400 Connector can also be used to connect Microsoft Exchange sites to non-Microsoft Exchange messaging systems that support the X.400 standard.The Internet Mail Connector
The Internet Mail Connector delivers mail between sites using the SMTP (simple mail transfer) protocol commonly used on the Internet. Microsoft Exchange Server computers that are configured to support the TCP/IP transport protocol can use the Internet Mail Connector to exchange messages. The Internet Mail Connector can also connect Microsoft Exchange sites to the Internet itself, or any other system that supports the SMTP RFC-822 or MIME (multipurpose Internet mail extensions) standards. Because SMTP support is built in to most UNIX® systems, the Internet Mail Connector enables users of UNIX systems to exchange messages with Microsoft Exchange users.The RAS Connector
In many cases no wide area connectivity exists between sites in an organization. This situation is common in very small satellite offices where permanent connections are either too expensive or are not available. Every Windows NT® server has a built-in remote access service (RAS) to provide dial-in access to the server. The Microsoft Exchange RAS Connector uses this capability to dial-up other Microsoft Exchange Server computers periodically to transmit messages. In cases where message traffic is low and message exchange can be scheduled, the RAS Connector is a very inexpensive way to incorporate satellite offices into the corporate messaging system.
You can also use the RAS Connector to provide an alternate connection for sites using one of the other connectors. For example, you can configure the RAS Connector to handle message routing in cases where the primary connector link becomes unavailable, adding even more reliability to the system.How Messages Are Routed
Once all of the sites in an organization are determined and the connections between them established, Microsoft Exchange can manage the routing and delivery of messages throughout the system. As sites are connected to the system, Microsoft Exchange automatically builds a routing table within each site that determines how messages will be routed from one point in the system to another.
While Microsoft Exchange is designed to handle routing decisions automatically, you can influence the process by associating a cost with each connection, or by setting a schedule for desired connection times. The cost of a connection is not a dollar amount per se, but is a number that represents the desirability of one route as compared to all of the other choices the Microsoft Exchange Server computer could make. For example, a connection over a leased line may be assigned a relative cost of 1, a frame-relay connection a cost of 5, and a satellite connection a cost of 50. When making the decision of which way to route messages through the system, Microsoft Exchange considers the total cost of a path from end to end. Microsoft Exchange always chooses the lowest cost route, using the higher cost alternative only when lower cost options are unavailable.
In addition to cost, scheduled availability is also taken into account. You can configure the X.400, Internet, and RAS Connectors to be operational at different times of the day. The availability of a path through a connector is also taken into account when Microsoft Exchange determines how messages will be routed.Planning for Public Folders
To make information available to many users in an organization, Microsoft Exchange includes technology that replicates information in public folders. The replication process creates copies of a public folder on one or more Microsoft Exchange Server computers, and then makes sure their contents remain synchronized. As a result, public folder contents are broadly available across an organization. Users need never worry about where a public folder is located, or whether it is a copy or the original. They simply see it as a folder that is available to everyone, everywhere across the organization.
A key step in effective planning for public folders requires an understanding of the public folder architecture itself. In addition, you should also consider developing a public folder policy for your organization early. Policy decisions determine the public folder hierarchy that everyone in the organization will see, who will use public folders, how much they will use them, and for what purposes they will be used. These decisions in turn influence where public folders are created, and will determine how much disk storage, CPU power, and memory will be needed to achieve the expected performance levels.
The following sections describe the architecture of public folders and provide suggestions that can help you plan your public folder policy.The Public Folder Architecture
Public folders are created the same way that folders are created to hold personal messages, using the Microsoft Exchange client. Once a folder is created, the owner can set access permissions, create views, establish rules, and assign other properties of the folder—all from within the Microsoft Exchange client. Electronic forms can also be constructed and installed into the public folder to create a folder-based Microsoft Exchange Server application. While much of how public folders are created is left to the user, the way public folders are replicated and managed is in the hands of the administrator.
A core component of Microsoft Exchange Server is the information store, a database that holds information. Microsoft Exchange Server computers can be configured to have a private store, public store, or both. Individual messages and private folders are held in a database called the private information store. Public folders and their contents are held in a separate database, the public information store.
One of the first configuration decisions you will have to make regarding public folders is where they will be created. The Microsoft Exchange architecture mandates that each site have at least one public server (the term "public server" refers to a Microsoft Exchange Server computer that contains a public information store). In some cases all of the Microsoft Exchange Server computers in a site may be configured as both public and private servers. In other cases you may choose to use separate public and private servers, in essence splitting the functions across several computers.
The decision to combine or separate public and private stores will likely be based on anticipated use, storage requirements, and policy, and you have the flexibility to structure the system optimally for each situation. Regardless of the structure you choose, the actual server location of a particular public folder is hidden from the users, who see all public folders as one, unified hierarchy.
The main objective of public folders is to enable users to access the same information, the same way, without regard to the actual location of where the information is stored. To do this, Microsoft Exchange treats the folder hierarchy and folder contents as separate elements. The folder hierarchy is the organization of the public folders as they appear to the users in the Microsoft Exchange client. To provide consistency across the entire system, Microsoft Exchange Server computers within an organization share the same folder hierarchy. The public folder hierarchy is replicated automatically to all public servers within an organization to ensure that accessing a specific public folder is the same process for all users.
While the entire public folder hierarchy is replicated automatically, the administrator determines the degree to which the folder contents are replicated. Folder contents refers to the forms, messages, documents, or other objects contained in the folder. The ability to control how folder contents are replicated is important for efficiency. For example, if users in three geographically remote locations need access to a public folder, it might be better to replicate the information to a public server in all three sites rather than having all users access the information from one public server across wide-area links. The public folder architecture in Microsoft Exchange enables the users to access the same information, the same way, from several physical locations. They see one hierarchy, but the actual contents of the folder may exist in several places.
You should consider geographical distribution, network bandwidth considerations, and load distribution when you decide to replicate public folder contents. Microsoft Exchange is designed to provide you with a self-maintaining replication mechanism that takes care of itself once it is set up. Setting up replication is simply a matter of selecting the servers to which a folder will be replicated and then setting the schedule, storage, and data age limits. From that point, information store processes track changes to the folders, bundle the changes in a mail message, and send it to the replicas. Because replication signals are essentially mail messages, they will be routed using the same mechanism as all other messages.
Replicated folders can introduce the possibility of conflicts as users work against different replicas. For example, two users may simultaneously modify the same form in different replicas of a public folder, creating a situation where the content conflicts. While the nature of public folder applications minimizes this possibility, Microsoft Exchange provides a mechanism for handling replica conflicts intelligently and automatically. First, Microsoft Exchange assigns revision numbers to all items in a public folder. Using revision numbers, the Microsoft Exchange Server computer can identify when conflicts occur and post conflicting revisions for a user with the appropriate permission to resolve. Microsoft Exchange also provides a backfill operation to quickly enable public folder replicas to be updated when a new replica is created, a server comes back on line after being down for a period of time, or in cases where servers are restored from tape backup.Determining Public Folder Policy
In addition to the technical factors of Microsoft Exchange routing and public folder architecture, the administrative policy decisions that you make regarding public folder use will be an important factor in how public folders will be used in your organization. Before completing a Microsoft Exchange routing and public folder design, you should determine:
By taking policy considerations into account during the planning process, you can determine the best ways to take advantage of Microsoft Exchange public folders.
The descriptions of other companies' products in this document are provided only as a convenience to the reader. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult the respective manufacturers.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, this document should not be interpreted as a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of this publication.
This document is for informational purposes only and is subject to change without notice. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
©1995 Microsoft Corporation. All rights reserved. Microsoft is a registered trademark and Windows NT is a trademark of Microsoft Corporation.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd.