by Wesley H. Peace III
Microsoft Exchange Server is the next generation in LAN-based electronic mail. Microsoft is the first of the mainstream electronic mail providers to offer mail that is based on a client/server model. Popular electronic mail programs such as ccMail and MS Mail are based on a shared file system structure rather than a database.
Although Lotus Notes is popular in the groupware arena, it has not been considered a leader in electronic messaging; this, however, is starting to change as they merge their Notes mail product with ccMail functionality
Exchange Server supports the two popular electronic mail addressing protocols, SMTP (which is used across the Internet) and X.400, in addition to the native Microsoft format used by Microsoft mail.
Exchange was first released as two products, The Exchange client that shipped with Windows 95, and the Exchange Server. This has caused considerable confusion when someone is speaking about Exchange. However, Exchange as a product is the Exchange Server and its supporting Exchange client, which is not the same as the Windows 95 version.
To resolve some of the confusion, Microsoft has renamed the messaging delivered with its operating system products, and specifically the Windows 95 Exchange client, Windows Messaging.
The Exchange Server and client provide a true client/server messaging strategy which is key to Microsoft's messaging strategy.
Earlier Microsoft e-mail applications have been based on a shared file structure. Microsoft Mail, one of the most popular e-mail applications on the market today, is based on a series of shared files and directories located on a hard disk. Although the simplicity and network operating system independence of the implementation made the program popular, the implementation is based on a passive file structure. All interaction and movement of mail is controlled by the client. It is a single post office solution that does not support delivery of mail outside of its post office. To deliver mail outside of the post office requires the addition of an external process, typically running on a separate machine. Large MS Mail (and ccMail) installations have not only the post offices, but machines running support applications such as External and Dispatch to keep the post offices and directories synchronized.
Exchange, as previously mentioned, has been designed around a client/server architecture. The Exchange server has been implemented as a series of NT multithreaded applications accessing a client/server fault-tolerant database. The database logs transactions to assist in database recovery in the case of system failure.
In prior LAN-based mail systems, MS-DOS based gateways and message transfer agents (MTA) that moved messages between post offices have been required to support multiple servers/post offices. This is not a requirement with Exchange. Exchange is scaleable and has been designed to take advantage of NT Server architecture and to run the MTA processes as services. Using this connector architecture, Exchange can support communications between organizations, servers, and sites from a single platform. This feature minimizes the hardware requirements as well as the points of failure in an implementation and greatly increases the scaleability of the Exchange product.
The Microsoft Exchange architecture is centered around industry standard protocols and a client/server database. Exchange has been in development for more than two years and represents the collective effort of not just the Microsoft Exchange team, but hundreds of beta testers. Extensive feedback from these testers has given Microsoft a product that in many ways was designed for the industry by the industry.
Before the release of Exchange, Microsoft's primary electronic mail product was based on a flat, shared file structure in which the client sent and received mail.
This architecture moves all processes into the Exchange Server and eliminates the need for additional hardware components to process mail. Exchange implements the electronic messaging architectural components defined by CCITT, User Agent (UA), Message Transfer Agent (MTA), and Information Store (IS) to build a high-performance, extendible multi-threaded application. Because industry standard protocols are used, connectivity to other compliant electronic mail systems is much more easily implemented.
Exchange has changed this to a client/server architecture based an X.500-compliant directory structure and support for X.400 addressing. Messaging between the Exchange servers and client is handled by remote procedure calls (RPC). When the server is operating in an NT domain, it uses NT security to validate access to the user's mailbox. This minimizes the need for the user to remember multiple passwords. RPCs enable Exchange to function over most popular protocols such as NWLINK (IPX/SPX), TCP/IP, and NetBEUI.
Because of its architecture, the Exchange Server is one of the first messaging solutions available in the LAN environment that offers scaleability and extensibility for most user environments.
Exchange is designed to take advantage of industry standard protocols. Exchange conforms to the 1984 and 1988 X.400 specification, which is an ISO standard for electronic mail addressing. It is integral to Exchange and is used for all internal addressing; it is also supported externally. The X.400 protocol model is composed of three components: the message transfer agent (MTA), the user agent (UA), and the message store (see Figure 3.1).
Figure 3.1. Basic X.400 messaging architecture.
The Microsoft Exchange Server architecture supports all of these components. The Exchange Server can support multiple MTAs, such as an internal MTA to communicate within the server and to support daily use of the server, X.400, MS Mail, and SMTP MTAs, to name a few. The Exchange message store is composed of two distinct units, the public store and the private store. The user agent part of the model is represented by the MAPI clients used to access the information/message store. A new concept to Microsoft messaging is Exchange's capability to support any MAPI-compliant client supporting the published API set. A number of vendors such as Lotus and Crystal Computer Services, Inc. have announced products capable of accessing the Exchange information store.
Exchange also uses X.500 internally, the ISO standard for directory services. Internal objects conform to an X.500-like directory specifications. It is not fully compliant because support for the X.500 directory access and directory systems protocols is not implemented. Microsoft recognizes the importance of these protocols and has promised compliance in future releases. In the meantime, you can obtain support for lightweight directory access protocol (LDAP), a subset of DAP, from third-party providers.
The X.500 directory protocols are an emerging component in the Internet community. There is currently no centralized method to obtain a electronic mail ID of a user; the directory protocols are supposed to serve as a central repository for directory information. Disparate systems can access directory information through the directory access protocols. It is expected that these directories will not only house information on individuals, but on objects within an organization as well.
Although they are not critical for the implementation of Exchange Server, Microsoft is actively working on incorporating X.500 directory services into its products. Future versions of NT will be based on these directory services.
Exchange adheres to an organizational structure based around a central administration model. The largest administrative unit in this model is the organization, which includes all servers in the messaging infrastructure, both local and remote. Typically, this organization equates to the company or organization name.
Servers in an organization are grouped by sites. A site is a group of servers that share the same directory information and communicate over high-speed, permanent and synchronous connections. Directory changes and updates in a site are automatically replicated to all servers; thus permitting the sharing of a single organizational directory based on a merger of all the sites directory information.
You do administration tasks for the Exchange organization from a single interface (see Figure 3.2), the Exchange Administration program, which is installed with the Exchange Server.
Figure 3.2. The Exchange administrative interface.
Microsoft distributes both the server and client software on a set of two CDs. Two versions of the product are available: the Enterprise Edition with all the connectors and the Standard Edition, which contains no connectors. You can also purchase connectors separately.
Before Exchange, connecting electronic mail systems that ran different protocols required a gateway. The Exchange server uses a connector. A connector is an Exchange product developed by Microsoft that supports not only the gateway function, but routing as well.
The Microsoft Exchange Server uses a database with transaction logging to manage messaging. The user agent also supports multiple information services, one of which is the Exchange Server. When the client is used in conjunction with the Exchange Server, users connect to the information store to send and receive mail. This client-to-server communication is handled by remote procedure calls (RPC), which permit connectivity possible over all protocol.
You must install the Exchange Server in a Microsoft Windows NT domain. After it is installed, it is integrated into User Manager for Domains (see Figure 3.3), which can now create the Exchange mailbox as new accounts are created. In an NT domain, Exchange is designed to use the NT security to validate logins. This permits the user to log in once to the NT domain, and allow the token generated by the NT login process to be used to access the Exchange server.
Figure 3.3. New User Manager for Domains Exchange.
The Exchange Server takes advantage of the underlying NT domain architecture for user authentication. A single password can be used to access both the NT domain and the Exchange Server. This integration with the NT domain alleviates the need to provide a separate password to access a users mailbox; but requires that the Exchange Server be installed in an NT domain.
To some, this single login feature appears to be a problem, but the Exchange server actually uses the NT security model to ensure that the correct user is accessing the mailbox.
If more than one user uses a workstation, you can configure the client to prompt for the user name, password, and domain. To do this, select Tools | Services, and then Microsoft Exchange Server. Click Properties and the Advanced tab. Uncheck the Use network security during logon box.
Integrating with Exchange is not a problem because it becomes impossible to "spoof" Exchange and open up someone else's mail. Because authentication occurs "under the covers," a rogue user cannot get his hands on it to defeat security. When a mailbox is created, it is tied to an NT domain account. Only that individual (or someone he has explicitly assigned permissions to) can now access that mailbox.
Conversely, the Exchange administrator can create the NT domain accounts when he or she creates the Exchange user. This method is typically used to add a single user (see Figure 3.4) but groups of users can be added using the import option.
Figure 3.4. Adding an NT account via the Exchange.
Although Exchange must be installed on NT servers, this does not preclude the use of Exchange in a Novell NetWare environment. When installed in this environment, the Exchange server must support IPX/SPX and gateway services for NetWare.
Exchange Server is comprised of a series of NT services, databases, and log files, which can be divided into core and optional components. Each of the core components are installed and configured during the installation process. All core components are configured to start automatically. These components provide the primary messaging services; message transfer, delivery, and storage, as well as the Exchange directory services. Optional components are also NT services. They provide connectivity and support for communications between multiple Exchange servers and other electronic mail systems. Security services are also considered an optional component.
The following are the Exchange services:
You use the Microsoft Exchange Administrator, installed on the Exchange server or an NT workstation, to configure each of these services (see Figure 3.5).
Figure 3.5. Exchange Server services.
Each of these Exchange Server services is discussed in the following sections.
The default location for the administrator program is in the Exchange executable directory \EXCHSRVR\BIN. When started, the Administrator program presents a graphical view into the Exchange organization (see Figure 3.6).
Figure 3.6. The Exchange Administrator structure.
The Exchange Administration program is the only Exchange component that does not require NT Server to run. The current version will run on NT workstation, but will not run on either Windows 95 or Windows for WorkGroups. Installing this component on an NT workstation enables the Exchange server organization to be managed from a designated administrative console.
The format of the display is hierarchical, showing all objects, users, and resources in the organization. The display is split into two areas. The directory objects are on the left. They represent all components in the organization. The container area is on the right. This area displays the current selected object. To view detailed information about an object in the container area, highlight each object. You can view the properties of each object from the File menu or select the object and press Alt + Enter. The interface itself resembles the Windows 95 Explorer.
A key element of the Exchange architecture is the directory. It maintains all information about the organization's resources and users. It also supports mailboxes, custom recipients, public and private folders, distribution lists, servers, connectors, and any other add-ons to the Exchange server. Other components of the server use the directory to complete their jobs. The server supports OSI protocols for internal messaging. A native X.400 address is created for all new objects that are added to the database. Internally, Exchange stores the definitions for these objects in an X.500-like structure. When users are created, three addresses are created: an X.400, an MS Mail, and an SMTP.
To change the default root component of the Exchange, select Site Addressing from Site Configuration and edit the site addressing property for each address.
Changing the default Site Addressing can effectively hide the existence of the Exchange servers and support a uniform addressing organization address for the entire organization. This is normally done with UNIX Sendmail and the sendmail.cf file, but with Exchange, the process becomes simple.
Changing the default site addressing offers a way to secure the Exchange server and NT user accounts from intruders and create user-friendly names for the recipients.
Microsoft Exchange uses objects to describe the structure of the organization. All items in the Exchange hierarchy are considered objects. This includes recipients, distribution lists, servers, and the messaging infrastructure itself.
The directory also supports special objects called containers. A container is an object that contains other objects and containers. The objects or recipients within the organization are addressable and maintain entries in the directory database. If there are multiple sites within the organization, the information about these recipients is replicated to the directory database on each server. This is how the global address list (GAL) is built.
The Exchange directory is comprised of two key elements: the directory database and the directory service. The database engine is based on a highly optimized version of the Access database engine, the blue-jet engine. This information store is located by default in \EXCHSRVR\DSADATA\DIR.EDB.
Although Microsoft uses an Access database structure, you cannot use Access to manipulate or view these tables. Using Access can destroy your Exchange site. If you want to view this information, use Crystal Report Writer for Exchange or a tool designed specifically to access the database.
The directory service (DS) is a Windows NT service that manages information in the directory database and handles requests from users, services, and applications.
Users and administrators can access and manipulate directory services. The Exchange administrator is responsible for creating, deleting, and changing directory objects as well as for populating the address book. When a new object (recipient) is added to the server, an entry is created in the server address book. This, in turn, is propagated to the site and then to the global address book (GAL), where it is available to all users in the organization. It is the responsibility of the DS to manage this process and to ensure that the integrity of the directory and its structure is maintained.
Users access the directory through the Exchange server address book. Although users cannot modify the address book, they can create custom subsets of entries of the address book as well as create new entries in their own personal address book (PAB). Exchange service processes can manipulate the database as well as third-party applications such as Crystal Report Writer for Exchange Server.
An access control list controls access to Exchange Server directory objects. The objects are assigned permissions when roles are established in the Administrator program for each user or service. To view the dialog box that displays the roles, select Tools | Options. Then select the Permissions tab from the Administrator menu and check Display rights for roles on Permission Page.
After roles have been defined, the roles for directory services are displayed in the Directory Service dialog box (see Figure 3.7). You do not always need to add permissions to every object within the Exchange architecture because permissions can be inherited from objects higher up in the hierarchy.
Figure 3.7. Directory services permissions display.
Objects within the Exchange X.500 directory structure are divided into distinct groups with distinct properties such as organization, site, and configuration (see Figure 3.8). This grouping permits permissions to be set based upon the group characteristics. Just as with the NT server permissions, permissions are propagated downward in the tree. This concept is known as inheritance. Because of inheritance, you must consider the consequences of changing a role when you set permissions. You need to understand the following rules before setting permissions in your organization:
Although the Exchange Server enables you to change the organization name, as with NT Server, this does not change the underlying name. The organization name is tied to each object within the Exchange server. Changing the organization name effectively invalidates all of the underlying objects. The correct procedure to follow is to reinstall the Exchange Server.
Figure 3.8. The Exchange organization structure.
Being able to dynamically assign permissions in Microsoft Exchange closely follows those same capabilities within NT Server but should not be confused with NT Server. An Exchange administrator does not have to be an NT Server domain administrator. However, a person who supports both functions obviously has an administrative advantage. When assigning permissions to a user, remember that when new accounts are created, it is the responsibility of either the Exchange or the NT Server domain administrator to create the accounts. To ensure no problems occur, assign appropriate permissions ahead of time.
The Microsoft Exchange information store connects the server and the client. You can install either a private information store, a public information store, or both on the server. The default is for both to be installed on the server. Each has a 16GB storage limit. Use the traffic and usage requirements of the organization to determine how best to define server utilization.
The information store is also responsible for delivering mail to users on the same server as the sender, and forwarding mail to the MTA for delivery to users who are not on the same server.
The Exchange Server information stores are database files. They are based on a fault-tolerant architecture with transaction logs used to process messages and support rapid recovery in the case of system failures. Transactions are written to the transaction logs and kept until the Exchange server is backed up. This permits data in the transaction logs to be used to reconstruct data.
The concept of single instance store has also been introduced with Exchange Server. Single instance store is defined as a single copy of a message sent to multiple recipients and saved only once within the information store. Each user has a pointer to the location of the message within the database.
Because Exchange Server uses single instance store, the entire server is restored when the default ntbackup utility is used to recover a single mailbox. This is not a bug, but a result of the benefit of single-instance store. As an alternative, you can use brick backup to back up individual mailboxes. However, using brick backup can increase the storage requirements for backup by 50 percent or more. Several vendors are currently working on brick-backup capability.
When you install Exchange Server, the default ntbackup is replaced with a custom version that is designed to support backing up the Exchange server while it is in use.
Most features are common between private and public information stores. The most important ones are discussed next. An overview of the information stores follows.
Figure 3.9. Private information store permissions.
Figure 3.10. Public folder resources.
The private information store contains the mailboxes for all users on the server. Each server that supports mailboxes has at least one private store. When a new user is added, the user's mailbox is created in the private store. Information about this new mailbox is passed to the directory service, and the global directory is updated. Global settings for the private information store such as aging, storage limits, permissions, and use by mailbox are set from the Private Information Properties page in the Exchange Administrator (see Figure 3.11)
Figure 3.11. Private information store properties.
The personal address book (.PAB) file for each user is not maintained in the private store as it was with Microsoft Mail. It is completely separate and can reside in several places.
A default installation of the Exchange Server uses the private store to save messages. This imposes a 16GB limitation on the size of the information store for all users. Although this limitation can cause problems in some instances, it is not the only method of saving messages. Users can also save their messages in personal folders, .pst files located either on their local hard disks or in a designated area on the file server. The choice of storage mechanism should be left to the requirements of each organization.
The Exchange Server has a 16GB limit per information store. This places a 16GB limit on the size of each information store. You can create additional private information stores on a server, but this is not recommended because administration can become unwieldy.
You can use private storage (.PST) files to save mail messages and bypass the limitations of the information store. Because you lose administrative control using .PST files, it is up to the user to manage and back up the files unless they are saved in home directories on the server.
In addition to user mailboxes, the private information store also contains other addressable recipients such as distribution lists and custom recipients. A custom recipient is any object with an e-mail address that does not reside within the Exchange organization.
The public store is the other location on the Exchange server in which you can store information. The primary difference between the public information store and the private information store is how the data is saved and used. There are more options available for the public information store than the private. Configurable options, in addition to those already discussed, include the following:
Information in the public stores is stored in folders that are shared among users. The public store supports replication of these folders among Exchange servers.
The message transfer agent (MTA) is a standard component of an electronic mail system that handles the routing, conversion, address mapping, and message transfer between systems. In Exchange, the MTA handles the routing of messages between Exchange servers, information stores, connectors, and gateways. It is a vital part of the Exchange architecture.
The Exchange MTA is configured at the server level of the Exchange Administration program (see Figure 3.12).
Figure 3.12. Exchange MTA configuration.
The Microsoft Exchange Server MTA can also be used to connect to X.400 MTAs that comply with the ITU (formally CCITT) 1984 and 1988 recommendations. As with other core components of the Exchange Server, the MTA is implemented as an NT service.
The MTA must have an accurate routing table in order to transfer mail between systems. Normally, the routing table is rebuilt once a day. This parameter is configurable and can be done manually from the Message Transfer Agent Property page. It is a good idea to manually generate this new routing table when changes to any Exchange routing component are made during business hours. This forces the new routing information to be propagated to other servers within the site.
The system attendant's role is to support the maintenance of the Exchange server. Without it, the other Exchange services do not run.
The system attendant checks the directory consistency on each server in the site and performs updates as required. It also reclaims space from deleted directory objects. If monitoring tools are created, the system attendant gathers information about the services being monitored and delivers it to the tools. Additionally, the system attendant monitors the state of the messaging connections between servers and responds to link monitor mail. The system attendant can act as an agent for other applications to support message tracking and accounting.
At preset times each day, the system attendant rebuilds the site routing table and generates foreign e-mail addresses such as X.400, Internet Mail, and any gateway for new recipients. Set configuration parameters for the system attendant from its property page in the Exchange Administrator program. This page is in the container area of each server in a site (see Figure 3.13).
Figure 3.13. Exchange server System Attendant.
As new users are added to the site, it is the system attendant's responsibility to create the e-mail addresses.
Directory synchronization is an optional Exchange service installed as an NT Server service. It is used to synchronize the directories between systems using the Microsoft Mail DirSync protocols such as Microsoft Mail 3.x and AppleTalk Mail.
The purpose of the directory synchronization protocol is to synchronize the directories on all post offices in an MS Mail network. Servers participating in this process can be either directory server post offices or directory requester post offices. One post office in the organization must be designated as directory server.
The directory server collects the directory address update information from the servers participating in the directory synchronization process. It compiles them and issues new global address list (GAL) updates to all requester post offices.
The DirSync process is a scheduled process controlled by the Microsoft Mail Dispatch and External programs.
The Exchange server can function as either the requester or server but not both. Organizational requirements determine how it is used.
When directory synchronization is configured, the administrator must specify an import and export container. The import container stores imported Microsoft Mail addresses. The export container holds the Microsoft Exchange recipients to export to Microsoft Mail.
You can control what addresses are exported to MS Mail by setting trust levels for all recipients. The only recipients that are exported are those with trust levels equal to or lower than the trust level configured in the connector.
The key management server is installed as a separate server within the Exchange server organization. It supports advanced security features such as digital signature and data encryption. Install this optional Exchange server component to manage security information used to digitally sign and encrypt messages that are sent between users within a Microsoft Exchange server organization.
Data encryption is the process of scrambling data to ensure it can be read only by the person to which it is sent. Both encryption and decryption must be supported. The key management server provides these advanced security features and supports the following services:
An organization with a single server requires no connectors unless it is connected to other messaging transports. Connectors are used to transfer messages between sites, organizations, and foreign systems. The Microsoft Exchange Server offers a number of connectors to assist in building enterprise class networks, including the following:
The shadow post office does not support local mailboxes or MS Mail clients. To support MS Mail users in an Exchange environment, either use the Exchange client or install an MS Mail post office.
External is not required to talk to LAN-connected MS Mail post offices. The MS Mail connector performs all functions of the External program. When connecting to MS Mail post offices over X.25 service, the External program is required to complete the connection at the distant end.
When you are integrating the Exchange server in an MS Mail environment that sends to MS Mail users via SMTP, turn MIME encoding off to avoid garbage at the end of user messages.
The Internet Mail connector complies with IETF RFC 821, 822, 1123, 1521, and 1522.
A smarthost mail server typically handles the routing of all messages within a domain. The concept of a smarthost originated in the UNIX environment where addressing and manipulation of mail headers is handled by a single server. This minimizes the requirement to modify multiple servers and centralizes administration of the domain database. Although it is not required in the Exchange environment, the functionality is supported.
Connectors are optional. An Exchange site with a single server has little need for connectors unless they require access to resources outside of the site. After you add another server or site, you must add a connector to support communications between the sites.
Microsoft offers the Exchange server in two models: the Standard Edition, which has no connectors, and the Enterprise Edition, which ships with all connectors. You can also purchase connectors separately. To determine which model of Exchange to install, examine the cost trade-offs between buying the Standard Edition with the required connectors or the Enterprise Edition with all connectors.
The Microsoft pricing model requires that when you are configuring a multiserver organization supporting connectors, the connectors or licenses must be for each server.
Schedule+ can function as a stand-alone product. However, when it is used with the Microsoft Exchange Server, it extends the concept of group scheduling. The product is tightly integrated with the Exchange client and with the Exchange server. It has a hidden public folder, Schedule+ Free/Busy, that supports replication of user scheduling among Exchange servers. This facilitates scheduling group meetings and managing static resources such as conference rooms, audio/visual equipment, and vehicles.
The Exchange Server administrator needs to do very little to support Schedule+. The Schedule+ Free/Busy Folder is at the organization level of the Exchange hierarchy in the Folders|System Folders tree (see Figure 3.14).
Figure 3.14. The Organization | Folders | System Folders tree.
To display configurable parameters for Schedule+, highlight the displayed Schedule+ object and select File | Properties from the Administrator menu.
By default, the replication schedule for Schedule+ conforms to the schedule configured for the information store, every 15 minutes. You can change this from the displayed property sheet.
The Exchange Forms Designer(EFD) is an optional component of the Microsoft Exchange client. You use EFD to create and manage custom electronic forms. Its purpose is to improve workgroup productivity by automating the distribution of repetitive information and paper forms. When used in conjunction with public folders, electronic forms are an easily implemented method of supporting shared applications such as Help Desk, Discussion Groups, and Employee documentation.
EFD is a self-contained application based on Microsoft Visual Basic 4.0. It uses an interface similar to VB4.0 to support the development of custom forms but has custom object types available to add to the forms. A VB4.0 project file is created when the application is saved, which enables the forms developer to extend the capabilities of the generated code with VB4.0. This permits the developer to add functionality not normally available in EFD by incorporating ActiveX (formally .OCX) code to perform functions not supported in EFD.
Although EFD is considered a part of Exchange server, it is installed on a client workstation. The components installed on the client fall into three categories:
Form Design Tools
Folder Design Tools
Sample Applications
The Exchange CDs contain a set of sample applications that describe the use of public folders and custom applications in Exchange. These sample applications can be used as guidelines to assist in constructing applications for deployment in the organization.
Although the sample applications appear complete, they were designed for demonstration only. Using them in a production environment is not suggested.
These applications can be installed in the user agent and used as examples to construct production applications.
When the client is installed, the folder design tools are installed. The folder design tools permit a user to customize any folder he may create, either private or public.
The folder design tools are installed from a share area on the Exchange server. The installation process adds the custom edition of Visual Basic 4.0 for Exchange to the end user's desktop.
This chapter discussed the components of the Exchange Server and how they interact.
The Exchange Server has been considered among the most complex products Microsoft has developed. This chapter attempts to shed some light on this complexity by presenting an overview of each of the components that it includes.
Unlike its predecessor, MS Mail, the Exchange Server is built around both Industry standard architecture and protocols. The server takes advantage of the strengths and security of the NT Domain by providing single logon to the domain and the user mailboxes. The internal services that comprise Exchange server, such as the Private and Public Information Store and the Directory Service were also discussed.
Connectors, which provide gateway support as well as routing in the Exchange Server were also reviewed.
The Exchange Server provides a lucrative development environment with its built-in forms capability.
The information provided in this chapter can be used to provide the basis for a detailed understanding of the Exchange Server and the capabilities it offers.