Copyright
©1996, Que Corporation. All rights reserved. No part of this book
may be used or reproduced in any form or by any means, or stored in a database
or retrieval system without prior written permission of the publisher except
in the case of brief quotations embodied in critical articles and reviews.
Making copies of any part of this book for any purpose other than your
own personal use is a violation of United States copyright laws. For information,
address Que Corporation, 201 West 103rd Street, Indianapolis,
IN 46290 or at support@mcp .com.
Exchange server is comprised of four fundamental system services that run under Windows NT server. Together, these services handle all basic client/server interaction, user lookups, message transmission, and storage of information in public and private folders. With these four core components an Exchange server can function as a stand-alone unit. All other components are optional and are designed specifically to facilitate information transfer to other Exchange servers and other external information systems.
In this chapter you learn about the following:
Exchange's Four Central Components
This chapter is designed to provide an overview of the Exchange server's four central components and describe how they communicate with each other and with other optional components. The following are the integrated server components (see fig. 3.1):
Fig. 3.1
The integrated Exchange Server performs all the functions needed in the Exchange environment.
See Chapter 12, "Directory and System Attendant Configuration," for more detailed instructions on System Attendant implementation.
This service performs general maintenance tasks. It functions much like the central nervous system for an Exchange server. Its operation is required in order for Microsoft Exchange processes to run. The System Attendant tasks are as follows:
The principal reason for communication between the System Attendant and other Exchange components involves logging messaging activity. Message logs are kept for all messages arriving and departing from the Exchange server. The following are the components that make up the communication between Exchange services:
| Agent | Function |
| Message Transfer Agent | The Message Transfer Agent notifies the System Attendant that it received or sent a message for delivery to other systems or sites. |
| Information Store | The Information Store communicates its messaging activity for logging by the System Attendant. This includes notice that it has received or sent a message for local delivery; i.e., on the same server. |
See Chapter 13, "Message Transfer Configuration," for an in-depth discussion of MTA topics and issues.
The Message Transfer Agent (MTA) comprises the foundation of Exchange server's communication infrastructure. The MTA handles message transport to other servers, other sites, or foreign systems. In addition to being the transport vehicle for messaging information, it also maps addresses, routes them, and performs message format conversion to other systems standards.
Being the principal message transport mechanism, the MTA communicates with all other Exchange components, as shown in the following minitable:
| Component | Communication |
| Directory | The MTA uses the directory to look up a user address. The directory instructs the MTA to submit mail from other sites' directories (to perform directory synchronization). |
| System attendant | The MTA tells the SA to log each instance of a message transfer. |
| Administrator Program | From the Administrator Program, the MTA receives requests to manipulate messages in the queue. |
| Information Store | The information store submits messages for delivery to other systems and is notified to receive new mail by the MTA. |
| Microsoft Mail connector | The MTA is notified of new mail to handle. |
Chapter 14, "Information Store Configuration," provides a complete description of all facets of configuring the IS.
The Information Store (IS) is the end of the line for all messaging data transmitted successfully to an Exchange server. This includes both private messages sent to individual users and public information folders intended for viewing by many users. The IS maintains data in two distinct databases--the Private Information Store and Public Information Store.
In addition to message storage, the IS handles local delivery of messages (when both sender and recipient are on the same server), replicates public folders, and enforces storage limits. The following is a list of the princiapl functions of the MTA. The MTAs communicate with the following Exchange components.
| Component | Communication | |
| Message Transfer Agent | The IS contacts the MTA to accept new incoming mail, to deliver new outgoing mail, and to resolve addresses intended for gateways. | |
| Exchange Clients | To the client the IS announces the arrival of new mail. Also the IS accepts mew mail submitted for delivery from the client. | |
| Directory | The IS uses the directory to look up addresses, get user mailbox information, and create directory entries for public folders. | |
| System Attendant | When the IS either receives or sends a message, it notifies the System Attendant so that a log entry is generated. | |
| Administrator Program | The Administrator Program sends instruction to the IS to show statistics about connected users and other storage usage information; e.g., folder sizes. The Administrator Program connects to the IS to view information, logons, and resources. | |
| Gateways | IS communication to gateways involves the retrieval and delivery of messages to outside systems. | |
Chapter 11, "Directory Management Configuration," covers the issues dealing with the directory in detail.
The directory service keeps all the information about users and resources in an organization. This includes a structured view of all server names, mailboxes, and distribution lists in a site. Also, the directory keeps configuration information that other Exchange server components use when mapping addresses and routing messages.
In order to maintain consistency of addressing information across several Microsoft Exchange servers, directory data is automatically replicated among all servers in a site. This replication is carried out through the MTA and administered by the directory service. The directory service also manages directory replication between sites on a scheduled basis (see Chapter 6, "Planning connections to Microsoft Mail systems," on directory synchronization/replication).
The directory classifies organization information (servers, mailboxes, etc.) as objects. Being objects, through the administrator program one can specify their characteristics, as well as determining who can use or change them (see Chapter 20, "Configuring X.400 Connections," on Exchange component administration). The following is a list of components of the Directory service and how they commnicate with these Exchange services.
| Component | Communication | |
| Other Directories | Directories communicate with other directories within the same site to replicate directory information. | |
| Message Transfer Agent | The directory notifies the MTA in order to send mail to and receive mail from other directories (during directory replication). The MTA looks up addresses and configuration information from the Directory. | |
| Administrator Program | The administrator program commands the directory to display and modify the address book, list of recipients, user properties, and directory objects (servers, monitors, connectors, etc.). Also, the administrator program can create objects in the directory. | |
| Exchange Clients | Client programs call upon the directory to find a specific user's address and to display the address book, resolve an e-mail name to a full alias, and modify distribution list memberships. | |
| Information Store | The IS uses the directory to look up address and configuration information, get information about mailboxes, and create directory entries for public folders. | |
| System Attendant | The SA uses the directory to look up address and configuration information, build routing tables, generate e-mail addresses for new recipients, and verify consistency of directory information. | |
| Directory synchronization component | The directory synchronization component generates requests to create, modify, and delete custom recipients. Also, it asks to look up recipients and configuration information. | |
| Microsoft Mail connector | The MS-mail connector looks up addresses from Microsoft Mail for PC networks and configuration information in the directory. | |
| Gateways | A gateway uses the directory to replicate directory information and to look up address and configuration information. | |
The Administrator Program is the primary tool for administering Exchange. Though it is not an integrated server component, it does comprise an essential part of the Microsoft Exchange architecture. Further chapters will describe the multitude of functions provided by the administrator program, but this will present you with the basic description of its communication with a few integrated server components. The following is a list of programs controlled by the Exchange Administration program with their associated functions.
| Program | Function |
| Directory | Through the administrator program one can display the address book, the main viewer, lists of recipients, properties of a user, and directory objects. Also, the administrator program allows you to create objects in the directory. |
| Message Transfer Agent | The administrator program allows you to manipulate messages in the queue. |
| Information Store | The administrator program allows you to delete mailboxes and show statistics about information storage usage such as number of users logged on. It also provides information on the private and public information stores (connections, logos, resources) and determines schedules for public folder replication. |
Integrating Connectors in the Exchange Server
One of the big improvements Microsoft has made with Exchange is the integration of connectors into the server. This feature eliminates the need for external boxes to establish connections to other mail systems.
Connectors allow Microsoft Exchange to exchange information with various messaging systems. They provide tight integration with all the tools and utilities Exchange administrators will be using in the running of the server, such as the Performance Monitor, Link Monitor, and the Administrator Program.
This section will cover the following:
Using Exchange connectors will be an easy transition for anyone who has configured mail gateways for other mail systems. For example, the Simple Mail Transfer Protocol (SMTP) gateway for cc:Mail has many of the same configuration parameters as the Internet Connector. These include whether to act as inbound and outbound gateway, who acts as the administrator, where bounced messages are delivered, and whether attachments are handled via Multimedia Internet Mail Extensions (MIME) compliance or UUENCODE. Being familiar with these terms as well as with Windows NT and 95 properties boxes facilitates configuration. By filling out properties sheets in the Administrator Program, as shown in Figure 3.2, you can be up and running without a lot of hassle.
The properties sheet for the Internet Connector gives the administrator many configuration options.
In addition, connectors can be used to link multiple Exchange sites. For example, the Internet Connector can be used effectively in organizations where some departments choose to use Exchange, while others choose other platforms. Many of these organizations standardize on SMTP to transfer messages between departments because most LAN-based e-mail packages have some form of SMTP gateway since SMTP is a non-proprietary Internet standard. These kinds of uses will be explained in a little more detail later in this chapter.
The following connectors will be explained in this chapter:
The Microsoft Mail Connector
Connecting to existing Microsoft Mail systems will be a very common use of Exchange in a large enterprise. With an installed user base of at least four million users, it makes sense that Exchange server would strongly support compatibility with MS-Mail.
See Chapters 18-19 for more information on configuring the MS-Mail Connector.
Primarily this compatibility comes in the form of the Microsoft Mail connector. This component bridges the gap between standard MS-Mail post offices and Exchange server. Essentially, Exchange emulates the functionality of an MS-Mail post office so other MS-Mail computers see it as just another member of the chain.
MS-Mail is a shared-file, LAN-based messaging system. Messages are sent to servers called post offices to which a user connects to retrieve messages. In order to integrate with this system, Exchange's MS-Mail connector becomes a post office of its own to which any other post office can connect. This allows other Microsoft Mail post offices to continue normal operation (That is, of course, until they are migrated to Exchange as well).
The MS-Mail connector (PC) consists of the following components:
Fig. 3.3
The MS-Mail Connector architecture.
Fig. 3.4
The MS-Mail connector (Appletalk) architecture.
In this scenario a Microsoft Exchange server with the Microsoft Mail connector installed is hooked to a LAN running several MS-Mail 3.x post offices (see fig. 3.5).
MS-Mail LAN connection
The following is a typical example of message transfer between both systems:
1. Messages intended for MS-Mail recipients are picked up by the Microsoft Mail connector interchange.
2. There they are translated into MS-Mail format; any OLE or other attachments are converted as required and the message is placed into the connector post office.
3. The MS-Mail connector (PC) MTA pulls the message from the connector post office and delivers it to the appropriate MS-Mail post office.
In the opposite situation, when a message originates from an MS-Mail user, the previous sequence is exactly reversed.
Microsoft Mail networks not on the same logical LAN can also be bridged with the Microsoft Mail connector. Such connections are commonly established by modem or wide area X.25 links. Exchange's Microsoft Mail connector (PC) MTA can be configured to support asynchronous or X.25 connections (see fig. 3.6). However, a normal Microsoft Mail post office cannot alone handle this connection. There must be an MS-Mail External or Multitasking MTA program set up to provide the modem management and message transfer functions over a remote link.
Asynchronous connection to post offices
A single Exchange server can run multiple instances of the MS-Mail connector MTAs (see fig. 3.7). Each MTA runs as a Windows NT system service that can be stopped and started independently of any other service. The best way to architect such connections is to create one instance of the MTA for each type of network connection. Therefore, one MTA is dedicated to an X.25 link, while another can service a modem link, and still another can connect to a local LAN.
Fig. 3.7
Exchange sever with multiple MS-Mail connectors
If your organization uses a large number of Microsoft Mail 3.x post offices or they are spread over a wide area, then you would want to set up multiple MS-Mail connectors within your organization.
It is important to realize that all MS-Mail connectors in a site will use the same e-mail address. From the MS-Mail perspective, each site will be seen as one large post office.
Understanding the X.400 Standard
Microsoft Exchange's use of the X.400 standard allows a broad interoperability with a wide range of messaging systems. X.400 is a standard set by the International Telegraph and Telephone Consultative Committee (CCITT). To date there have been three iterations of the X.400 standard (1984, 1988, 1992). The initial release version of Microsoft Exchange supports the 1984 and 1988 standards, with the 1992 version to be supported in later versions.
See Chapter 20, "Configuring X.400 Connections," for more information.
The X.400 standard defines the basic framework of a message handling system, the structure of the message and its components, and how messages are transferred. It is widely supported and used by most public e-mail carriers and telecommunication providers. Because of its widespread acceptance, many companies have already developed gateways to bridge their messaging systems with X.400. In real-world situations, where network, hardware, and communication standards are not strictly enforced, X.400 provides a common ground for interoperability between messaging systems. Microsoft has assured Exchange's strict conformance to government X.400 standards, which means that Exchange will be a reliable solution for the widest possible number of X.400 connections.
The Microsoft Exchange X.400 connector provides all essential connectivity with this standard. In this section, you will see the following:
The X.400 standard makes provisions for specific components of a Message Handling System (MHS), including a structure for message content and addressing. These components are as follows:
Microsoft fulfills each element specified by the X.400 standard. In fact, the whole Message Transfer System design is the basis for Exchange's Server site and organization structure.
When referring to a Microsoft Exchange X.400 connector, one is really describing the use of a Microsoft Exchange MTA configured to connect to an X.400 based system. MS Exchange MTAs are compliant with other MTAs (in another Exchange server or an external system) that comply with the 1984 or 1988 X.400 standards. The Exchange MTA can be extensively configured to negotiate such connection over a wide variety of network transports.
See Chapter 13, "Message Transfer Configuration," for more information on MTA configuration.
The Message Store requirement is met by Exchange's public and private information stores.
See Chapter 14, "Information Store Configuration," for more details.
The User Agents are realized as Microsoft Exchange Client programs currently available on several common platforms.
The Access Units are the many gateways currently available for use with Exchange (PROFS, SNADS, Fax, pager, etc.). Each provides a route into their particular system.
Much like an Exchange address is identified by the user at site structure, X.400 addresses are distinguished by unique personal information and information about the system on which they receive messages. A typical X.400 address contains the following information:
c=US; admd=MCI; prmd=Digital Genesis; o=Los Angeles; ou1=Sales; dn=Davey Kim;
Each element is described in Table 5.1.
Table 5.1 X.400 Addressing Elements
| Element | Description |
| c=US | country |
| admd=MCI | Administrative Management Domain. Usually the name of your X.400 service carrier. |
| prmd= | The name of your enterprise |
| o= | Organization. Name of the Exchange site |
| ou1= | Organizational Unit. The X.400 attribute which helps further identify the remote site. |
| dn= | Directory Name |
To appropriately route messages in a site or between sites, Microsoft Exchange uses what is called the X.400 global domain identifier (GDI) of the local site. In order for messages to be routed correctly, the GDI used for a Microsoft Exchange Server cannot be identical to the GDI of a connected foreign system. This will become an issue only when using Exchange to connect to foreign X.400 systems.
As a system administrator you can use Exchange's bulk import utility to merge a series of foreign addresses into Exchange's global address list. Additionally, the Exchange client allows individual users to enter their own X.400 addresses via an X.400 template.
X.400 addresses for recipients on an Exchange server are automatically created when a new mailbox is created.
Connecting an Exchange Server site to a foreign X.400 system will be a primary use of the X.400 connector. However, there are a number of connection possibilities afforded by the implementation of this versatile tool. Connections over X.400 can be established to share directory information, replicate public folders, transmit standard messages, or all of the above. The following figure 3.8 gives three examples of such usage.
Fig. 3.8
You can connect an Existing MS-Mail server to a foreign X.400 system (through an Exchange server).
The Microsoft Exchange X.400 connector in conjunction with the Microsoft Mail connector can allow users on MS-Mail to access X.400 systems (see fig 3.9).
Fig. 3.9
You can connect an Exchange Server site to an MS-Mail post office.
A common use of the X.400 connector in Exchange will be bridging messaging systems that are geographically disperse. In this example, a Microsoft Exchange server is set up to transfer messaging data with an MS-Mail system using an X.400 connector on one end and a currently available MS-Mail X.400 gateway on the other(See fig. 3.10).
Fig. 3.10
You can connect two Exchange Server sites.
Two Microsoft Exchange Server sites can be linked via a public (or private) X.400 mail system. All that is required is one properly configured message transfer agent at either end. The same technique is applicable over a TCP/IP network with the Internet Connector and is covered in the next section.
The Internet Connector
As its name implies, the Internet Connector provides integrated, native SMTP connectivity to the Microsoft Exchange server. In doing this, Microsoft has eliminated the need for the DOS-based SMTP gateway for Microsoft Mail that lacked robustness, had memory allocation problems, possessed little or no security, and needed external hosts to send out SMTP mail. The gateway was usually run on a 386 and had a hard time communicating with various Internet mailers.
The Internet Connector solves those problems by providing a stable, proven, and secure platform with Windows NT Server. In addition, the Internet Connector can send and receive SMTP mail without the need for external hosts, is MIME compliant, and provides robust performance.
See Chapter 21, "Setting up SMTP Connections," for more information.
The following diagram (see fig. 3.11) shows how the Internet Connector fits into the Microsoft Exchange architecture.
Fig. 3.11
Internet Connector Architecture
In addition to providing Internet mail service, the Internet Connector allows those users running TCP/IP over the backbone to connect Exchange sites to each other using the connector. As mentioned previously, decentralized organizations often give control of the mail system to the respective department. Many large universities operate this way. These organizations often choose SMTP as the way for disparate mail systems to communicate because it is an Internet standard. Microsoft has recognized that many companies route only TCP/IP over their WANs to maximize router throughput. More information on planning and designing Exchange networks can be found in Chapters 12-16. A diagram showing how to link disparate Exchange sites by using the Internet Connector is shown in figure 3.12.
Fig. 3.12
Connecting Multiple Exchange Sites Over TCP/IP
The Internet Connector provides for full integration into environments where security is a big concern. Many companies configure firewalls to protect internal data from hackers on the Internet. In addition to all the security components inherent to Exchange and Windows NT Server, the Internet Connector provides the ability to refuse messages from any specified hosts. This provides protection from many forms of hacking because many hackers use the e-mail system to carry out their work. For example, you might configure the connector to refuse mail from all hosts other than a certain mail relay. That means that a hacker could not send a message directly to your Exchange server and send commands directly to it. By refusing mail from certain hosts, Exchange is flexible enough to fit into existing company security policies. Any hacker would have to compromise the firewall in order to send a message directly to the Internet Connector.
Exchange can also be configured to allow only incoming or outgoing traffic through the connector. This is an important feature because one Windows NT server can only do so many things and complete so many tasks without taking a performance hit. Configuring the connector to only send out mail might be a good idea for a machine that is already overloaded. However, this is not a cause for concern. As long as there is incoming Internet mail added to the Information Store, all Exchange users, including users at other Exchange sites, will receive Internet mail. For example, if you have the Internet connector configured on two servers and configure one to receive only and the other to send only, the Exchange users' e-mail addresses will still be the same. Users will not know where the mail came in and don't really care. The connections are completely transparent. Figure 3.13 shows the properties screen where the administrator can configure security and transfer options.
Figure 3.13
Internet Connector Connections Properties
In addition to fitting into the overall Microsoft Exchange picture, the Internet Connector has an architecture of its own that needs to be explained. When installed and configured properly, the Internet Connector functions as two NT services. One is the "Connector Service" and the other is the "SMTP Service." These two services combine to perform all the tasks of obtaining, transporting, and receiving SMTP messages and all their MIME attachments. The following describes these two services and their functions:
Connecting to Lotus cc:Mail
The cc:Mail Connector provides seamless communication between Microsoft Exchange Server and Lotus' cc:Mail product. In recent months, Lotus has embraced the MAPI standard for messaging-enabled applications, switching from their previous Vendor Independent Messaging (VIM) standard. Despite this change in Lotus' strategy, their Post Office Version 8, which supports MAPI, has yet to ship, leaving existing users with VIM-based post offices. The cc:Mail Connector enables connectivity between these post offices and Exchange.
The cc:Mail Connector has many configuration variables enabling the use of the existing cc:Mail tools such as Import, Export, and ADE to enable robust, hassle-free connections to cc:Mail VIM post offices.
cc:Mail users are to be directly imported into the Microsoft Exchange Global Address Book and will appear just like any other Exchange user.
Just as with the Microsoft Mail Connector, a cc:Mail post office is created on the Exchange server, resulting in Exchange server users appearing in the cc:Mail directory like all other cc:Mail users. This gives transparency to the cc:Mail user. As far as he or she is concerned, all users in the Global Address Book are local.
Exchange allows the administrator to set the paths to the standard Import and Export utilities that come with cc:Mail. These utilities are used to import and export directory and message data from the Exchange server to all other cc:Mail post offices in the cc:Mail network. Examples of the uses of this connector are shown in figure 3.14.
Architecture of the cc:Mail Connector
On the cc:Mail side, Exchange looks just like any other post office; and by using Automatic Directory Exchange (ADE), all cc:Mail post offices, including the Exchange cc:Mail post office, can be kept up to date as users are added on both sides. For example, if a user is added to the Exchange Global Address book, an ADE message is generated and sent to the master cc:Mail post office. From there, the master cc:Mail post office generates ADE updates through the cc:Mail router to the rest of the cc:Mail post offices. All the cc:Mail administrator needs to do is follow the same directory synchronization procedures used when a new cc:Mail post office is created. The following Figure 3.15 explains this concept.
Fig. 3.15
ADE Synchronization between the cc:Mail and Exchange
Microsoft realized that the cc:Mail is a large player in the LAN-based messaging market. By making the cc:Mail Connector available, they have leveraged this popularity. In some organizations, many dollars have been spent on training personnel to install and maintain cc:Mail, as well as hardware resources. Using Exchange means that your organization will not have to throw away existing mail systems to roll out a new one.
The CCMail Connector will not be available in the inital release of the Microsoft Exchange server. Microsoft will make this component available after the product has been released.
Understanding Gateways
Gateways provide a way for Exchange to integrate disparate information services into Microsoft's Universal Inbox, using the single Microsoft Exchange Viewer to organize all types of information. These include things such as voicemail, fax, paging, as well as e-mail from other vendors' systems.
Despite the variety of information services that snap into Exchange, the end user sees no difference. To him or her, the addressee is the addressee. A user can address a message and send it, and the addressee might get a page, fax, voicemail, or Internet message. The addressee may be using cc:Mail, PROFS, SNADS, or Microsoft Mail, and the user sending the message would never know because all he or she needs to know is the addressee's name in the Global Address Book.
In addition to native Exchange gateways, Exchange can use standard Microsoft Mail gateways by using the Microsoft Mail Connector described earlier in this chapter. Each gateway uses the Microsoft Mail Connector to exchange data with foreign mail systems. This may be useful for sites with large Microsoft Mail installations that are migrating to Exchange slowly, but want to provide the core messaging functions first and add connectors and gateways later. In addition, some organizations are hesitant to sway from things that work. For example, if the Microsoft Mail gateway to PROFS has been working fine, some may be hesitant to roll out the Exchange PROFS gateway because they haven't had the opportunity to test it and get their staff familiar with it. Figure 3.16 shows how Microsoft Mail gateways fit into the Exchange topology.
Fig. 3.16
Message flow of Exchange to PROFS using PROFS Gateway for MS-Mail
In the preceding case, the PROFS gateway for MS-Mail simply talks to the MS-Mail Connector post office. When configuring the PROFS gateway for MS-Mail, you simply point it at the MS-Mail Connector post office and the exchange of information becomes transparent.
With Exchange, Microsoft took those concerns into consideration and provided the flexibility to use legacy systems in the migration to a robust Exchange environment. For the purposes of this book, only the native Exchange gateways will be discussed in detail.
Exploring Native Exchange Gateways
The following Exchange gateways will be discussed in the following sections: Voicemail, Fax, Pager, PROFS, and SNADS.
Microsoft's Universal Inbox metaphor is being further developed by the integration of voicemail into Exchange. In some cases, voicemail is quicker and carries less overhead than e-mail. In addition, many organizations have an existing voicemail infrastructure. Many vendors are working to integrate these existing technologies into Microsoft Exchange Server, bringing the concept of the universal inbox into reality.
Octel, a leading provider of Enterprise voice and fax messaging, is bridging the gap between voice and e-mail communications through new technology developed for Microsoft Exchange. Octel Unified Messaging simplifies communications by combining voice and fax messages with e-mail into a single Exchange Server mailbox and providing access to all messages from a telephone or PC (see fig. 3.17). System managers also benefit as the Octel Unified Messaging architecture shares a common database, directory, and administration. Octel Unified Messaging operates on standard PC hardware and is fully compliant with Microsoft NT Server.
Fig. 3.17
Voicemail Integration with Exchange
The Microsoft Exchange Client provides for outbound faxes through Exchange Server or a local modem, but there are fax gateways being developed that tie into the Exchange Server Address Book. This means that users without a local modem can send and receive faxes that come into their inbox. By interfacing with the PBX at the site, transparent fax capability can be achieved.
Figure 3.18 shows the architecture of the fax gateways. The NT server housing the Exchange server has PBX interface hardware that connects several Direct Inward Dial (DID) lines to the server. The gateway software then links mailboxes with specific fax numbers using the * key on the telephone keypad. For example, if the DID line phone number was 555-3456, each user's individual fax number would take the form of 555-3456*1.
Fig. 3.18
Fax Gateway Connectivity.
Using this system, the fax gateway can route the message to the proper inbox. This paperless fax system, along with the concept of binary faxes, makes fax integration very robust. Binary faxing allows the user to receive a fully editable document. Rather than faxing a plain image, you can load Word and start editing a fax.
One of the many add-on products for Exchange is the Integra Wireless Server for Microsoft Exchange. This product allows all Exchange clients to send pages through the Exchange server by adding a custom recipient to their personal address books.
The software works by using modems in the Exchange server to dial access numbers which are set up in the "Gateway Wireless Communications Connector" properties. The gateway supports the following communications protocols:
Integra Wireless Server is fully MAPI compliant, and custom applications can be created to take advantage of paging technology. For example, you could write a program that will page you when there are more than five messages in your inbox while you're away from the office. The product fully supports 32-bit OLE automation and includes a 32-bit OCX custom control.
If you have an alphanumeric pager, the Wireless Server can also be configured to send your e-mail directly to your pager. You can also have it send your Schedule+ information to inform you of appointments while on the road.
Integra is the maker of WinBeep for Networks, and has migrated this technology to Microsoft Exchange Server (see fig. 3.19). Like all other native Exchange software, it is configured through the Exchange Administrator Program and integrates with all the standard Exchange administration tools.
Fig. 3.19
Integra Paging Gateway Connectivity
Attachmate's Zip! Gateway for Microsoft Exchange Server allows seamless integration with PROFS systems. It will allow for the transfer of e-mail, address books, and Free/Busy Schedule information. The advantage this product has over the standard MS-Mail Gateway for PROFS is that it is tightly integrated with Exchange Server's Administrator Program. You will be able to configure and monitor this gateway in the same way as all the connectors.
The Zip! Gateway also improves on the standard Microsoft Mail gateway for PROFS by adding real time calendar detail access and directory integration. All of the standard directory synchronization is taken care of by the standard Exchange directory synchronization service.
In addition, just as with the Internet Connector, the Zip! Gateway can be used to leverage PROFS host-based infrastructure. If two sites have SNA APPC connectivity between them, any Exchange messages can be sent over the PROFS backbone as shown in Figure 3.20.
Fig. 3.20
Sending Exchange Messages over a PROFS backbone
The Zip! Gateway uses standard SNA APPC, CSV, CPIC, and LUA APIs and works with the following host platforms:
Attachmate's Zip! Gateway is a marked improvement to the Microsoft Mail PROFS gateway, and Microsoft has committed to working very closely with Attachmate due to their knowledge and history of working with IBM mainframe connectivity products. Rather than reinvent the wheel, Microsoft is teaming with other companies, leveraging their distinctive competency in a given area. Microsoft's alliances with third parties is discussed in detail in Chapter 29.
Microsoft sees the PROFS gateway as being very important for organizations looking to migrate existing PROFS users to Exchange, given the recent surge of companies migrating from mainframe-based applications to client/server based systems.
Attachmate's Zip! Office Gateway to SNADS allows Microsoft Exchange users to seamlessly communicate with users on existing SNADS platforms. SNADS is the IBM mainframe connectivity protocol over serial connections, instead of using LAN conenctions.
It is tightly integrated with Exchange Administrator Program, Microsoft SNA Server, and other Microsoft Exchange gateways. Its 32-bit object architecture gives it the ability to scale in large environments as well as perform reliably and quickly.
Similar to the PROFS gateway mentioned earlier, the Zip! Gateway to SNADS allows current SNADS infrastructures to be used to send native Exchange data without the loss of data integrity.
The gateway is compatible with the following platforms:
This gateway can be used to both leverage current hardware and software investments in SNADS, or as a migration tool to Exchange depending on your organization's plans and goals.
From Here...
Exchange has a powerful back-end architecture consisting of four components: the System Attendant, the Message Transfer Agent, Information Stores both public and private, and the Directory. In addition, connectors and gateways are integrated into the server to provide seamless connections to external systems.
Both connectors and gateways serve the following needs:
The following chapters contain related information to some of the items talked about in this chapter:
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation
