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.
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.
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.
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.
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:
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.
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.
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:
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:
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.
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.
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:
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.
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:
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.
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.
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:
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:
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 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:
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.
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:
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.
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 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.
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:
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:
These are the drawbacks of using Site 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:
These are the drawbacks of using Dynamic RAS Connector:
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.
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:
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.
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:
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.
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:
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:
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.
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.
| 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.
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.
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.
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.
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 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.
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.
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.
