Novell is now a part of Micro Focus

Integrating MHS Services with Other Novell Products

Articles and Tips: article

BRUCE GREENBLATT
Systems Architect
GroupWare Division

GERALD HERBEL
Senior Development Engineer
GroupWare Division

LARRY MORRIS
Managing Editor
Systems Research Department

GLENDON WHITELEY
Lead Engineer
GroupWare Division

01 Oct 1995


Novell's messaging solution centers on GroupWise (which offers E-mail, scheduling, and task management) and GroupWise XTD (Novell's next-generation solution). MHS Services, which is tightly integrated with NetWare, can communicate with GroupWise via the GroupWise MHS Gateway or the MHS Connectivity Server. MHS Services can also be used in a variety of other settings. This AppNote offers an overview of MHS Services and covers installation and management of MHS Services. It also discusses the relation-ships among MHS Services, NDS, GroupWise, and Global MHS.

RELATED APPNOTES Dec 94 "Managing Basic MHS" Oct 94 "Managing and Using FirstMail" Aug 94 "Installing Basic MHS and FirstMail" July 94 "Key Issues Surrounding Enterprise E-mail"

Introduction

Novell's Message Handling System (MHS) is a technology for sending, routing, and receiving electronic mail. MHS offers store-and-forward capabilities. "Store-and-forward" simply means that a message can be composed in workstation memory, stored on a hard disk, and forwarded to recipients when they read their mail. Novell offers several versions of MHS:

  • Basic MHS, which is included with NetWare 3.12 and offers message transport among users on the same file server.

  • MHS 1.5, a DOS-based product offering rudimentary MHS connectivity to environments not supporting NLMs.

  • Remote MHS, which connects MHS users not directly connected to the network.

  • Global MHS, which runs on NetWare 3.1x networks and offers full integration with NetWare.

  • MHS Services, which ships with NetWare 4.1 and is comprised of two NLMs.

NetWare MHS Services deserves special attention because it is the latest MHS product, it ships with NetWare 4.1, and it supports NetWare Directory Service (NDS).

This AppNote discusses Novell's current messaging products and then offers an overview of MHS Services and its companion product, FirstMail. Next, the AppNote covers installation, configuration, and management of MHS Services. Lastly, it discusses the relationship between MHS Services and the following Novell messaging products:

  • SMF

  • MHS MailSlots

  • GroupWise

  • Global MHS and MHS 1.5

Novell's Messaging Products

Novell's messaging solution centers on two key products: GroupWise and GroupWise XTD. These products are described in the following sections.

GroupWise

GroupWise provides E-mail, scheduling, calendaring, and task management for the workgroup or the enterprise from a single application. GroupWise allows users to:

  • Communicate via E-mail messages and attachments

  • Track personal and group tasks and appointments

  • Route documents to a distribution list for review and approval

  • Automatically process messages by using rules

  • Connect to PROFS, cc:Mail, SMTP, and X.400-based systems

  • Communicate with other E-mail users via fax or wireless devices

The next version of MHS Services, 1.1, will be released within the next few months. This upgrade will offer closer interoperability with GroupWise, since it includes GroupWise addresses from NDS in the MHS Extract File. MHS Services 1.1 and MCS constitute Phase III of MHS/GroupWise convergence.

GroupWise XTD

Novell presently offers a family of collaborative computing products, including MHS, GroupWise, InForms, SoftSolutions, and Collabra Share. Building on this foundation, Novell is now developing its next-generation solution, called GroupWise XTD.

GroupWise XTD will consist of an integrated line of groupware products that enable:

  • Users to accelerate their decision making processes

  • Workgroups to handle tasks more efficiently

  • System administrators to manage applications and networks from a common point of administration

  • Developers to build ad hoc and production applications

The first components of GroupWise XTD are expected to be available early in 1996.

At the heart of GroupWise XTD is the Universal In Box, which will combine many in-boxes (such as voice mailbox, E-mail in-box, fax machine, and pager) into a single point of entry for all types of information, regardless of data type. GroupWise XTD communication services will optimize the movement of information by giving users the option of downloading files or simply moving references or pointers around the network.

The central component of these communication services will be the GroupWise XTD message transfer agent (MTA). This MTA will support the following:

  • GroupWise 4.1 clients

  • MAPI 1.0 clients

  • CMC 2.0 clients

Current communications tools that link GroupWise and MHS will also be supported under GroupWise XTD.

Current MHS and GroupWise users will be able to migrate to GroupWise XTD by replacing their MTA with the GroupWise MTA, moving individual mailboxes to GroupWise XTD one mailbox at a time or upgrading entire post offices.

GroupWise XTD will support such standards as X.400 and SMTP/MIME, and a large variety of messaging gateways will be available.

NDS will play a critical role in the GroupWise XTD infrastructure. All GroupWise XTD objects will be published and accessible through NDS. In fact, all additions, deletions, and modifications made to NDS will automatically be reflected in GroupWise XTD.

GroupWise XTD will also integrate Novell's ManageWise, a management tool that can enable event notification, set up performance benchmarks, and collect and analyze information.

The Role of MHS Services

Although Novell's messaging solution centers on GroupWise, the use of MHS Services is appropriate in situations such as the following:

  • For small, self-contained NetWare 4.1 networks

  • For messaging systems already using MHS

  • For networks using a front end other than GroupWise

  • For systems requiring a file-based API for in-house ad hoc use

Overview of MHS Services

MHS Services provides message delivery to users on a 4.1 network. Users can create messages with applications compatible with Novell's Standard Message Format (SMF) interface (described below). The application submits its message to MHS Services, which delivers it to the recipient's mailbox.

MHS Services requires less than 400 KB of RAM and is fully integrated with other NetWare 4 components. (such as the NetWare Administrator, NETADMIN, and UIMPORT utilities.)

Like other products in the MHS family, MHS Services supports a simple file-based interface that can be used to write messaging-enabled applications. These applications can use MHS Services to send messages to users or to other applications. For example, a messaging-enabled database program can generate a report and use MHS Services to distribute it to a group of MHS users.

FirstMail

FirstMail is an E-mail application available in both DOS and Windows. When you install MHS Services, both versions of FirstMail are automatically installed in the server SYS:\PUBLIC directory. FirstMail gets user information directly from NDS.

The main menu for FirstMail includes such options as sending a message, browsing mail, changing file servers, and editing a file.

FirstMail users can do the following:

  • Create and send messages and attached files

  • Read, print, delete, reply to, and forward messages

  • Create and maintain a private address book

  • Organize messages in folders

MHS Services Utilities and Programs

The following table describes utilities and programs used by MHS Services.


Utility/Program
Tasks

NWADMIN (MSWindows-basedgraphical utility)

Managing mailboxes,configuring gateways

NETADMIN(Text utility)

Managing mailboxes,configuring gateways

UIMPORT (Batch utility)

Assigning mailboxes

MHSCON (NLM)

Monitoring messaging server statistics and events, managingmessage flow, and customizing configuration

MHS (NLM)

Picking upand routing messages

MAIL (DOS-basedFirstMail application)

Creating and sending messages and reading, printing, and filing incoming messages; automatically installedduring MHS Services installation.

WMAIL (MS Windows-basedFirst Mailapplication)

Automatically installed during MHS Services installation. To use this application, users must createa program item in Windows.

Note: NWADMIN, NETADMIN, and UIMPORT are installed as part of the NetWare4.1 installation.

Using MHS Services

This section briefly describes installing, loading, managing, and configuring MHS Services. (See the Novell MHS Services for NetWare 4 manual for more detailed information.)

Installing MHS Services

You can install MHS Services when you install NetWare 4.1 or you can install it later.

If you install MHS Services with NetWare 4.1, use the Customized installation of NetWare 4.1 option. First complete the operating system installation. Then the Other Installation Actions menu appears; select the Choose an item or product listed above option. Next, select Install NetWare MHS and follow the prompts.

If you install MHS Services separately, enter the following command at the file server console:

LOAD INSTALL

The Installation Options menu appears. Select Product options. The Other Installation Actions menu appears; select the Choose an item or product listed above option. Next, select Install NetWare MHS and follow the prompts.

Loading MHS Services

To activate an MHS messaging server, you must load the MHS Services NLMs - MHS. NLM and MHSLIB.NLM - on a NetWare server. When activated, MHS Services provides message-delivery services to all users with mailboxes on the NetWare server.

To load MHS Services manually, enter the following command at the NetWare server console:

LOAD MHS

If you add this command to the AUTOEXEC.NCF file, MHS Services will automatically load whenever you bring up the NetWare server.

Unloading MHS Services

You must unload and reload MHS Services after you change the configuration parameters. New parameters will not take effect until MHS Services is reloaded. Novell also recommends that you unload MHS Services before bringing down the NetWare server for maintenance.

To unload MHS Services, enter the following commands at the NetWare file server console:

UNLOAD MHS

Before unloading, MHS.NLM completes the processing of any messages in progress. This can take several minutes, during which the NetWare server console is unavailable.

You can also unload MHS Services from the MHSCON utility. If you do so, you can use the console for other tasks while MHS Services is unloading. To unload MHS Services from the MHSCON utility, follow these steps:

  1. Select Shut down MHS from the MHSCON Available Options menu. MHSCON prompts for confirmation

  2. Select Yes. MHSCON terminates and MHS Services is unloaded.

Managing MHS Mailboxes

When you assign an MHS mailbox to a user, you must define the following properties:

  • Mailbox location, which identifies the messaging server on which the user's MHS mailbox is located.

  • Mailbox ID, which is the name of the subdirectory in which the user's incoming messages are stored.

You can use NWADMIN to assign, move, or delete MHS mailboxes. Two dialog boxes are available for managing MHS mailboxes: the object dialog box and the messaging server dialog box.

Use the object dialog box if you are assigning, moving, or deleting the mailbox of an individual object or multiple objects with mailboxes on different MHS messaging servers. Use the messaging server dialog box if you are assigning mailboxes to, or deleting mailboxes from, multiple objects on the same server.

When you use UIMPORT to import users from an existing database into an NDS database, you can also import user mailbox information via UIMPORT Mailbox Location and Mailbox ID.

Using the MHSCON Utility

The MHSCON utility offers options for administering the messaging server. To load the utility, enter the following command at the NetWare file server console:

LOAD MHSCON

The Available Options menu appears, listing the following options:

  • Messages

  • Event Logs

  • Statistics

  • Configuration

  • Applications

  • Update Extract File

  • Flow Control

  • Shut Down MHS

  • Exit MHSCON

The Statistics option, for example, allows you to display statistics for a specific server, write the summary stats to a disk file, or reset the summary statistics.

Configuring MHS

The default configuration options will be adequate for most installations. Customizing the configuration is an option under the following circumstances:

  • You want users notified when messages are delivered to their mailboxes.

  • Messages are not being delivered.

  • Messages are not being delivered quickly enough.

  • You frequently add, delete, or change messaging users in the NetWare Directory database.

  • You need the MHSCON messaging server status and statistics screens to be current.

  • Your NetWare server is short on disk space.

  • The performance of other services on the NetWare4 server is suboptimal.

Configuration information is stored in an ASCII text file called MHS.CFG, located in the SYS:\SYSTEM directory. You can view or edit this file with a text editor or with MHSCON.

Understanding SMF

SMF is closely related to MHS Services because applications must follow SMF guidelines to support MHS Services. This section introduces SMF. (For more information, see the NetWare SMF-71 Programmer's Reference manual.)

SMF is a set of rules governing how applications and gateways must construct messages to ensure reliable delivery by the messaging system. (Messages are defined as units of information containing addresses, text, and attached files.) The current version of SMF is SMF-71, which is compatible with NetWare Directory Services. The previous version, SMF-70, was a simpler implementation limited by its 8-character addressing scheme (which is not compatible with NDS).

Observing SMF rules allows developers to ensure the reliability and interoperability of applications and gateways. SMF rules fall into three basic categories:

  • Message generation and management

  • Interaction between applications or gateways and MTAs

  • Interaction between one application or gateway and another application or gateway

Messages are transferred by message transfer agents (MTAs). (MTAs, UAs [users agents], and other components of an E-mail system are defined in X.400, the ITU standard for E-mail and messaging.) An SMF-compatible MTA is a program that transfers messages from an SMF-compatible application or gateway to applications or gateways that are compatible with NetWare MHS and NetWare Global MHS.

The SMF-compatible MTAs transfer messages between SMF and other messaging environments, including those that use non-SMF message and address formats. MTAs can transfer messages across a broad range of data communications media, such as telephone lines, Ethernet, and wide area networks.

Novell provides the following SMF-compatible MTAs:

  • NetWare MHS 1.5, a DOS-based MTA.

  • NetWare Global MHS, an MTA that runs as a set of NLMs on a NetWare server.

  • NetWare Basic MHS, an entry level MTA that is supplied with NetWare 3.12.

  • Messaging Services for NetWare 4.1, a full featured MTA that uses NDS as its messaging directory, and is supplied with NetWare 4.1.

Public hubs can also provide SMF-compatible MTAs on other platforms.

SMF and NDS

Novell has added support for messaging applications to NetWare Directory Services (NDS). In NetWare 4.1, objects have been added to the NDS schema that have been designed specifically for messaging. Some of the things SMF applications can do with NDS are:

  • Develop tightly integrated messaging applications and gateways

  • Get MHS Mailbox address from NDS

  • Get distribution list members from NDS

  • Get local users of an MHS MTA from NDS

  • Configure distribution lists and their members

NDS objects are identified by their distinguished names. MHS Services makes use of an NDS object's distinguished name in order to derive the object's E-mail address. As an example of how this works, assume that some hypothetical user's distinguished name is:

CN=Bob.OU=Marketing.O=Novell

To generate the SMF-71 address from the NDS object name, MHS Services converts the period between the CN and the other distinguished name components to the '@' character. Thus, Bob's E-mail address would be:

bob@marketing.novell

In MHS Services, mail can be addressed to any of the following types of NDS objects:

  • User objects

  • Distribution List objects

  • Group objects

  • Organizational Role objects

  • External Entity objects

For more information about these object types, refer to the schema definition for the NetWare 4.1 version of NDS.

Key Elements of MHS Services

Key concepts associated with MHS Services include the following:

  • Messaging server

  • Message routing group

  • Postmaster General

  • Postmaster

  • Gateway

  • Mailbox

  • Extract file

  • External entity

  • External name

  • Foreign E-mail address

  • Foreign E-mail Alias

  • Distribution list

MHS Messaging Server

A Messaging Server picks up messages which are either submitted by messaging applications (for example, E-mail) or transferred from another Messaging Server, and delivers them to the recipients. For recipients whose mailboxes are local on the Messaging Server, the message is delivered to their mailboxes. Otherwise the messaging server transfers the message to another messaging server for eventual delivery to the recipient's mailbox. In other words, the Messaging Server provides store-and-forward message transfer service for messaging applications such as E-mail.

The MHS Messaging Server runs as MHS.NLM on a NetWare 4 file server. It provides store-and-forward message transfer service in NetWare 4 networks. There is no limit on the number of mailboxes it can service, as long as sufficient disk space is available. MHS.NLM (and its related NLMs) is included as an integral part of the NetWare 4 release. In the NDS schema, MHS Messaging Server is represented by an NDS leaf object called Messaging Server.

MHS Message Routing Group

An MHS Message Routing Group is a group of messaging servers that communicate with each other directly to transfer messages. The MHS Message Routing Group is represented by an NDS leaf object called Message Routing Group. The Member property lists the Messaging Server(s) which exchange messages directly with each other.

Postmaster General

Each message routing group has one or more Postmaster Generals. The Postmaster General (typically the Admin user) is automatically granted the privileges necessary to perform the following tasks:

  • Modify the message routing group object

  • Modify the messaging servers that belong to that message routing group

When you install MHS Services, the installation program prompts you to log in as the user who will be the Postmaster General.

Postmaster

Each messaging server has one or more Postmasters, users who are automatically granted privileges to perform the following tasks:

  • Modify the messaging server object

  • Assign a mailbox on the messaging server to an object

  • Modify or delete mailboxes on the messaging server

Gateway

A gateway is a software program that does either of the following:

  • Supplies additional messaging features, suchas access to a gateway service (for example, a fax service or an electronic bulletin board).

  • Provides access to another protocol or messaging system.

MHS Mailbox

The messaging server delivers messages to a user's mailbox. A user's mailbox in MHS is specified by two properties of the NDS User object: Mailbox Location and Mailbox ID. Mailbox Location identifies the messaging server in which the mailbox resides. Mailbox ID uniquely identifies the mailbox within that messaging server. For MHS Services 1.0 in NetWare 4.1, the Mailbox ID specifies a file subdirectory (under the Message Database Location) in which all of the user's inbound mail will be placed.

MHS Extract File

The MHS Extract File provides applications with a read-only, flat view of the NDS objects that have a mailbox (native MHS or foreign) to receive messages. By using the MHS Extract File, applications can provide a sorted list of Users, Distribution List, and so on, from which users can select recipients. The MHS Extract File contains a list of fixed-length records. These records are sorted by "Surname, Given-Name Middle-Initial, Generation-Qualifier," an order that somewhat resembles that used in telephone book white pages. ( Refer to the SMF-71 Programmer's Reference for more information.)

External Entity

An External Entity is a non-native NDS object which is imported into NDS or manually registered in NDS. External Entities are normally imported into NDS by NDS External Synchronization software. MHS Services uses External Entity to include users (and distribution lists) from non-NDS directories in order to provide an integrated directory (that is, an address book) for sending mail. In other words, when addressing messages, MHS users can choose non-native NDS users from the MHS address book (MHS Extract File). External Entity is represented by an NDS leaf object called External Entity.

External Name

External Name specifies the type of the entity's native Directory Service (or Name Service) and its name in that Directory. For example, an user imported from an X.500 directory system would have X500:X500-DN as his/her External Name.

Foreign E-mail Address

Foreign E-mail Address specifies a user's mailbox that resides in a Foreign E-mail system. For example, an NDS user can choose to have his or her E-mail delivered to a UNIX machine that supports SMTP messaging protocol. And this user's SMTP address in the UNIX machine is his or her Foreign E-mail Address. A user can have at most one Foreign E-mail Address. Foreign E-mail Address is represented by the E-mail Address property in NDS.

Foreign E-mail Alias

Foreign E-mail Alias specifies a user's E-mail alias as known in a foreign messaging system. It is used by users of a foreign messaging system to send mail to an MHS user. For example, an MHS user (whose mailbox is in a MHS messaging server) can have an X.400 alias so that X.400 users can use this alias when sending mail to the MHS user. A user can have more than one Foreign E-mail Alias - one for each different foreign E-mail system.

Foreign E-mail Alias is represented by the E-mail Address property in NDS.

Distribution List

A Distribution List is a list of mail recipients. A Distribution List is used to facilitate sending messages to multiple recipients. For example, you can create a Distribution List of users called "Recreation Committee". When anyone wants to send a message to each of the members in the Recreation Committee, he or she can simply address the mail to Recreation Committee. A member of a Distribution List can be a user, another Distribution List, Group, or Organizational Role.

Although you can also send mail to all the members in a Group by addressing the mail to the Group, there are some differences between Distribution List and Group, as follows:

  • Members of Group automatically get the privileges assigned to the Group, but the members of Distribution List do not.

  • Group is to be used mainly for simplifying trustee assignment and login scripts, whereas Distribution List is to be used for simplifying sending mail to a list of recipients.

  • A Distribution List can have another Distribution List as a member, whereas a Group can not have Group as a member.

  • Members of a Group have a property called "Group Membership" that points back to the groups to which they belong. Members of a Distribution List do not.

Distribution List is represented as an NDS leaf object called List. It has the following properties, which are significant for messaging operation.

Mailbox Location. Mailbox Location specifies a Messaging Server where the Distribution List is expanded. A Messaging Server expands a Distribution List by looking up the members of the Distribution List and sending each a copy of the message. A message addressed to a Distribution List is sent to its Mailbox Location for expansion.

In the case of nested Distribution Lists, the Distribution Lists are expanded at their own respective expansion points. For example, if Distribution List X contains Distribution List Y as a member, and Distribution List X has expansion point at server A and Distribution List Y has expansion point at server B, a message addressed to Distribution List X will be sent to server A for expansion into Distribution List Y and other members. That means a copy of the message addressed to Distribution List Y is generated. This message is then sent to server B where Distribution List Y is further expanded into its members. The main purpose of expansion point is to minimize traffic from message transfer and directory lookup (for distribution list members).

The Mailbox Location is an optional attribute, and need not be specified in the List Object. If it is absent from the List object, this indicates that MHS Services is free to expand the distribution list at any location.

Owner. The Owner property contains the name of administrator(s) of the Distribution List. When a message addressed to the Distribution List failed to be delivered to any member, then a non-delivery notification to the effect is sent to the Owner.

Member. The Member property contains the list of members of the Distribution List. Member can be a user, an External Entity, a Group, an Organizational Role, or another Distribution List.

Addressing External Users

In MHS Services, there are three ways to address external users:

  • Create an external entity in NDS and give it the appropriate foreign E-mail address. In this situation, the external user will appear in the MHS Extract File.

  • Create a user in NDS, and give that user an appropriate foreign E-mail address (but not an MHS mailbox). In this situation, the external user will also appear in the MHS Extract File.

  • If the addressee is an object that does not exist in NDS, enter a recipient address of the form x@y{type: address in the appropriate type}. For example, x@y{SMTP: bgg@ novell.com}. When the curly braces are present, an extended address is used and MHS Services will ignore the front portion of the address (in this case Ax@y@).

NetWare MHS MailSlots

NetWare MHS MailSlots is a set of MS Windows DLLs that enable Windows applications to send and receive mail messages using NetWare MHS. NetWare MHS MailSlots supports the following industry standard messaging APIs for NetWare MHS:

  • Common Messaging Call API (CMC)

  • Simple Messaging API (SMAPI)

  • Vendor Independent Messaging API (VIM)

MailSlots supports both SMF-71 and SMF-70.

To install NetWare MHS MailSlots, use the Run item in the File menu of the Windows Program Manager to run SETUP.EXE. SETUP.EXE can reside on a diskette, hard disk, network drive, or CD-ROM.

To use MHS MailSlots, select the "Send Mail" menu item within your mail-enabled Windows applications. MHS MailSlots then passes your messages to an MHS router, which routes your messages to the recipients. (Comprehensive online documentation is available within the MHS MailSlots dialog boxes.)

If you are a user of an MHS application (client) from a third-party developer or a user of FirstMail (bundled with NetWare 4), chances are you do not have support for mail-enabled applications. Suppose you have prepared a document or a spreadsheet and wish to mail it without quitting the application that created it. Firstly, the application must at least, provide a menu option like "Send" somewhere in it's menu structure (if this is so, the application is said to be mail-enabled). Secondly, it must provide support for at least one of the industry-standard APIs that enable a menu option like"ASend" to translate into a dialog box which allows you to (amongst other things) address and mail the document (or spreadsheet).

If an application implements VIM, the MailSlots implementation of VIM will ensure that the application talks to MHS at the back-end. Similarly, applications that talk to CMC will talk directly with MHS at the back-end. New mail-enabled applications written using VIM or CMC will work with MHS when MailSlots is installed. MailSlots also includes support for Simple MAPI through the provision of a DLL.

Some users may become confused between the Simple MAPI implementations of the Microsoft Mail Driver for MHS and the Simple MAPI implementation for MailSlots. These are distinct implementations. Simple MAPI with the MSMail client uses the Microsoft implementation that translates Simple MAPI calls into MAPI 0 calls, which in turn are translated to MHS specific actions by the MHS Driver. The Simple MAPI implementation provided with MailSlots is Novell's implementation, which translates Simple MAPI calls directly into MHS specific actions.

It is possible that users may wish to install both the MHS Driver for Microsoft Mail and MailSlots. This situation arises when you are a user of the MSMail client program and you install an application that does not support Simple MAPI, but does support CMC or VIM.

In this instance you may opt to install MailSlots, however, MailSlots will force you to choose between the Simple MAPI implementations in these products. In this case, you should choose to use the MS Mail implementation of Simple MAPI. MailSlots is available via NetWire.

MSMail Driver for MHS

The Microsoft Mail client (the MSMail application) is bundled with Microsoft Office and Windows for Workgroups. The MHS Driver for Microsoft Mail is developed in accordance to the Microsoft MAPI 0 architecture. This architecture allows the messaging system that the client works with to be replaced.

The MHS Driver forces this client to become an MHS client preserving the user's investment in the MSMail Client. In NetWare 4 MHS is built into the operating system, and users who have invested in the MSMail Client and NetWare 4 now have a complete messaging solution as a bonus from these investments.

When installed, the driver is inserted between MHS and the mail client. The Simple MAPI support provided by Microsoft with the client software also translates to MAPI 0 calls which are intercepted by the MHS driver allowing full Simple MAPI support with MHS.

The Driver will work with any SMF-71 compliant MHS Server and is also capable of efficiently supporting massive address books.

The MSMail driver for MHS is available on NetWire.

Connecting MHS and GroupWise

Connecting to or upgrading to GroupWise may be desired because of the following:

  • MHS Services is designed to communicate within its tree only; it is not designed to communicate among two or more installed NetWare 4.1 trees.

  • The MHS Server currently supports one message routing group, which means that all servers running MHS Services will attempt to communicate with all other servers running MHS Services. This can negatively affect network traffic.

  • MHS Services is designed to work across existing networks and not across asynchronous lines.

The GroupWise MHS Gateway and the MHS Connectivity Server allow GroupWise and MHS systems to communicate.

GroupWise MHS Gateway

The GroupWise MHS Gateway for NLM or DOS connects a GroupWise system to an MHS 1.5 or Global MHS mail system. The MHS Gateway translates message files from GroupWise format to SMF format and then transfers them to the MHS mail system.

The features included in the MHS Gateway are designed to provide transparent communication and messaging capabilities between two different systems. These gateway features make it possible for users of both systems not only to communicate, but also to make use of much of the functionality which the GroupWise and MHS-compatible E-mail systems provide.

The MHS Gateway allows GroupWise users to perform the following tasks:

  • Exchange E-mail messages and schedule requests with MHS users

  • Send attachments with messages

  • Receive status messages

  • Send passthrough messages

  • Enable automatic directory synchronization

The GroupWise MHS Gateway is sold separately from the GroupWise Admin/Client Packs and the Message Server Pack. (For more information, call Novell GroupWare Product Information at 800-861-2507 in the U.S. and Canada. In all other locations, contact your local Novell Authorized Reseller.)

The MHS Connectivity Server

The MHS Connectivity Server (MCS) connects a GroupWise system to MHS Services 1.x. Scheduled for release later in 1995, MCS is now being tested.

The MCS is part of Phase III of MHS/GroupWise convergence, and performs the following connectivity functions:

  1. Register in NDS as a peer Messaging Server object and effectively connect a GroupWise system, including gateways, to all MHS Messaging Servers in the NDS Routing Group.

  2. Synchronize the MHS addresses from NDS into the GroupWise directory.

  3. Convert messages between SMF and GroupWise Message File format.

Minor functionality enhancements available in MHS Services 1.1 Messaging Server cause GroupWise addresses to be synched from NDS into the MHS extract file(s). No NWAdmin modifications are necessary.

MCS allows MHS Services to leverage the power of GroupWise and GroupWise communications tools. With MCS, for example, MHS Services users can access GroupWise gateways and communicate with GroupWise clients.

MCS differs from previous MHS-GroupWise connections (gateways) in the following ways:

  1. NDS is used as the central source of address and configuration management.

  2. By interfacing with MHS Services as a Messaging Server in NDS, tighter integration between MHS and GroupWise is achieved.

  3. Interoperability problems found to exist between the GroupWise MHS Gateway and MHS Services are corrected.

General Design Scheme The goal of the MCS is to make the GroupWise system appear to MHS applications and gateways in a seamless fashion, and similarly expose the MHS system to GroupWise senders, as shown in Figure 1.

Figure 1: MCS connects to a variety of services.

The MCS is installed and configured much like the present GroupWise MHS Gateway, and thus appears to GroupWise agents as a gateway connection. Its Gateway Foreign Name is a valid NDS name representing an NDS Messaging Server object by which the MCS is known to the MHS/NDS world.

Gateway specific setup within GroupWise Admin includes specification of:

  1. A primary MHS Messaging Server to which the a MCS interfaces. This Messaging Server is MCS's link to the MHS Routing Group.

  2. A GroupWise foreign domain name. This domain iscreated by MCS and populated with MHS addresses imported from the NDS tree.

The MCS's install NLM (PINSTALL NLM) creates the Messaging Server object in NDS to represent the GroupWise system where the MCS resides, and specifies that its server type is Novell GroupWise (NGW). It also associates the MCS with the desired Routing Group.

When the MCS starts up, it checks NDS for a Messaging Server object bearing its configured name. The names of all other gateways in the GroupWise system are added to the Messaging Server object as "Supported Gateways."

As a Messaging Server object, the MCS makes its GroupWise system a visible peer to the MHS Messaging Servers in the Routing Group, rather than the destination of an SMF gateway associated with one server. It has MTA_IN and PARCEL subdirectories for MHS input from other Messaging Servers.

In order to synchronize the MHS and GroupWise directories, the MCS maintains a GroupWise foreign domain to correspond to the MHS Routing Group. Each MHS Messaging Server in the Routing Group is represented by a post office in this foreign domain. The MCS periodically and/or by operator action updates the post offices directly from the NDS tree.

To maintain GroupWise users in the MHS extract file(s), the MHS Messaging Server (1.1) has been modified to include objects with GroupWise addresses in its filter as it builds the file. Version 1.0 of the MHS Messaging Server can be used with the MCS to connect to GroupWise if GroupWise addresses are not needed in the MHS extract file (such as the case where GroupWise is used exclusively as a gateway hub and its native domains contain no users).

Consider a NetWare 4.1 configuration including the following:

  1. A Routing Group called MAIL_Group.mail which includes the following MHS Services 1.1 Messaging Servers:

    a. MSG_1.mailb. MSG_2.mailc. MSG_3.mail

  2. MSG_1.mail services users Dan, Scott, Wendy and Karen, all contained in admin.

  3. MSG_2.mail services users Jill, Camille, Shannon and Rick, all contained in mkt.

  4. MSG_3.mail services users Steve, Tom, John and Pam, all contained in engr.

  5. A GroupWise domain called GW_Mail containing the following:

    a. An MCS called MHSGATE (foreign name MSG_NGW.mail, foreign domain name MHSDOM and Routing Group MAIL_Group.mail, with MSG_1.mail as Primary Messaging Server) b. An SMTP gateway called SMTPGATE c. An MHS gateway called GMHSGATE connecting to Global MHS d. Post Office NORTH containing Ed, Sally and Joe; configured in NDS as ed.gwise.mail, sally.gwise.mailand joe.gwise.mail, respectively.

Once the MCS has run and directory information is exchanged, the MHS extract files include records for ed.gwise.mail, sally.gwise.mailand joe.gwise.mail. A GroupWise-type Messaging server called MSG_NGW.mail is found in the NDS tree, listing SMTP:SMTPGATE and MHS:GMHSGATE as supported gateways. The GroupWise system has a foreign domain linked through the MCS called MHSDOM. MHSDOM supports three post offices:

  1. MSG_1_mail containing users:

    Dan (alias dan@admin) Scott (alias scott@admin) Wendy (alias wendy@admin) Karen (alias karen@admin)

  2. MSG_2_mail containing users:

    Jill (alias jill@mkt) Camille (alias camille@mkt) Shannon (alias shannon@mkt) Rick (alias rick@mkt)

  3. MSG_3_mail containing users:

    Steve (alias steve@engr) Tom (alias tom@engr) John (alias john@engr) Pam (alias pam@engr)

MHS-to-GroupWise Message Flow. SMF messages can be explicitly addressed to GroupWise (via the MCS) or one of its supported gateways. To address a native user in the GroupWise Domain(s), the keyword "NGW" is specified in the address extension. Such messages will be routed through the MCS by the MHS Messaging Server. A message is routed out one of the GroupWise gateways by specifying the gateway's name as the extension keyword.

If a destination is specified by an NDS name only, or if the address extension is not routable, the MHS Messaging Server looks up the object in NDS to find its mailbox. This logic has been modified (in version 1.1) to look for a GroupWise address for the object if no MHS address is found. These messages will also be routed to the MCS by the MHS Messaging Server.

Using the previous configuration example, GroupWise user Ed can be addressed from MHS using any of the following forms:

  1. ed@gwise.mail

  2. <don't care<@<don't care< {NMHS:ed@MSG_NGW.mail}

  3. <don't care<@<don't care< {NGW:GW_Mail.NORTH.ED}

Similarly, if NDS includes an External Entity called BFrank.SMTP.extern, and this object has a foreign E-mail address SMTP:bfrank@novell.com, he may be addressed from MHS using either of the following:

  1. BFrank@SMTP.extern

  2. <don't care<@<don't care< {SMTP:bfrank@novell.com}

GroupWise-to-MHS Message Flow The GroupWise sender can use gateway addressing to explicitly route messages through the MCS. A valid MHS address can also be obtained by the MCS if the sender picks a user from the MCS's foreign domain, since the user's complete NDS Distinguishing Name is stored as an MHS gateway alias.

The MCS addresses an SMF message to the MHS address derived from the recipient's NDS distinguishing name and sends the message to its primary MHS Messaging Server.

Given the user John in the sample configuration, he can be reached by either of the following To: line addresses:

  1. MHSDOM.MSG_3_mail.john

  2. MHSGATE:john@engr

SNMP Management The MCS is instrumented to be managed remotely via SNMP. An SNMP MIB file ships with the MCS, enabling SNMP consoles to monitor its performance. This MIB file includes NetWare Management System (NMS) extensions for on-line help.


Note: MHS Services 1.1 must be deployed in order for GroupWise addressesfrom NDS to be included in the MHS Extract File.

Global MHS Access Module for MHS Services

The Global MHS Access Module for MHS Services (GAM) provides a migration path for organizations using earlier generations of Novell's MHS product family, such as Global MHS and MHS 1.5 (DOS-based). GAM enables customers to retain their investment in third-party messaging gateways to these previous generations of MHS.

As shown in Figure 2, GAM was designed to facilitate communication between MHS Services users and Global MHS users.

Figure 2: GAM links Global MHS and MHS Services.

Running on a NetWare 4.1 server, GAM exchanges MHS-based E-mail (that adheres to the SMF-71 standard) between the two messaging environments.

What's In a Name?

MHS products prior to the NLM-based Global MHS supported only a short name format for recipients of E-mail. Jack Smith might be given an E-mail name of jsmith@novell. Both of the fields - "jsmith" and "novell" - were limited to a maximum of eight characters each, as per the SMF-70 specification. Therefore, if two employees named Jack Smith worked for Novell, administrators were forced to use middle initials or some other characters to distinguish between them.

Global MHS enabled the use of the long name format, which provides a more natural form of addressing E-mail recipients; for example, jack smith@sales.provo.novell. Maintaining unique names became easier as long as there was only one Jack Smith working within the Sales department at Provo. This naming scheme is also referred to as hierarchical in that Anovell@ is at the top of the naming hierarchy, "provo" is one level below "novell" and "sales" is a level below "provo".

Global MHS actually supports both the short and long naming conventions. These names as well as several other messaging-related items are kept in a hierarchically-organized, distributed directory specific to Global MHS.

In contrast, MHS Services relies on the NetWare Directory built into the NetWare 4 operating system to identify users and distribution lists. Consequently, the NDS Distinguished Name for user and list objects are synonymous with their E-mail names. The naming scheme within NDS is based on a hierarchical tree structure. In Figure 3, for example, both "sales" and "provo" could be represented as Organizational Unit container objects within ahypothetical Organization container named "novell".

Figure 3: MHS Services relies on NDS to identify users and lists.

NetWare 4.1 users that have E-mail accounts under MHS Services do not have short name SMF aliases. They are known only by their hierarchical, long names within the NDS directory of NetWare 4.

Users of E-mail in both messaging environments, Global MHS or MHS Services, rely on Public Address books to simplify the selection of E-mail names that are inserted in the TO: and CC: fields when composing messages to be sent. These address books are derived indirectly from the directory of the system on which the messaging servers exist:

  • The Global MHS messaging-specific directory in older environments

  • The NetWare Directory within the NetWare 4.1 Operating System for users of MHS Services

GAM synchronizes the E-mail names between these two directories so that users of MHS Services will see Global MHS users in their Public Address book and likewise users of Global MHS will see MHS Services users in their Public Address book.

Obviously, the primary role of GAM is to relay E-mail messages between the two systems.

How Does the Mail Get There?

Figure 4 illustrates the message flow and the high-level architecture of GAM. GAM runs on a NetWare 4.1 server on which MHS Services is also installed. GAM appears as a gateway to MHS Services and requires that a SMF-71 gateway be configured on the contact Global MHS server.

Figure 4: The high-level architecture of GAM.

Note that the GAM Administration utility executes as a runtime extension ( a snap-in) to the NWADMIN (Windows-based) utility used to administer the NetWare 4 NDS directory.

GAM periodically performs a server-to-server bindery login to the contact Global MHS server, picks up SMF-71 E-mail messages, translates the addresses in their envelopes into a form suitable to the destination messaging system, and then deposits the mail into the destination gateway file system sub-directory. Stated differently, messages from the Global MHS server (if any exist) are picked up and deposited into a MHS Services gateway file system subdirectory and messages from the local MHS Services server (if any exist) are picked up and deposited into a Global MHS gateway file system subdirectory during each login session.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates