## MS BackOffice Unleashed

- The History of Messaging Standards and Architecture
  - The Timeline of Messaging
  - The Need for Standards
  - Messaging Standards for the Internet
  - X.400 and X.500
- From MS-Mail to Exchange
  - Client Software
  - Administrative Tools
  - The Administration program for Microsoft Mail is DOS-based and requires a redirected drive letter to the post office that needs to be administered. From this interface, administrators can add, modify, and delete user mailboxes, external post offices, and change system options. The menus within this program are not generally considered intuitive and take time to get used to. Remote users' settings and gateways are also administered from this program and provide the administrator with simple tools for checking message queues and configuration. The import/export utility is command line-driven and is used to maintain address lists for the local and externally defined post offices.
  - The Exchange server administration program is GUI-based and leverages the client-server architecture by making connections to servers over RPCs. From this interface, an administrator can manage the entire enterprise, consisting of many servers at different locations. Every object within the X.400 schema database is accessible for doing maintenance and configuration, with an emphasis on being able to see the entire system from one view. The bulk import/export utility is integrated to enable easy creation and manipulation of mailboxes. This program will run only on computers running NT, so administrators must plan accordingly to make sure they have appropriate hardware on administrative workstations. Other administrative tasks are performed by using the various administrative tools, such as server manager and event viewer. This tight integration with NT makes this program much more usable and enables a single-seat view of the entire Exchange messaging system.
  - Server Message Store
  - Message Transfer Agents
  - Directory Services
  - Gateways
- Exchange Messaging Architecture
  - The System Attendant
  - The Information Stores
  - The Directory Services
  - The Message Transfer Agent
- Connectors and Gateways
  - Site Connector
  - Dynamic RAS Connector
  - Microsoft Mail Connector
  - Internet Mail Connector
  - X.400 Connector
- Directory Management
  - Directory Service Agent
  - Directory Synchronization Agent
- Groupware, E-Forms, and Scheduling
  - Public Folders
  - Electronic Forms
  - Group Scheduling
- Summary

#
— 20 —

##
Exchange Server and Mail Overview

Deep within each of us is the need to communicate. From the earliest cave drawings to today's electronic messages, humans have demonstrated the need to share their thoughts with each other. Although we have replaced stone tools and pigments with keyboards and bytes, the need to express our ideas in writing has remained constant.

In this chapter you will learn about the history of messaging standards and their impact on Microsoft Exchange. You will examine the different messaging standards, such as SMTP, X.400, and X.500, and how they came about. Then the discussion picks up where Microsoft entered the game with MS-Mail, and you will read about the transition to Exchange. This section should be helpful for those administrators using MS-Mail today. The success of any messaging system depends on how well it can "play with others," so an explanation of the different connectors and gateways is needed. Good directory management is crucial to any enterprise messaging system, so you will learn about Exchange's directory services. And last, but not least, is a discussion of the groupware, electronic forms, and scheduling features found within Exchange.

Industry requirements and competitive pressures demand that a messaging system's primary focus be on the timely, reliable transfer of messages from sender to recipient. Customer requirements for groupware functionality require the system to go beyond the traditional messaging services and provide features that support collaboration and coordination of information among users. This situation creates many challenges for both the application developer and the support professionals responsible for implementation and maintenance.

Microsoft Exchange may have arrived on the scene four years later than initially promised, but after reading this section, you will see why the product was worth the wait. Building a robust client/server messaging system with integrated groupware and standards-based gateway services is a major accomplishment. The needs of this powerful multiuser messaging system were a perfect match for the Windows NT platform, which brings Exchange Server the horsepower, security, and scaleability it needs to support large enterprise organizations. This overview of the different messaging standards and their relationship to Exchange is necessary to properly convey the rest of the concepts in this section.

###
The History of Messaging Standards and Architecture

Picture yourself as a typical end-user in the 1970s attempting to communicate with other employees in your organization. You would be sitting at a "dumb" terminal attached to a proprietary time-sharing host computer using text-based editors to send "messages" to your intended recipients. Although the process was frustrating at times, your messages could be sent to and received by any other person connected to the local host. Now let's say that you wanted to send a message to your customer on a different proprietary host two states away. This was virtually impossible at the time because no real standards for interchange of electronic mail between dissimilar systems were available.

####
The Timeline of Messaging

In the early 1970s the Department of Defense commissioned a research project to create a communications network that could survive nuclear attack. This brought about the creation of the ARPANET (Advanced Research Projects Agency Network), which used packet-switching technology to ensure that there was no single point of failure. Although ARPANET and its offspring, the Internet, were a good solution for connecting government installations and universities, corporations were not initially allowed to "connect up" for commercial purposes.

In 1972 Ray Tomlinson of BBN (Bolt Beranek and Newman, Inc.) created "e-mail" to send messages over distributed networks such as ARPANET. In 1972 more than 100 researchers at the University of Wisconsin were sending e-mail over THEORYNET using UUCP (UNIX to UNIX Copy). Finally, in the early 1980s messaging standards solidified with the adoption of TCP/IP as the standard protocol, with RFCs (Request for Comments) #821 and #822 defining the format and delivery method for messages. This began the process of establishing and enhancing messaging standards, most of which we still use today.

Refer to Figure 20.1 for the major events in the evolution of messaging.

FIGURE 20.1. The timeline of messaging standards.

####
The Need for Standards

Throughout the 1970s and 1980s, companies realized that host-based messaging was good for supporting the needs of the organization, but not flexible enough to communicate externally. Around this time other proprietary LAN file-sharing based systems were developed by software vendors to support the demands of the new corporate personal computers. These new systems were also limited in their capability to communicate with other systems outside the local network or workgroup. This produced problems for many enterprise-level companies that had various proprietary host and LAN-based systems that could not talk to each other, even within the same organization.

Many of the software vendors developed gateway products to link to external systems, but they were also proprietary in nature and did not solve the underlying problem of interoperability. Fierce competition among the various software vendors created some de facto standards, but seamless message transfer between dissimilar systems was still not possible. The industry realized that messaging standards were needed to allow for the exchange of messages among a large number of highly dispersed users on dissimilar systems.

This situation allowed organizations such as the International Telegraph Union (ITU) (formerly the International Consultative Committee on Telephony and Telegraphy, or CCITT) and International Standards Organization (ISO) to develop the X.400 recommendation for messaging, and the X.500 recommendation for directory services. Because X.400 and X.500 were created by communication service providers for their proprietary networks, they did not necessarily meet the needs of the growing Internet. This problem prompted the IETF (Internet Engineering Task Force) to enhance the earlier RFCs #821 and #822 by adding such services as MIME, PGP, RECIPT, PEM, and NOTARY. This leads to a discussion of the various messaging standards.

####
Messaging Standards for the Internet

The journey Internet messaging standards have taken from the inception of the ARPANET to the Internet of today has been an interesting one. Electronic mail and the transports that carry it have changed drastically, with various groups and individuals adding RFCs to upgrade and enhance mail features. Due to the culture of the Internet, these messaging standards are uniquely tailored for simplicity and ease of use. Here is a list of the most prevalent Internet messaging standards:

- RFC 821 describes the commands and arguments passed between hosts to transfer a mail message. The Simple Mail Transfer Protocol (SMTP) is defined by this specification.
- RFC 822 defines the syntax for text messages, split into the envelope and unstructured message contents. The message contents are concatenated with no boundaries for different body types or attachments. Nontext attachments are usually handled by UUENCODE encryption by the sender, and UUDECODE decryption by the recipient, stored as a message body part.
- RFC 1521 (Multipurpose Internet Mail Extensions, or MIME) defines the format of the actual message body parts and specifies the methods to tag each part for identification. Message body parts can be different kinds of data such as sound and video Rich-text.
- RFC 1154 defines the message format used by the Microsoft Mail Gateway to SMTP. Nontext attachments are encoded with UUENCODE after the first body part, with the extra message header X-MS-Attachment defining the various properties of the attachments.
- RFC 1327 is a proposal for a series of mappings to be used to allow X.400 and SMTP systems to exchange mail messages without the use of a gateway.
- RFC 1725 POP3 (Post Office Protocol 3) is a standard by which an Internet mail server allows clients to directly connect via TCP/IP to send, retrieve, and delete mail.

The messaging protocols utilized by the Internet are very basic in design, but they serve the needs of millions of users every day. With the advent of Domain Name Services (DNS), messages can be routed to the intended recipient via a structured naming convention to map to a physical address. Unfortunately, the Internet messaging standards are lacking in a few crucial services, such as read receipt, delivery receipt, and guaranteed message delivery. Future enhancements should allow for better mapping of message fields, as well more structured definitions of service requests.

####
X.400 and X.500

As the emerging Internet messaging standards were gaining support in the early 1980s, the United Nations group CCITT was addressing the needs of worldwide telephone systems and public data networks. The CCITT realized the need to create a robust standard for international computer-based message handling. This lead to the initial X.400 (1984) recommendation with a goal to allow for electronic mail users to exchange messages regardless of the system they are on. Although X.400 gained very strong support from many parties, this first attempt at a standard fell short of solving all the messaging issues.

In 1988 the recommendations were refined and updated to meet the ever-changing needs of message handling systems (MHS), establishing the X.400 (1988) specification. It defined new guidelines for security, directory services, distribution lists, extended mapping, and the definition of the message store. Since the 1988 specification the combined efforts of the ITU (Formerly CCITT) and ISO have overhauled the X.413 message store, and when this specification is officially published later this year it should take X.400 into the next century.

While the CCITT was working on the X.400 (1984) specifications, the need for an extensible directory service became apparent. The directory is required to maintain information about all the various objects within an organization, such as people, distribution lists, message transfer agents (MTA), mail messages, and organizational units. This lead to the X.500 directory recommendation's adoption in 1988; unfortunately, it was not able to meet all the requirements of true directory services. Further work by the ITU/ISO refined the specification to extend directory services to met these challenges.

###
From MS-Mail to Exchange

Microsoft Mail first came on the scene in the late 1980s. It was derived from a product named Network Courier. Microsoft Mail had some distinct features of a LAN-file-sharing-based architecture, such as GUI client software, post office message stores, message transfer agents, store-and-forward message routing, and directory synchronization. Often referred to as client/server-less architecture, the active processes for mail transfer are located in the client software and external message transfer agents. Imagine if you had to drive to the post office every time you wanted to send or receive letters, with no mailman to deliver the letters to your mailbox, with your intended recipients having to do the same at their post offices. This process allowed for simple and easy messaging for small locally connected workgroups, but it presented many challenges for administrators in large enterprise organizations.

In 1990 Microsoft began work on its next-generation messaging system, Exchange Server, code-named "touchdown." The product team for Exchange realized that a complete departure from the architecture of MS-Mail was needed to build a competitive product. Utilizing client/server architecture and the X.400/X.500 messaging recommendations, the team members set out to build a scaleable, reliable, interoperable enterprise messaging product. Naturally, they had to be sure to provide for backward compatibility with the MS-Mail environment to allow for easier migration. Around the same time, the Internet was gaining popularity with their customers, so they had to ensure that Exchange could work with Internet protocols.

MS-Mail and Exchange have different architectures, which means there are differences in the messaging components that make up each system. These messaging components can be divided into six parts:

- Client software
- Administration tools
- Server message store
- Message transfer agents
- Directory services
- Gateways

####
Client Software

The client software for MS-Mail is based on the MAPI (Messaging Application Programming Interface) specification and is designed to use transport-specific service provider drivers to access various mail systems. Support for simple MAPI and CMC (Common Mail Calls) allow it to work across various platforms such as Windows 16-bit, Windows 32-bit OS/2 Presentation Manager, and Macintosh. Messages are retrieved from the Shared File System (SFS) post office and moved to the user's appropriate MMF (Microsoft Mail File format) file located either locally or on the server. Messages are moved by the client software to and from the post office, without the assistance of any process running on the server. The user interface is GUI based (except for DOS); it provides panes for viewing the tree of folders on the left and the contents of each folder on the right. Figure 20.2 shows an example of the MS-Mail client interface.

FIGURE 20.2. The MS-Mail client interface.

Microsoft Exchange Client is also built on an enhanced MAPI specification, but it supports dynamic simultaneous connections to various service-provider drivers, while storing messages in a universal inbox message store. The Exchange Client has the same look and feel on the following environments:

- Microsoft Windows 3.1
- Microsoft Windows for Workgroups
- Apple Macintosh System 7
- MS-DOS
- Microsoft Windows NT (Intel, Mips, and Alpha)
- Microsoft Windows 95

The Exchange Client establishes a synchronous RPC (Remote Procedure Call) connection to the Exchange Server over any number of network protocols, not using any SFS access methods. The mail messages are moved from the server to a server-based or local message store. Because Exchange uses the client/server architecture, both the server and the client can initiate two-way mail transfer. The client software is GUI based (except for DOS) and has folder and folder-contents viewing panes similar to MS-Mail's. The main difference in the interface is in the hierarchical view of message stores and folders in the left pane. Figure 20.3 shows an example of the Exchange Client interface.

FIGURE 20.3. The Exchange Client interface.

####
Administrative Tools

####
The Administration program for Microsoft Mail is DOS-based and requires a redirected drive letter to the post office that needs to be administered. From this interface, administrators can add, modify, and delete user mailboxes, external post offices, and change system options. The menus within this program are not generally considered intuitive and take time to get used to. Remote users' settings and gateways are also administered from this program and provide the administrator with simple tools for checking message queues and configuration. The import/export utility is command line-driven and is used to maintain address lists for the local and externally defined post offices.

####
The Exchange server administration program is GUI-based and leverages the client-server architecture by making connections to servers over RPCs. From this interface, an administrator can manage the entire enterprise, consisting of many servers at different locations. Every object within the X.400 schema database is accessible for doing maintenance and configuration, with an emphasis on being able to see the entire system from one view. The bulk import/export utility is integrated to enable easy creation and manipulation of mailboxes. This program will run only on computers running NT, so administrators must plan accordingly to make sure they have appropriate hardware on administrative workstations. Other administrative tasks are performed by using the various administrative tools, such as server manager and event viewer. This tight integration with NT makes this program much more usable and enables a single-seat view of the entire Exchange messaging system.

####
Server Message Store

Microsoft Mail utilizes a courier-derived database that clients access through their network operating system redirector as an SFS. This message store is the repository for undelivered user mail, user message stores (server based), outbound inter-post office messages, folders, address lists, and server configuration files. Because the MS-Mail message store is proprietary, it does not adhere to any widely adopted messaging standard.

The Exchange Server message stores, split into public and private, are vastly different from the SFS stores of MS-Mail. Because the database underneath the Exchange information store is based upon a fully relational transactional 24X7 database technology, the clients do not need to make a redirected drive connection. The private message store contains all the user messages and uses pointers to a single instance of a message to reduce the storage needed when there are multiple recipients. The public message store contains the public folders, electronic forms, documents, and messages stored in those folders. Currently, the maximum size of any message store is 16GB, but the next version will increase the size to 16TB essentially removing that limitation.

####
Message Transfer Agents

Microsoft Mail uses external MTAs for inter-post office message transfer, and they can operate over X.25-, modem-, LAN-, or WAN-based connections. For direct connections via a drive letter, networking software is necessary for each type of network operating system to which a post office connection needs to be made. MTAs come in three flavors: DOS, OS/2 MMTA, and Windows NT MMTA, with each type capitalizing on the strengths of the operating system on which it runs. The asynchronous MTA is also used to support remote mail clients via modem, or message transfer between post offices.

In contrast, the MTA for Exchange Server conforms to the X.413 (1988) specification for a message transfer agent. It can operate over the following OSI transports:

- TP0/X.25
- TP4/(CLNP)
- TP0/RFC 1006 to TCP/IP

The Exchange MTA can be used to connect different Exchange sites, or connect an Exchange site to another system running either the 1984 or the 1988 X.400 specifications. For asynchronous connections, Exchange uses the Dynamic RAS Connector which utilizes the remote access services built into Windows NT. Exchange also includes an MS-Mail–compatible NT MMTA so that it can interoperate with MS-Mail systems. The Exchange MTA also has the capability to act as a relay MTA, to help it seamlessly send and receive messages to other X.400 systems. Another robust feature of the MTA is the capability to act as a PRMD (private management domain)-to-PRMD MTA, eliminating the need to connect to a public X.400 service.

####
Directory Services

Microsoft Mail has a simple directory synchronization (dirsync) protocol that depends on a single post office to act as the master repository for directory updates. The dirsync process has four transaction processing cycles:

- T0. This is the time when a user mailbox or group is created, modified, or deleted. Transactions are stored in the file reqtrans.glb on the post office and can happen at any time.
- T1. This is the time when the requester post offices process and send a list of the T0 transactions to the dirsync server via a special message called dispatch mail.
- T2. This is the time when all the T0 transactions sent by the T1 process are compiled by the dirsync server. The updates from each post office are grouped into update lists to be sent as dispatch mail to all the appropriate requester post offices.
- T3. This is the time when the dispatch mail is received and imported by all the requester post offices. Then the process to rebuild the global address list (GAL) runs to complete the dirsync process.

The directory synchronization process for MS-Mail is very structured and easy to follow, but it lacks features such as fault tolerance and decentralized server processes necessary for enterprise systems.

Exchange's Directory Service is built to handle the very large number of objects necessary in an enterprise or worldwide system. Because its Directory Service is built on many of the recommendations of X.500, directory exchanges should be possible with other systems based upon X.500 standards. The directory update process is automatic within a site, and delta changes can be periodically sent and received with other sites or foreign X.400 systems. The Directory Service is also a transactional database, with transaction logging for roll-forward, roll-back restoration capabilities. Exchange Server also includes MS-Mail–compatible directory server and requester processes to allow MS-Mail to participate in a much more robust directory-management process.

####
Gateways

Microsoft Mail 3.x enterprise server edition does not ship with any of the most common gateways, with the exception of the AT&T mail gateway. Microsoft has written gateways from MS-Mail to X.400, SMTP (RFC 1154), Fax, MHS (Novell), MCI, 3COM, PROFS, and various proprietary networks such as CompuServe and AT&T. A gateway for MS-Mail has two components: the access component and the gateway program. The gateway access component is loaded on the gateway post office, and all downstream post offices, to provide the address space and mailbags for collecting mail to the foreign mail system. The gateway program interfaces with the foreign system to exchange mail. The gateway can also be used for directory synchronization of addresses to and from the foreign system. Many third-party gateways are also available to various systems.

> > Most of the gateways for MS-Mail use File Format API (FFAPI) messages to and from the foreign system. FFAPI defines the format of tags and data within the text messages that are exchanged between the two gateway programs. The Exchange AppleTalk MTA uses FFAPI to transfer messages to MS-Mail for AppleTalk networks.

Microsoft Exchange has connectors for Microsoft Mail, X.400 (1984 and 1988), and the Internet (via SMTP). The term connectors is used rather than gateways because they can be used to connect Exchange sites for mail transfer as well as directory exchange. These connectors are built into the Enterprise edition and are options for the standard edition. Other third-party gateways and connectors are available to link Exchange to legacy mail systems, such as DEC All-in-1, PROFS, MHS, and CC-Mail. Microsoft Mail post offices can utilize these connectors through gateway access components that route through the Exchange shadow post office. Later in this chapter, you can find a more detailed analysis of the connectors and gateways available in Exchange.

###
Exchange Messaging Architecture

As mentioned in previous sections, compatibility with current messaging standards is critical to the success of any messaging system in today's competitive market. Many messaging vendors have attempted to introduce proprietary messaging solutions with the hope that they will be adopted by the industry as a standard. This is probably due to the development time and effort that goes into bringing a messaging product to market. More recently, many vendors have adopted the posture of creating messaging products that have their architectures based on commonly adopted industry standards. This allows them to spend most of their development efforts on creating a competitive product that meets the needs of their customers, instead of trying to develop new standards that will not be able to interoperate with other systems.

Microsoft Exchange was built from the ground up, utilizing standards such as X.400, X.500, SMTP, and MAPI to create an enterprise-level messaging system. The architecture of Exchange is deeply rooted in these standards and takes advantage of Windows NT Server to ensure a powerful, robust, and scaleable messaging system. The various components that make up the Exchange Server architecture were designed to be mutually independent processes that communicate with each other through internal APIs. To understand the messaging architecture of Exchange Server, you must take a look at its components:

- The System Attendant
- The Information Stores
- The Directory Services
- The MTA/Connectors

Figure 20.4 shows a diagram of the core components of Exchange Server.

FIGURE 20.4. The core components that make up Exchange Server.

These components make up the core services of Exchange Server. The Exchange Server administration program is used to manage these services, as well as Windows NT administration tools such as Server Manager and Event Viewer. The flexibility of these components running as services can be appreciated only by those of you who spend hours administering current mail systems. For instance, you can perform a manual directory synchronization with users still logged onto the system without their knowing. This capability should help those mail administrators out there get home much earlier. Figure 20.5 shows the relationship of these services.

FIGURE 20.5. The Exchange Server component relationships.

These services work together to perform the following tasks:

- Monitor the state of server services and the links between them.
- Maintain the objects in the directory database for the organization and its sites.
- Control user and system access to directory objects and message stores.
- Provide users with a single point of access to manage, send, and receive messages.
- Receive, deliver, transfer, and route messages to the intended recipients.
- Keep all the servers within and outside the site up-to-date on directory changes.
- Monitor the replication process and take steps to resolve any conflicts.
- Perform general housekeeping tasks assigned by the administrator.

To help explain the roles of the various components that make up Exchange, lets assume that you are about to take your annual vacation. You are planning to drive your car across country to your secluded mountain cabin, which should take about a week. Along the way you receive help from various sources that assist you in getting to your destination. This example will be used in explaining the roles of the various Exchange Server components.

####
The System Attendant

The Microsoft Exchange System Attendant is the janitor of the Exchange Server. It carries out the tasks that the other services need not be burdened with, such as monitoring, logging, and general housekeeping. Do not discount the importance of this service, because it will help you keep tabs on the health of your entire organization. As you begin to work with Exchange, you will come to realize that the System Attendant is your friend and should be treated as such. The System Attendant performs the following functions:

- Works with the monitoring tools to determine the status of all the server services running within a site or the organization
- Performs the dirty work for a link monitor, sending and receiving the poll messages used to test the status of a connection between sites, servers, or other systems outside the organization
- Builds the system routing tables for a site on a scheduled basis
- Generates e-mail addresses when new users are added or imported into the site
- Maintains the tracking and system logs for the site

In the trip example, the System Attendant would be your travel agent. When you first came in to the travel office to plan your trip, the agent created a new customer account for you and wrote down your home address. Your agent would calculate the best route to your cabin and keep track of you as your trip progressed. Unlike a standard travel agent, the agent would have already driven the route to your cabin to make sure it was valid. If anyone needed to get in touch with you while you were driving, your agent would have a log of your current location and where you had been.

####
The Information Store s

Have you ever had a hard time finding a reliable place to stay when traveling? So have some of the messages sent on other e-mail platforms; they've gotten lost or stranded within the system. On the other hand, the Exchange Information Store is a reliable place for any message to stay. This is due to the transactional logging capabilities of the jet database engine underneath the Information Store component. A space-saving feature of the Information Store is the single instance of any message object, with pointers assigned to the message recipients. These features allow for better message storage and retrieval in heavy load environments.

Two different Information Stores are included: the public and the private. The private Information Store is the repository for all the user's messages, attachments, electronic forms, enhanced data types (sound, video, and such), and documents. The public message store contains public folders with the associated messages and electronic forms that can be replicated throughout the organization. Both the public and the private Information Stores are accessed and maintained through the Information Store service component, but they are stored as separate databases on the physical disks. Both message stores also have the following responsibilities:

- Monitoring storage limits established by the administrators, and notifying users when they are nearing or have exceeded their limits
- Enforcing mailbox and folder security to prevent unauthorized access to messaging resources
- Interfacing with the backup/restore engine to save copies of the Information Store, even when users are in the system
- Monitoring age limits for the Information Store, removing anything that has been deemed "outdated" by the administrators
- Monitoring the replication of public folder data, according to a predetermined schedule, to keep folder information updated within the organization

Very strict NT-based security prevents any one user from accessing objects in either message store that they do not have permission to. The security properties of each mailbox and folder in the Information Store are contained within the Exchange directory as an object permissions property. Any service such as the MTA or Directory Service cannot access the Information Store databases directly, but must pass all requests on the Information Store service.

In the vacation road-trip example, the Information Stores are the hotel desk clerks who check you in and out of each hotel along the way. They record your name, keep a log of your stay, and issue you the key to your hotel room. When you stay in a hotel, you have a private room that only you can stay in (but you can delegate it to others), and you have public areas where you can talk with other guests or catch up on some reading. The desk clerks would report back to your travel agent with the logs concerning your stay and would make sure that you check out at the predetermined time.

####
The Directory Services

One of the most important components of the Exchange Server messaging system is the directory services. The DS (Directory Service) and the DX (Directory Exchange) are responsible for managing many thousands of different X.500 standard objects contained within the directory schema. The Exchange directory contains information on all the objects within an organization, such as local and custom recipients, public folders, servers, MTA configuration, and distribution lists. The directory agents are responsible for keeping the directory up-to-date within the organization, and they also exchange directory information with external systems such as MS-Mail.

The Exchange directory is queried by users and system components to access information on the objects stored in the directory schema. A user might click the Properties button to get another user's location and telephone number, whereas an MTA service might query the directory to find the distinguished name of a recipient for a message. Neither users nor system components can access the directory database directly, and they must make requests to the Directory Service for any information on a directory object.

> > The current version of Exchange uses the standard X.500 database object schema but does not support object queries or modifications by way of the Directory Access Protocol (DAP) or the Directory Service Protocol (DSP). Future versions of the Directory Service probably will support these access methods as the Exchange product matures.

The Directory Service Agent (DSA) and the Directory Synchronization Agent (DXA) perform different tasks relating to the Exchange directory. The DSA is responsible for replicating the directory databases between servers within the site and other configured sites to ensure that the directory is consistent within the Exchange organization. The DXA synchronizes the directory with MS-Mail 3.x and compatible systems by acting as either an MS-Mail directory synchronization server or requester. As you can tell, the DSA and DXA are critical for maintaining up-to-date global address lists within Exchange and external systems. A more in-depth discussion of the directory services is found in the section Directory Management, later in this chapter.

As you continue driving to your cabin in the mountains, the directory services act as your phone book and atlas to provide you with information as you need it. You might need the phone number of the next hotel you are staying at to guarantee your reservation. Or you might need to consult your atlas for information about roads and points of interest ahead. The directory services ensure that the information in your phone book and atlas are current, and you can get updated copies of them from gas stations along the way.

####
The Message Transfer Agent

The message transfer agent within Exchange is the workhorse of the Exchange messaging architecture. It is primarily responsible for moving large volumes of messages from point A to point B by the quickest and least costly route. Assigning routing costs to the different connectors allows the MTA to find alternative routes if a connection is down, or to load balance across two connections with the same cost. The MTA can also be configured for message tracking to allow administrators to trace the route of messages between any number of recipients.

The Exchange MTA has the following core messaging components available for its use in transferring messages: Site Connector, Dynamic RAS Connector, Internet Mail Connector, Microsoft Mail Connector, and X.400 (1984 and 1988) Connector. The method by which the MTA selects a connector for message delivery is based on the recipient type (SMTP, X.400, and so on), the entries in the Gateway Address Routing Table (GWART), and the associated costs for each connector stored in the GWART. Because Exchange is built on the X.400 standard, the MTA is fully integrated with this connector. Each connector available to the Exchange MTA is discussed in greater length in the following section, Connectors and Gateways.

The Exchange MTA is always with you as you are driving to your cabin, because it is your automobile. Also assume that you have a "smart" car with a Global Positioning System (GPS) connected directly to your atlas, or Directory Service. Your car would already know your route, because the travel agent put it in the directory, and you would receive frequent updates from your travel agent about the road conditions ahead. Your car could alert you to change to different highways on the recommendations of your travel agent and could determine the route that would get you the best gas mileage.

You have now reached your cabin, and you settle down for a good night's sleep after all that driving. You recollect that your trip was made easier with the help of your travel agent (System Attendant), the hotel desk clerks (Information Stores), your phone book and atlas (Directory Service) and your faithful "smart" automobile (MTA). You now can sleep soundly with the knowledge that these things will be available to assist you in getting back home at the end of your vacation.

###
Connectors and Gateways

A system's capability to interchange messages with other systems is only as good as the service components assigned to talk to those other systems. Exchange includes connectors for the most widely used protocols and messaging standards, as well as those specific to internal Exchange messaging. A messaging system must also be able to provide solid internal routing of messages within the organization. In the following text you will read about each of the five connectors available in Exchange Server:

- Site Connector
- Dynamic RAS Connector
- Microsoft Mail Connector
- Internet Mail Connector
- X.400 Connector

####
Site Connector

The Site Connector component of Exchange was designed to be the easiest connector to set up and administer, while also being the most efficient way to move messages between sites in an organization. During configuration, the Site Connector asks the administrator whether to automatically set up directory synchronization between the sites and automatically configure the other site (if selected). This does not mean that you should always choose this connector to link your sites, because the requirements introduce some limitations. If you are considering using the Site Connector over a WAN, it is recommended that you use network sniffing and monitoring software to determine the effect it will have on WAN connectivity.

These are the benefits of using Site Connector:

- It is the easiest to configure because it uses RPCs; no transport configuration is needed.
- It is the most efficient message transfer because any one server in site A can transfer the message directly to any server in site B.
- It can be configured a bridgehead server for the remote site, or can establish a many-to-many relationship to remote servers.
- There is no need to schedule connections; message transfer is instantaneous.
- Messages do not need to be translated; they are sent in native form.
- It can take advantage of a high-speed backbone.
- Public folder replication can be almost instantaneous.

These are the drawbacks of using Site Connector:

- It requires RPC connectivity between sites.
- It cannot schedule connection times.
- It cannot control the message size sent through the connector.
- It requires high-speed network access, at least 64KB net available bandwidth to work efficiently.
- It requires both Exchange sites to run under the same security context, unless you use the override feature.

####
Dynamic RAS Connector

The Dynamic RAS Connector is actually a modified Site Connector, tuned to work with the RAS service over asynchronous modem connections. You must set up the RAS connectors at both sites individually and must also manually configure directory synchronization between sites. This connector is the most inexpensive way to connect two sites that have limited or nonexistent WAN communications.

These are the benefits of using Dynamic RAS Connector:

- It offers an inexpensive solution when a WAN is not present.
- It can schedule connect times and MTA parameters.
- Messages are not converted from their native format.
- It is a good solution for branch offices.

These are the drawbacks of using Dynamic RAS Connector:

- Message volume is limited by the speed of the connection.
- It can actually cost more per month than a WAN link if used for long distance.
- Asynchronous communications can be unreliable.
- It requires more complex route tuning if many sites are involved.

> > The Dynamic RAS Connector is an inexpensive way to provide backup routes between sites. For the cost of a modem and a phone line, you gain the ability to transfer mail if your WAN links go down. Just be sure to increase the cost of this connector so that it will not be used when all is working correctly. You can also add a link monitor action to start the RAS service on the determination that a link to another site has been broken. Thus, you'll give your boss the impression that you have taken care of the e-mail system when you were actually putting for a birdie on the 17th hole.

####
Microsoft Mail Connector

The Microsoft Mail Connector component of Exchange is designed specifically to connect to systems running MS-Mail for PC Networks Version 3.x and MS-Mail for AppleTalk Networks Version 3.1. Those of you who are administering MS-Mail networks today will find that the configuration and administration of this connector is very straightforward. Those of you who have had an MS-Mail network "dumped" in your lap, or who are unfamiliar with how MS-Mail works, should read on.

The MS-Mail connector is composed of four services:

- Microsoft Mail Interchange (MSMI)
- MS-Mail Connector ("shadow" post office)
- MS-Mail AppleTalk MTA (ATMTA) with associated Macintosh Gateway extensions
- LAN and asynchronous MMTA services

The MSMI is responsible for transferring and converting messages to and from the Exchange Server MTA and the connector shadow post office. This process involves conversion of MS-Mail native messages into Exchange message format, and vice versa. The MSMI can be considered the core service for connections to MS-Mail systems, because without its services the files would have to remain in their native formats, and the recipient would have to convert the message locally. The MSMI also makes it possible to have Exchange leverage existing gateways that are available only on MS-Mail, and it allows MS-Mail to use the Exchange Server for SMTP, X.400, and ATMTA gateway access.

The MS-Mail connector post office, or shadow post office, provides just enough of the MS-Mail database structure to allow for mail transfer to and from native MS-Mail post offices. It also allows gateway traffic to be routed through this post office and provides the MSMI and ATMTA with the appropriate directories for message transfer. The post office directories can be found on the share named maildat$ on your Exchange Server, but you do not need to perform routine maintenance on this post office.

> > Even though the Exchange MS-Mail connector shadow post office seems to have all the directories of an MS-Mail database, do not be tempted to create users or run any of the MS-Mail–specific utilities against this post office unless instructed by product support. One exception is that you can install gateway access components on this shadow post office.

The AppleTalk MTA service and its associated Macintosh native gateway extension make up the gateway from Exchange to MS-Mail for AppleTalk networks. The gateway components use FFAPI to communicate between the two systems, converting the messages to and from their appropriate native format. The two systems exchange messages by placing them in the \macgate\store\pctomac and \macgate\store\mactopc directories on the connector post office and picking up messages from their respective directory. Another program, the Directory Exchange Requester (DER), is similar to the directory requester from the MS-Mail connection gateway product, except that it is compatible with the Exchange dirsync message format and can filter addresses based on their network/post-office names.

> > Exchange Server 4.0 shipped with version 3.1a of the Macintosh gateway extension, which can cause problems in certain situations. You can replace this version with the newer version 3.1d gateway extension located on your MS-Mail for AppleTalk Networks version 3.1d server diskettes.

To facilitate mail transfer from the connector shadow post office to MS-Mail 3.x native post offices, the Microsoft Mail Connector has the capability to create and configure instances of external MMTAs. This means that you can replace your existing DOS, OS/2, or NT MMTA external instances with a more versatile Exchange version. These Exchange MMTAs can communicate with MS-Mail post offices via LAN, WAN, X.25, and modem connections. The configuration of the external MMTA services is done via MS-Mail connector MTA property page, eliminating the need for editing the external.ini on your post offices. Use of this MMTA requires you to reconfigure your routing on existing post offices to allow messages to be transferred "Direct via DOS drive" to the Exchange network/post office, but it proves to be more reliable in the long run. This routing change and MMTA configuration is also necessary before you begin any migration from MS-Mail to Exchange so that migrated users will still receive mail addressed to their old post-office address.

####
Internet Mail Connector

Of all the connectors available on Exchange Server, the Internet Mail Connector (IMC) is the one most of you need to configure as soon as you get your Exchange Server installed. It provides connectivity to the Internet and UNIX sendmail or POP3 mail servers using the specifications in RFC #821 and RFC #822. The IMC operates as a smart mail host, and it allows for message attachments to be sent and received in either UUENCODE or MIME format.

I know that if you are a current MS-Mail 3.0a SMTP gateway administrator, you will want to get your existing MS-Mail post offices changed over to use the IMC immediately. This change will enable your MS-Mail users to send and receive MIME-encoded attachments seamlessly, without any change at their desktop. The steps necessary to perform this conversion are outlined in Chapter 24, "Interfacing with Other Mail Systems."

Because the IMC is a connector, it can be used to connect one or more Exchange sites and allow for directory replication and message transfer over the Internet or private network. Even though the X.400 Connector is a better choice for directory replication, this type of configuration is possible. The IMC also has the following features:

- The capability of sending and receiving rich-text messages, configurable by the administrator and the users
- The capability of configuring one server IMC for inbound traffic and another server IMC for outbound traffic, to load balance on mail systems with a high volume of SMTP mail
- Configuration of default attachment encoding methods and interoperability parameters—this feature can also be set on a per-domain basis
- The capability of sending encrypted messages between Exchange sites if keyserver is installed

> > By default, the Exchange IMC is configured to allow Rich-text messages to be sent over the Internet. This creates an attachment, winmail.dat, that contains the Rich-text formatting codes and any file attachments. To disable this option for default connections, use the interoperability button in the IMC general properties page and set the Send Rich-text setting to never. You can then configure Rich-text capabilities on a per-domain basis for messaging systems with the appropriate support.

####
X.400 Connector

The X.400 Connector for Exchange is tightly integrated with the Exchange MTA, which is compatible with the 1988 X.400 MTA specification. Because Exchange is built on X.400 messaging recommendations, very little conversion is needed to transfer mail to other X.400 systems. Currently, Exchange X.400 connections are supported on the following OSI transports:

- TP0/X.25
- TP4/(CLNP)
- TP0/RFC 1006 to TCP/IP

The X.400 Connector supports many of the standard textual message body parts, such as International IA5, T.61 (Teletex), ISO 6937, and ISO 8857-1. This support ensures that mail addressed from foreign-language messaging systems will have most of characters kept in a displayable format. The X.400 Connector also supports file attachments using the following binary body parts:

- BP9 provides support for embedding and forwarding messages based on the X.400 standard.
- BP14 (1984 specification) provides support for simple transport of binary attachments.
- BP15 provides support for the 1988 X.400 standard for sending attachments.
- File Transfer Body Part (1992 specification) includes file name, size, properties, and other information.
- Other X.400 body parts not listed above are converted to MAPI binary attachments.

When you define a connection to another message handling system via the X.400 Connector, you can specify the properties for the body part conversion and the version of X.400 (1984 or 1988) to use for that connection. This step ensures that your X.400 Connector can communicate and transfer mail and attachments to most X.400 message handling systems.

The X.400 Connector can also be used to connect two Exchange Server sites, giving the administrators a higher level of control over the behavior of the MTA than with other connectors. They can schedule times for activity, control message size, and assign cost routing and be used for directory replication between sites. Directory replication can only occur over the X.400 Connector when the connected site property page is correctly defined. You can even connect Exchange Server to an MS-Mail network over X.400 given that the MS-Mail system has the X.400 gateway installed and running.

###
Directory Management

As mentioned earlier in this chapter, Exchange implements the directory structure recommendations specified in X.500 but does not support the X.500 directory access recommendations in the current version 4.0 release. The Exchange Server Directory Service stores all the objects defined by the X.500 object classes in an X.500 schema and tracks each object's attributes and the relationships to other objects. The Exchange directory does differ from the X.500 recommendation in the directory names of the objects in the schema. Table 20.1 shows how those names map to the X.500 name space.

Table 20.1. Exchange Server to X.500 Name Space mappings.

Exchange Server | X.500 Name Space
Country | Country
Organization | Organization
Site Name | Organizational Unit
Exchange Server Recipient Container | Common Name
Exchange Server Recipient | Common Name

The Exchange Server also adds object classes not found in X.500 to the Directory Service to support objects such as customizable fields, alternative recipients, additional phone numbers, and organizational chart data. Information from other databases within the organization can be used to populate the directory, enriching the value of the directory as a central repository of company information.

####
Directory Service Agent

The Directory Service Agent must keep tabs on the status of all the objects within the X.500 schema. Any changes to the local directory database must be copied to all the other servers within the same site immediately. Additionally, these changes must be propagated throughout the entire organization at the next scheduled replication time with any connected sites. The DSA is also responsible for interfacing with the backup/restore process to allow online backup of the directory database.

Any and all inquiries to the directory database must pass through the DSA to keep the integrity of the database intact. The DSA constantly monitors the status of the directory database, and it performs recovery if necessary in the case of corruption or loss of power to the system. Future versions of Exchange will provide support for services such as Directory Access Protocol and Directory Service Protocol to allow for other systems to query and modify the directory objects. Another up-and-coming directory access method, Lightweight Directory Access Protocol (LDAP), will allow various "light" e-mail clients and Web browsers to query for information in the Exchange X.500 directory.

####
Directory Synchronization Agent

The Directory Synchronization Agent (DXA) is responsible for the MS-Mail–compatible directory synchronization process. This allows the Exchange Server to function as either a directory synchronization server or a requester utilizing the Microsoft Mail version 3.2 for PC Networks directory synchronization protocol to exchange directory updates with other systems. This allows companies to add extra capacity to their current MS-Mail dirsync process and gain control over which addresses are sent to which post offices. The capability of the DXA to act as both a dirsync server and a requester will help alleviate some of the problems for large implementations of MS-Mail in enterprise environments.

###
Groupware, E-Forms, and Scheduling

The first time I heard the word groupware, I pictured a group of users all huddled around a PC fighting for control of the keyboard. I have since seen the light, and I now understand that groupware is generally defined as "The management and sharing of information to allow a group to be more productive, allowing for collaboration and coordination of resources within the group." Although this definition might be a little lacking in specifics, it should get the general point across.

Exchange Server integrates many aspects of groupware, with support for discussion threading applications, group scheduling, data replication, electronic forms, e-mail, information repositories, and information-tracking databases. This discussion touches on the three most important features that allow Exchange Server to provide groupware functionality, allowing users and administrators to build customized solutions for the ever-changing business environment.

####
Public Folders

A public folder can be many different things to many different people. It can be a repository for documentation on a soon-to-be-released product, with technical writers checking in and checking out the different chapters for the various manuals. It can also be a threaded discussion database that allows users to openly discuss their viewpoints on new ideas from upper management for new products. Or it can be a forms library for Human Resources, enabling users to compose items such as vacation requests that would be automatically routed to their manager for approval. As you can see, public folders are extensible directory objects that can contain various types of information and that can be available throughout the organization through the replication process.

Next, you'll examine a simple example of a public folder that solves a simple business need. I know that many of you currently subscribe to at least a few Internet mailing lists. If you are unable to check your e-mail for even a few days, you are greeted by multiple messages from the previous days all mixed in with your normal allotment of messages from your manager and coworkers. Wouldn't it be nice if you could have those messages stored in a folder to enable you to browse them at your leisure? Setting up a public folder to perform this function is easier than you think.

First, log on to an Exchange Client and access the public folders from the tree view. Create a new public folder, being sure to set the default permission to Create to allow for new messages to be put in the folder. You can set up any custom views at this time. Then find out the SMTP address of the folder by adding the folder to your personal address book, and then view the e-mail Addresses tab from the properties of the folder. Next, send mail to the listserver address subscribing the SMTP address of the public folder. Typically, you can do this with the command subscribe list email-address for most lists. Some listservers require the subscription to come from the person subscribing, so you must send mail "in behalf" of the folder. To do this, compose a message and select the From selection on the View menu, and enter the SMTP address of the public folder. After the folder is subscribed, you should start to see messages accumulating in the folder. Other users should also be able to browse the folder. This technique is much more efficient than having numerous individuals subscribing to the list individually. If you need more detailed instructions than are provided here, go to Microsoft's Web site in the Exchange product section at http://www.microsoft.com/exchange.

####
Electronic Forms

Electronic forms are based on the Visual Basic 4.0 language. You can create them by using the Electronic Forms Designer (EFD) included on the Exchange Client CD-ROM. I suggest that you take a look at the sample applications Microsoft has provided. You can find them on the samples share located on your Exchange server. The versatility of the applications created with EFD can be utilized for many different business solutions.

The discussion folders included in the sample applications are one example of a collaborative application. The customer-tracking application is an example of an information-tracking application for managing client data. I think that the chess application is just plain fun, and it shows what you can do with a crack programming staff. Creating custom forms and applications with EFD is a snap, with an intuitive user interface that one can learn in very little time. Administrators should not be wary of their users' getting their hands on EFD, because EFD can enable them to create their own applications to solve various business needs. You should control the deployment of these applications, though, and you might want to set the proper permissions on the root folder to control the creation of public folders. I suggest that you set up a folder where users can submit new applications for review before placing them into production.

> > The EFD application creates native VB 4.0 source code just before you compile and load the application into the Exchange Server. You can extend the functionality of this code by adding your own functions or procedures, such as database queries to a SQL server. But after you have edited the source code, the EFD will be unable to open and modify that application. If you are comfortable with the VB 4.0 language, I say happy coding. If you are more comfortable with EFD, look for third-party add-ons to extend your applications.

####
Group Scheduling

The Microsoft Exchange Client includes a copy of Schedule Plus 7.0 for group scheduling, contact management, and project tracking. The Schedule Plus client is optimized for both remote and local access, working primarily from the local file with two-way replication of updates to the Exchange Server private store. Users can view each other's schedule files (assuming that they have the proper permissions), invite others to meetings, schedule resources such as conference rooms, and send messages—all from the Schedule Plus client.

The functionality of Schedule Plus can easily be extended using Electronic Forms Designer to create "schedule-sensitive" applications. One such example that's included with the sample applications is used to notify others of vacation or sick time. This example application demonstrates how EFD applications can be extended to interface with MAPI-based applications to promote collaborative efforts by users. All the data you need in order to create a project management application is contained within the Exchange Client. It is your job to create that application and put it to work in your organization.

###
Summary

Throughout the evolution of messaging systems, the industry has realized the need for reliable standards to allow for interoperability among systems. This realization is demonstrated by the efforts of the ITU and ISO to create the X.400 and X.500 recommendations for messaging systems. Members of the Internet community also recognized that they needed standards for exchanging messages, which prompted them to cooperatively develop the SMTP standard that we still use today. Many messaging vendors have attempted to create their own de facto standards, but have realized that their customers want messaging systems that can seamlessly communicate with other systems.

Microsoft brought these lessons to the drawing table, and decided to develop a new messaging system that embraces these widely adopted standards. Exchange Server was designed to capitalize on the strengths of the client/server architecture built into Windows NT to address the needs of large organizations. Although the product took much longer to develop than expected, the final result is a robust, secure, and scaleable messaging system built on an X.400 engine with X.500 directory services.

The Exchange Server includes connectors that allow it to exchange messages with SMTP, X.400, MS-Mail, and other third-party systems. Future enhancements to Exchange will allow other systems to query and modify the X.500 directory objects contained within the database schema. With such a robust directory database, you can expect future products to utilize this information to extend their own functionality.

The success of any messaging system is also tied to user acceptance of the client components. The redesigned user interface of Exchange Client, and its cross-platform conformity, are winning over new users every day. The Exchange Client and Server use MAPI to communicate over Remote Procedure Calls to reduce LAN traffic and enhance remote connectivity. The groupware features built into Exchange allow organizations to build customized applications to promote user collaboration, and to distribute business information throughout the enterprise.

The next chapter takes you through the process of planning, testing, and implementing an Exchange Server messaging solution in your organization. Key topics include a discussion on naming conventions, server hardware planning, site planning, connector selection, installation tips, and post-installation testing.