Using NetWare 3.12

book cover

Chapter 23

Message-Handling Services

Novell's MHS (Message-Handling Service) is one of many electronic mail transport and messaging standards available today. This chapter looks at the following topics:

Included with NetWare 3.12 is a Basic MHS. This chapter discusses its installation, as well as how to use FirstMail. (FirstMail is a user application front end that comes with NetWare 3.12 and is discussed shortly.) NetWare 3.12 provides all the necessary pieces to implement e-mail on your network.

This chapter is not meant to provide an in-depth look at MHS, nor is it intended to provide detailed installation and troubleshooting steps for implementing MHS. However, sufficient information is provided to get you up and running so that you can use MHS in a productive manner.

What Is Novell's MHS?

When discussing LAN-based electronic mail, references often are made to the terms front end and back end. The front end, or user agent (UA), is the software application you use to read, reply to, and compose messages. The back end, or message transfer agent (MTA), is the application that does mail delivery, transporting messages between systems (locally or remotely). In other words, the user agent (front end) makes outgoing message delivery requests to the message transfer agent (back end), and the message transfer agent delivers incoming messages to the user agent (see fig. 23.1).

To facilitate message transfer between remote systems and locations, MTAs communicate with one another, either via asynchronous protocols (over dial-up lines) or internetwork protocols (over LAN and WAN links). This "network" is referred to as the message transfer system.

Novell's MHS is a transport engine. You should not confuse Novell's Message-Handling Service with the Message-Handling Systems of CCITT's X.400 specification. Although they provide similar functionality, they are not the same. In this chapter, unless otherwise indicated, any reference to MHS is to Novell's MHS.

As mentioned before, MHS is one of the industry's messaging and e-mail transport standards. MHS is composed of two layers: the transport services and a message-format specification. More about both layers in the next section.

The NetWare messaging product family includes the following products:

For example, your remote NetWare 2.2 LAN can exchange e-mail with Global MHS running on your NetWare 3.12 LAN at the head office by running MHS. Users on the road can use Remote MHS to call in and pick up or drop off e-mail. You can mix and match these products to meet your particular environment.

Have you ever been in a situation in which your office is using one e-mail package, the party you need to send a message to is using another, and you cannot communicate? You will not face this dilemma if both e-mail packages use MHS or have an MHS gateway. It does not matter what front end you use; as long as MHS is used as the back end, you can exchange messages.

Currently, well over 100 commercially-available electronic mail products support MHS directly. You also can use MHS gateways to exchange messages with other non-MHS e-mail platforms, such as cc:Mail, Microsoft Mail (MS Mail), WordPerfect Office (WPO), UNIX/SMTP (Simple Mail Transfer Protocol), and so on. The last section of this chapter, "MHS Connectivity," discusses how to enable these different e-mail packages to exchange messages with each other.

How Does MHS Work?

In a way, sending an e-mail via MHS can be directly compared to sending a letter by way of the postal service. Consider the steps when a letter is sent through the postal service:

  1. You write the letter.
  2. You put the letter in an envelope and address the envelope.
  3. You drop the letter into a mailbox.
  4. The post office picks up the letter from the mailbox.
  5. The letter is routed to the post office nearest the recipient.
  6. The letter is delivered to the recipient.

The steps for sending e-mail using MHS are analogous:

  1. You compose the message using a user agent.
  2. The user agent adds on the necessary header information.
  3. The user agent writes the file to a predefined directory on the MHS server.
  4. The transport agent picks up the message.
  5. The transport agent determines the address and forwards the message to the MTA nearest the recipient.
  6. The receiving MTA delivers the message to the recipient's user agent.

Now that you know what steps an MHS e-mail message goes through when it is sent, you need to examine the MHS components that make those steps possible.

Within its framework, an MHS is made up of the following two services:

Associated with these services are two types of MHS protocols:

Standard Message Format

The Standard Message Format (SMF) is file-based. This means that the message itself is a text file that conforms to the SMF protocol. You submit the message for delivery by writing it to a designated directory.

The SMF protocol provides the following two specifications:

SMF user agents interact with transport engines through the SND, PARCEL, and USERS directories. When an user agent submits a message for delivery, for example, the user agent must place the message file and any associated attachments in the following directories:


Note that the NetWare SYS:MAIL directory structure is not used by MHS.

If you know the keywords (and their associated syntaxes) for SMF, you can create messages manually for delivery by the transport engines. You do not need a front end. However, using a front end based on a graphical user interface (GUI) helps tremendously.

Three versions of the SMF specifications currently are in use:

• SMF-64. The native interface for MHS 1.1 (circa 1988). This specification limits user and workgroup names to eight characters, one file attachment per message, and one recipient per message.

• A workgroup is a logical grouping of users who frequently exchange messages with each other. A more detailed discussion of workgroup and its naming scheme is presented shortly in the section "Workgroups, Workgroup Names, Hosts, and Usernames".

• SMF-70. The native interface for MHS 1.5 (circa 1991). This specification limits user and workgroup names to eight characters, 64 file attachments per message, and up to 64 recipients in a single transmission instance of a message.

• SMF-71. The native interface for Global MHS 2.0 and MHS 2.0 (circa 1992). This version removes the eight-character naming restrictions and allows for an unlimited number of message recipients. Among this specification's many enhancements are distribution-list support, auto-forwarding, and notification information.

Transport Protocols

After a message has been submitted by the user agent, the MTA automatically picks it up (based on a schedule the user can configure). After determining the recipient's address, the MTA then either delivers the message locally or forwards the message to another MTA for a gateway that will deliver the message. This feature is known as store-and-forward. Messages are stored in one location and then forwarded to another location until they arrive at their destination. This process is similar to the postal system, as well as e-mail exchanges on the Internet, FidoNet, and so on.

Depending on the type of link that exists between two MTAs, the NetWare Internetwork Messaging Protocol, or NIMP, is used for LAN and WAN links; the NetWare Asynchronous Messaging Protocol, or NAMP, is used for dial-up links (see fig. 23.4). The NIMP uses IPX as the LAN transport protocol. The NIMP and NAMP protocols are built into Global MHS. Basic MHS does not have the NIMP/NAMP protocols because it cannot exchange messages with other servers.

Workgroups, Workgroup Names, Hosts, and Usernames

As mentioned earlier, a workgroup is a collection of users operating with a common organizational name (a workgroup name) in the MHS messaging network. This resembles the way groups are organized for NetWare security.

A workgroup name may be the name of a company or the name of a particular group within a company. This group can be a department or division within your company. You can even have multiple workgroups within one department. An MHS host is the machine running the MHS software, regardless of whether the machine is stand-alone or part of a network.


When you choose a workgroup name, be sure to select one that is meaningful, especially if you will be communicating with people outside your organization. For example, Sales, Engineering, and Support, are all meaningful workgroup names.


If you will be connecting to a public MHS hub (such as CompuServe), it is necessary that you check and register the workgroup name you intend to use with the hub before you implement your MHS workgroup.

Workgroup names must be unique among the workgroup names and host names assigned to the hubs and hosts through which your group's communications will pass.

Usually, an entire network is set up using a single MHS Host, independent of the number of workstations in the LAN. This set up is called a single-host workgroup. Local users exchange mail directly through this host. In a WAN MHS network, messages are moved from one host to another until they arrive at their destinations.

In certain cases, due to the number of users, more than one MHS host may be necessary for the workgroup. This kind of set up is called a multihost workgroup, or domain. For more information on domains, see the section "What Is Global MHS" later in this chapter.

To give your LAN users access to MHS-based e-mail, you have to define the users in the MHS user database. Depending on the version of SMF that your network supports, your MHS usernames may be restricted to eight characters or less.


As with workgroup names within a given network, it is important to make sure that your MHS usernames are unique within a given workgroup.


In many cases, when a network is using specifications SMF-64 and SMF-70, the administrator makes the MHS usernames the same as the NetWare usernames. With this naming convention, users only have to remember one username.

MHS Address

A standard MHS address contains a username, an application name, and a workgroup name. The application name normally is hidden from the user by the user interface (user agent), and is optional. Therefore, the standard form of an MHS address is

• Username@Workgroup

MHS names are not case-sensitive.

Now that you have a basic understanding of the various MHS building blocks, the next section lists the steps necessary to install the back end and user agent that are shipped as part of NetWare 3.12. These are, respectively, Basic MHS and FirstMail.

Basic MHS

Bundled with NetWare 3.12 is Basic MHS, a back end that provides message delivery on a single server only. Basic MHS cannot communicate with other workgroups. Also shipped with NetWare 3.12 is a simple user agent called FirstMail. You don't have to use FirstMail with Basic MHS. You can use any MHS-compliant user agent with MHS. Some of these other options are presented in the next section; in this section, however, you learn to successfully install Basic MHS and FirstMail.


Although the version of Basic MHS shipped with NetWare 3.12 is a 1000-user version, Novell recommends that Basic MHS works best with systems having fewer than 30 users.


Depending on your volume of e-mail, Basic MHS should easily handle 100 or more users. If you find the performance slower than you like, consider upgrading to Global MHS.

Installing Basic MHS

You must perform 10 steps to install Basic MHS on your NetWare 3.12 server, The installation is performed using the INSTALL.NLM at the file server console, and you are prompted for all necessary information.


Basic MHS comes on two disks, labeled BASICMHS_1 and BASICMHS_2.

Assuming that you are installing Basic MHS from the floppy disks, perform the following 10 steps:

1. At the file server console prompt, type LOAD INSTALL.

2. From the Installation Options menu, choose Product Options.

3. At the Currently Installed Products screen, press the Insert (Ins) key.

4. Insert the disk labeled BASICMHS_1 into your floppy drive, type the drive letter at the prompt (see fig. 23.5), and press Enter. (The default is drive A.)


If you are installing from the CD-ROM, the path is VOLUME:NETWARE.312\ENGLISH\BASICMHS.

1. Enter Y to accept the workgroup name; enter N to create a new one (see fig. 23.6). If you choose to use a new workgroup name, you are prompted for the long name and the short name.

2. Notice that the file server name is used as the default workgroup name, and the default workgroup's short name is derived by taking the first letter of the first word and the first seven letters of the last word.


If you expect high e-mail traffic volume, consider installing MHS files on a separate volume. This prevents your SYS: volume from running out of disk space unexpectedly.

1. Enter Y to install Basic MHS into SYS:MHS. Enter N to specify a path (including volume) of your choice. The installation process creates the necessary directory structure and assigns the necessary NetWare rights (see fig. 23.7). After some files have been copied, you are prompted to insert Disk 2.

2. Enter Y to add existing users from the NetWare bindery to the messaging service database. Enter N to skip (see fig. 23.8).


It is strongly advised that you add all your users to the bindery before installing Basic MHS. The installation then adds any user in the bindery to the mail list, thus saving you from having to enter the information twice.


Step 7 inserts users included in the EVERYONE group into the mail list. If you have any users not listed in the EVERYONE group, but you want to include them in the mail list, you must add them manually using the ADMIN utility described in the next section.

1. Enter N if you want to use login names as mail IDs.


If you intend to use users' full names for their mail IDs, make sure that you use SYSCON to fill in the Full Name section.


If the e-mail front end does not support long names (as, for example, a SMF-71-compliant interface does not), enter N at step 8.

1. Enter Y to update the System Login Script. In order to use Basic MHS and the ADMIN utility, users must have a search drive mapped to the MHS\EXE directory and must have set an environment variable named MV (see fig. 23.9).


Updates are inserted at the beginning of your System Login Script. You may want to move them so that your MAPs are grouped together.

1. Enter Y to update the AUTOEXEC.NCF file. This adds the necessary commands to load Basic MHS automatically when the server boots up (see fig. 23.10).

When the installation is complete, a Full Installation: Successful message appears at the bottom of your screen (refer again to fig. 23.8). When you are returned to the Currently Installed Products screen, notice that NetWare Basic MHS is now listed (see fig. 23.11).

You should now reboot the server to ensure that the Basic MHS NLM loads correctly. If the NLM load is successful, you see a Basic MHS status screen, shown in figure 23.12. During normal operations, status messages may be displayed on this screen (see fig. 23.13). For information about the option switches for loading BASICMHS, consult the file ADMIN.DOC on the BASICMHS_1 disk. They also can be found in your \MHS\SYS directory on the file server.


Should you encounter any errors during installation, your best bet is to remove Basic MHS and reinstall it from scratch. Consult the MESSAGES.DOC file located on the BASICMHS_1 disk for a description of any error messages you encounter.

Now you are ready to configure Basic MHS for use.

Configuring Basic MHS

Before using Basic MHS, you may wish to customize its operation, such as by modifying the message delivery frequency and global distribution lists.

You use the ADMIN.EXE utility to configure Basic MHS. The ADMIN.EXE program is copied to \MHS\EXE during installation. You have to load the Btrieve Requester (BREQUEST.EXE, located in SYS:PUBLIC) on the workstation before you can run ADMIN.


Remember to load BREQUEST.EXE before you run ADMIN.EXE. If you do not load BREQUEST first, ADMIN tells you to load it. Sometimes, however, neglecting to load BREQUEST results in your workstation locking up without any message.

When you run ADMIN.EXE, you can use the Admin Functions menu to perform the following functions (see fig. 23.14):

In most instances, you just have to run ADMIN to manage the global distribution list. Only occasionally will you have to add or remove user mailboxes manually.

The user interface is easy to understand and use. The standard Novell F1 help key is available. You must log in to ADMIN as Supervisor or equivalent in order to run the program (see fig. 23.15). Otherwise, you can only view the database.

When you choose the Users option from the Admin Functions menu, you can obtain a list of all currently defined users within MHS (see fig. 23.16). To add a new user, simply press the Ins key. A corresponding NetWare bindery user account is also created.

To define and maintain public distribution lists from ADMIN, choose the Distribution Lists option from the Admin Functions menu. Then press Ins to create a new list. You are prompted for the necessary information. You are first prompted for a distribution list name (see fig. 23.17); then you need to specify which users are to be included in the distribution list (see fig. 23.18).

Basic MHS has to know the MHS applications for which it is routing messages. Normally, you do not have to define the applications for MHS. This usually is accomplished as part of installing the MHS-compliant application. However, if a particular MHS application does not do that, then you need to use the Applications option from the Admin Functions menu to manually define it.

Finally, you can choose the Configuration option from the Admin Functions menu to establish how often MHS checks and delivers queued messages (see fig. 23.19).


You can find detailed information about ADMIN.EXE in the README.TXT and ADMIN.DOC files in the MHS\SYS directory.

After you are satisfied with the configuration of the system's parameters, you are ready to test the installation.

Testing Basic MHS with FirstMail

The easiest way to test whether you have installed and configured Basic MHS correctly is to send some test messages using FirstMail. As you learned earlier, FirstMail is a user agent installed with Basic MHS. You do not have to use FirstMail with Basic MHS. You can use any MHS-compliant e-mail program, as long as it uses the SMF-70 or SMF-71 specification.

FirstMail is not installed as part of the Basic MHS installation; you install it separately. FirstMail is on a single disk labeled FirstMail v1.0 for DOS. Simply copy all the files from the disk to a directory on the file server. Read the file README.TXT for more details.

To invoke FirstMail, you type MAIL at the DOS prompt, and a screen similar to the one shown in figure 23.20 appears. If you have new mail waiting, a screen like the one in figure 23.21 is displayed.

FirstMail provides standard e-mail features, including file attachments, message forwarding, and return receipt (see fig. 23.22).

Soon after you send the message (to Demo User in this example), you see the delivery status of the message (refer again to fig. 23.13) on the server's Basic MHS status screen.

You then can sign on as the Demo User and select the Check for New Mail option to check for the incoming message (see fig. 23.23). Read the message; then to get to the file attachments, use the eXtract menu option shown at the bottom of the screen. A screen similar to the one shown in figure 23.24 appears.


The new-mail notification program (NEWMAIL.EXE) shipped with earlier copies of Basic MHS v1.0 does not work as advertised. NEWMAIL.EXE v1.1 (May 24, 1993; 12686 bytes), however, shipped with later copies of Basic MHS v1.0, does work.

Other MHS Applications

Keep in mind that e-mail is not the only use for MHS. MHS is essentially a communications protocol, so it has many uses. In this section, a couple of MHS-based e-mail products are reviewed, followed by some utilities that make use of MHS (known as MHS-enabled products).


The applications discussed in this section represent only a small sample of those available. Novell publishes a NetWare Messaging Solutions Guide, which you can order by calling 800-NETWARE if you are in North America. Or you can contact your local Novell office or Novell Authorized Reseller.

You also can download the August 1992 version of this guide from CompuServe. It is available as the file MHSSOL.ZIP in the NVENA forum, Library 4.

Pegasus Mail

Pegasus Mail (PMail), by David Harris of New Zealand, is an electronic mail system for use with Novell NetWare versions 2.15a and later. It is a full-fledged e-mail package, and one of its more unusual characteristics is that it is free—not shareware, but freeware. You can use it without charge, restriction, or obligation, on as many servers as you want.

To run Pegasus Mail, you need DOS 3.0 or later and 384K of RAM on the DOS workstation. Although it runs fine from within Microsoft Windows, a native Windows version (WinPMail) is available. A Windows .PIF file and icon are provided with the DOS release.

You may notice that PMail looks very similar to FirstMail (see fig. 23.25). As a matter of fact, FirstMail is a slightly stripped-down version of PMail! (Call it PMail Lite, if you will.) PMail has an additional feature not commonly found in other e-mail packages: it lets you define custom forms and add custom menu entries.

You can reach David Harris at

• Pegasus Mail
c/o David Harris
P.O. Box 5451
Dunedin, New Zealand

• (64) 3-453-6880 (voice)
(64) 3-453-6612 (fax)


The latest version of PMail is 3.01. It is available for DOS, Windows, and Macintosh platforms. You can find them on many BBSs, including CompuServe, and on the Internet.


ExpressIT! from Infinite Technologies is one of the best MHS-based e-mail packages available commercially. This program is available in DOS, Windows, and OS/2 versions.

ExpressIT! Electronic Mail is a comprehensive electronic mail system for your Novell NetWare network. This is one of the very few memory-resident e-mail packages. Using overlay files enables ExpressIT! to run in less than 2K of resident workstation memory.


If you use ExpressIT! for DOS on a properly configured 386 or 486 machine, your conventional-memory overhead may be as low as 0 bytes!

ExpressIT! provides native support for Novell's MHS and NetWare Global MHS. Although neither Novell product is required to install ExpressIT!, these products enhance ExpressIT!. The Novell products offer delivery services that facilitate dial-in/dial-out communications, as well as connectivity (via gateways) to other popular electronic mail systems and standards. These include CompuServe, X.400, SMTP, MCIMail, and popular mainframe- and minicomputer-based electronic mail systems.

In addition to the network version of ExpressIT! Electronic Mail, Infinite Technologies offers ExpressIT! Remote (both DOS and Windows versions) to provide dial-in access to MHS-based e-mail from your notebook, laptop, or home PC.

You can reach Infinite Technologies at

• Infinite Technologies
11433 Cronridge Drive, Suite H
Owings Mills, MD 21117 U.S.A.

• (410) 363-1097 (voice)
(410) 363-3779 (fax)

Figure 23.26 shows a sample opening screen from ExpressIT! for DOS.


PageIT!, another product from Infinite Technologies, extends the reach of your electronic mail system by converting your alphanumeric pager into a portable message center. Using PageIT! you can send complete messages to field-based personnel in words and sentences, without ever picking up the phone.

PageIT! provides a gateway interface from MHS-compatible e-mail systems to full-text alphanumeric pagers. After PageIT! is installed, you can send a beeper page as easily as you can send e-mail from any MHS-based e-mail system.

The PageIT! gateway runs on your (DOS) MHS server and utilizes the modem you are currently using for MHS communications. Because PageIT! is running as a gateway, your users only have to compose and address the e-mail; the gateway handles all the communications to the pager service. You only have one interface to learn: your e-mail's.

Before you can use PageIT!, you must have your MHS server and e-mail system installed and operational, with a Hayes-compatible modem installed in the MHS server.


PageIT! is compatible with any alphanumeric paging service that uses the IXO transfer protocol. Before you install PageIT!, you should call the technical support or service department of your local pager company to ensure that they support the IXO protocol system. (Note: In some countries, the IXO protocol is also known as TAP or PET.)

As noted before, you can reach Infinite Technologies at

• Infinite Technologies
11433 Cronridge Drive, Suite H
Owings Mills, MD 21117 U.S.A.

• (410) 363-1097 (voice)
(410) 363-3779 (fax)


FaxWay is another MHS-enabled office automation tool. Developed by EmTek Systems, FaxWay is a fax gateway for MHS mail systems. It enables you to send fax documents directly from your e-mail program by way of a CAS-compatible fax card or server. As with PageIT!, your e-mail users can easily send fax documents using the same e-mail system they are familiar with, without having to learn another front end.

FaxWay converts the text of an MHS message into a fax cover sheet. Any file attachments are converted to follow-up sheets. Attached files can be PCX or DCX images or plain-text files.

You also can send faxes to multiple recipients at one time (that is, broadcast). This can simplify having to send the same information and follow-up sheets to multiple fax numbers.

FaxWay keeps users informed of the status of their faxes. In the event that a transmission fails, detailed information about the failure is sent immediately to the user through e-mail. If you want, e-mail notification can always be sent—even when a transmission has been completed successfully (see fig. 23.27). In this way, users know the exact date and time the fax was sent and how long it took to transmit. This feature simulates the transmission-confirmation option on your fax machine.

To run FaxWay, you need the following:

• MHS version 1.5 (SMF-70) or later, running the Connectivity Manager on a regular basis.

• An MHS-based e-mail application (a given).

• A CAS-compatible fax board in the MHS machine and all necessary fax drivers loaded. Alternatively, you can have a CAS-compatible network fax server to which the MHS machine is logged in.

• You can reach EmTek Systems at

• EmTek Systems
26180 Raine
Oak Park, MI 48237 U.S.A.

• (313) 968-4227 (voice)


ERR/Monitor, a network-management tool from Loren Data Corporation, is an MHS gateway that checks the SYS:SYSTEM\SYS$LOG.ERR error log file on NetWare 3.1x servers, and the VOL$LOG.ERR file on each volume, for new entries. If a new entry is found, it is e-mailed to the predefined users. ERR/Monitor also supports SFT-III (NetWare 3.11). It looks for the existence of the IO$LOG.ERR file, and monitors the file if found.

ERR/Monitor can monitor multiple file servers—the number is limited only by the number of servers in which the MHS hub is simultaneously logged/attached.

Initially, the software sends messages for all alerts found in the log files. When it sends a message that it has not seen before, it learns that message and stores its pattern in a data file. The Alert Filter Screen enables you to turn off the sending of particular alerts in the SYS$LOG.ERR files (see fig. 23.28). Initially, only the System time changed alert is in the file. As ERR/Monitor runs on your system, it learns each alert it detects and informs you, in the e-mail message, that the new alert has been added to the list.

PRODUCTION: Be aware that from here on, electronic file names for

You can send messages to multiple users by using standard MHS addressing conventions, such as user1@hub1, user2@hub2 ... (see fig. 23.29). The software handles extended addressing, which gives you access to other e-mail systems and gateways as supported on your system.

ERR/Monitor detects automatically all NetWare file servers on your network. By entering the File Server List screen, you can toggle on and off monitoring support for each file server.

You can reach Loren Data Corporation at

• Loren Data Corporation
7334 Topanga Canyon Blvd., Suite 116
Canoga Park, CA 91303 U.S.A.

• (818) 226-5500 (voice)

What Is Global MHS?

Similar to Basic MHS, NetWare Global MHS (GMHS) is an NLM-based product designed to run on NetWare 3.1x platforms. The major difference between Global MHS and Basic MHS is that Basic MHS is designed for a single-server environment. It cannot route messages to other servers. Global MHS, on the other hand, is designed to meet enterprise-wide messaging needs. You can obtain optional protocol modules, such as SMTP, to run on top of GMHS and connect to non-NetWare platforms.


At the time of this writing, a NetWare 4.x version of Global MHS is not yet available. Global MHS v2.0x and lower will not load on a NetWare 4.x server.

GMHS provides these two important advantages:

• Optional messaging protocol modules

• Directory synchronization

Traditionally, gateways tend to be dedicated workstations. With GMHS, you can replace the dedicated workstations with a single server—thereby reducing and simplifying administrative overhead. At the same time, you reduce the amount of network traffic occurring between your gateways and the server storing mail messages.

Currently, three protocol modules are available for GMHS:

1. SMTP (Simple Mail Transfer Protocol) is for connecting to UNIX mail.

2. SNADS (SNA Distributed Services) is for connecting to IBM mainframe mail, such as DISOSS.

3. The X.400 module is for connecting to X.400 services.


The X.400 protocol module is developed by Retix Corporation. However, under a partnership agreement, you can order the Retix X.400 for NetWare Global MHS product through the Novell channel.

Directory synchronization provides simplified administration by automatically updating usernames, workgroups, distribution lists, and routing information among all GMHS servers.


A detailed discussion of Global MHS is beyond the scope of this book. However, Novell offers a two-day course on NetWare Global MHS. Contact your local Novell Authorized Education Center or call Novell at 800-233-3382 (or 801-429-5508) and ask about "NetWare Global MHS," Course #720.

Before the steps to install and configure Global MHS on your server are presented, you need to understand two concepts that are new for GMHS:

• Administrative domain

™B7 Root workgroup

An administrative domain (or simply domain) is the logical collection of servers and workgroups that share common access needs, such as access to distribution lists for e-mail. Domain is very similar to the "group" usage concept applied when you assign trustee rights.

You can have multiple domains within your organization. Directory synchronization, however, only works within a domain. Each domain is given a name and password (to control directory-synchronization security) when you install GMHS.

Root workgroup is used to control routing of messages. All servers and workgroups within a domain have the same root workgroup name. Any message that ends with the name of a different root workgroup indicates that the message is not in the same domain and must be handled differently (that is, routed).

Preparing for GMHS Installation

For this GMHS installation, make the following assumptions:

• Domain name = DreamLAN

• Root workgroup name = Consulting

• Message server name = Consult-1.Consulting

• Default workgroup name = LAN Group.Consulting


The Message Server Name does not have to be the same as the file server name. Just make sure it is readily identifiable and unique within your domain.

Before you install GMHS, make sure that your server is ready:

1. You should have all the GMHS disks: four for GMHS, one for AIO (serial adapter) drivers; one for FirstMail for DOS; and one for FirstMail for Macintosh—a total of seven (7) disks for GMHS v2.0b.


Before you open the disk envelopes—before you even open the "Red Box"—check to make sure that you have the correct number of user licenses (mailboxes) to meet your requirements. GMHS is licensed independently of your NetWare user licenses.

1. Your server must have at least 8M of RAM, in addition to your normal server requirements. For example, if you require 8M of RAM for your server without GMHS, you must have 16M to run GMHS.

2. Each MHS user must have 8M of free disk space, plus (recommended) 500K of free disk space per mailbox. (This is site-specific, depending on your e-mail application.)

3. You must be running NetWare 3.11 or later.

4. If you are running NetWare 3.11, make sure that you are using CLIB.NLM v3.11 Revision E (Feb. 3, 1993, 269642 bytes) or later; BTRIEVE.NLM v5.15 (Aug. 4, 1992, 66688 bytes) or v6.0b (Dec. 1, 1992, 146258 bytes) or later.


Do not use BTRIEVE.NLM v6.0 (May 7, 1992, 144922 bytes) with GMHS, as it can cause loss of data.

Do not use CLIB v3.11c (Nov. 20, 1992, 266432 bytes), as it can cause server crashes.

1. If you are using asynchronous dial-up connections, make sure that you have Novell-certified modems, serial I/O adapter, and drivers (for speeds greater than 2400 bps).


Consult the README.TXT file on Disk 4 of the GMHS disk set (in directory \NGM) for any new information that did not make it into the product manual.

Installing GMHS

As with the installation for Basic MHS, you must perform 10 steps to install Global MHS 2.0B. These steps are as follows:

1. If BTRIEVE.NLM is already loaded on your server, unload it and reload it with the -p=4096 parameter, as in the following:


1. At the file server console prompt, type LOAD INSTALL.

2. Choose Product Options.

3. When the Currently Installed Products screen appears, press the Insert (Ins) key. Insert the disk labeled Disk 1 of 4: Installation in your floppy drive, type the drive letter at the prompt (see fig. 23.30), and press Enter.

1. During the installation, you are prompted to provide the directories into which GMHS will install the files. The default for the NGM Messaging Area is SYS:NGM; for the MHS Messaging Area the default is SYS:MHS. If you have MHS 1.5 or Basic MHS installed, the install program can update them to GMHS (see fig. 23.31).


Serial I/O adapter (AIO) drivers are not copied by the installation program. You have to copy them manually into SYS:SYSTEM. If you have AIO drivers from other products, such as NetWare Connect, check the version of the existing drivers before copying the ones from GMHS disk.

1. Files are then copied (see fig. 23.32). You are prompted for the various disks as they are required.


The title of the menu (refer again to fig. 23.32) indicates NGM—NetWare Global Messaging. This is the previous name for Global MHS.

1. Enter the information required on the Domain Information screen (see fig. 23.33).

2. Enter the information requested in the Messaging Server information screen (see fig. 23.34). You must specify the root workgroup name as part of your message server name (see fig. 23.35).

3. When the installation is complete, a NGM has been installed successfully message appears on the your screen (see fig. 23.36). When you are returned to the Currently Installed Products screen, notice that NetWare Global MHS is now listed (see fig. 23.37).

4. Edit AUTOEXEC.NCF (see fig. 23.38) to include the following lines (assuming that you used the default directory path):


Now you are now ready to configure GMHS for a single-server environment.

Configuring GMHS

This section discusses some of the configuration steps you may want to take. These steps include creating distribution lists and importing users from the NetWare bindery into the MHS database.

Before you bring up GMHS, you have to verify a couple of things on your NetWare server—especially if you are using NetWare 3.12:

Version of CLIB. The GMHS install program copies over an older CLIB than the one that shipped with NetWare 3.12.

Version of BTRIEVE. The GMHS install program copies over an older BTRIEVE than the one shipped with NetWare 3.12.

If you are indeed running the newer CLIB and BTRIEVE NLMs, rename the ones in NGM\BIN to an extension other than .NLM so that the copy from SYS:SYSTEM is used instead. Or you can delete these two files from NGM\BIN.

To start GMHS, load any AIO drivers, if necessary, and then load NGM.NLM. NGM.NLM autoloads a number of other NLMs (see fig. 23.39).

If you are not using asynchronous connections—therefore not loading AIO drivers—you will see the error shown in figure 23.39. This error appears because the default GMHS configuration file shown in figure 23.40 (SYS:SYSTEM\NGM.CFG) asks to have NGMAMP.NLM (NetWare Asynchronous Messaging Protocol) loaded. You can edit the configuration file to leave out this NLM.

To configure GMHS, you must use NGMADMIN.NLM (the GMHS configuration program) from the server console. Type LOAD NGMADMIN and no parameters are required.

From the Main Menu, choose This Server. Then, if this is a new installation, choose Import Users from Bindery (see fig. 23.41). If you were running MHS before, choose Import Users from MHS.

After importing the users, you can verify they were added correctly. Go back to the Main menu and choose Workgroups, Users, and Dlists. Then choose Users (see fig. 23.42).


Notice that there is a username PETER-2. This name appears because an MHS user called Peter was specified as the postmaster during installation (refer again to fig. 23.34). A (NetWare) bindery user called PETER also exists, so the new name is changed to PETER-2 to avoid conflict.

The mail ID is independent of the NetWare login username. The two do not have to be the same. For easy troubleshooting, however, keep them the same or similar.


Generally, it's a good idea for you to add all your users to the bindery before you import bindery users into GMHS. The installation can then add any user in the bindery to the mail list and save you the trouble of entering the information twice.

Should you add a number of new users, however, you can "reimport" the users from the bindery with GMHS. Existing users are not re-created.

You also can configure (global) distribution lists—DList—for your users (see fig. 23.43). These lists are available to your MHS-compliant e-mail packages, such as FirstMail, Pegasus Mail, and ExpressIT!. The distribution lists are accessed from the Main Menu. Select Workgroups, Users, and DLists, and then select Distribution Lists. Press Ins to create a new list.

If you are going to use only one e-mail package, it is best to define that as the Preferred Application for each user. Then Global MHS knows where to deliver messages that do not specify the type of application in the SMF message header. The default Preferred Application is MHS.


Some e-mail applications, such as FirstMail, enable you to scan the MHS mailbox for messages. You then can leave the default Preferred Application as is.

You can use NGMADMIN.NLM to change the assignment: choose Workgroups, Users, and DLists; choose Users; choose the specific user; and then choose Preferred Applications (see fig. 23.44).

Now you are ready to test your installation using FirstMail.

Testing GMHS Using FirstMail

The FirstMail application is not copied as part of the installation for Global MHS. You have to copy the files manually from the distribution disk. There are two disks: one for DOS and one for Macintosh.

Before running FirstMail for DOS, you have to register it with GMHS so that the proper directories are created. This is done using FMCONFIG.EXE. From the main menu of FMCONFIG (see fig. 23.45), choose the NetWare MHS/SMF Interface option to inform FirstMail of your MHS/SMF setup. You have to specify the default workgroup, the version of SMF, and the location of the MHS files (see fig. 23.46). Finally, let FMCONFIG execute MHSUSER to register FirstMail as an MHS application with GMHS (see fig. 23.47).


Make sure that you have a search drive mapped to MHS\EXE before you run FMCONFIG. That is where MHSUSER (see fig. 23.46) is located.

From FirstMail, you can see all the (MHS) users and DLists (see fig. 23.48). Everyone, LAN Support, and Management are distribution lists.

You have two ways to confirm that mail messages are sent correctly: by signing on as the other user and checking for mail, or by using NGMADMIN.NLM. From NGMADMIN, choose Maintenance from the Main Menu, choose Statistics, choose the messaging server in question, and then select View Statistics. If you have configured the system correctly, the Rejected Messages line should contain 0 (see fig. 23.49).

Configuring GMHS for CompuServe Connection

GMHS comes preconfigured (via asynchronous links) for CompuServe (CSERVE) and Novell (NHUB) connections. These connections are defined as message servers within the Public Hubs foreign domain. This information can be obtained using NGMADMIN. From the Main Menu, select Foreign Domains, followed by Public Hubs, followed by Message Servers (see fig. 23.50).

In order to communicate synchronously, you have to configure the asynchronous connectivity portion of GMHS.

First, you must load either the COM port driver (AIOCOMX.NLM) or the appropriate multiport serial port driver if you have a multiport serial board installed. To load the COM port driver, enter the following command at the file server console:


This loads the driver for COM1.

The next step is to configure the asynchronous ports using the Configure Asynchronous Ports option under the This Server option in NGMADMIN.NLM (see fig. 23.51). After selecting Configure Asynchronous Ports, you are presented with a Configured Ports screen listing all the ports available. Select a port (COM1 based on our above example) and you are then presented with the Configuration screen (see fig. 23.52).

In the Configuration screen, you can put in a description for the port for easy identification. You have to tell GMHS whether or not the port is connected to a leased line (dedicated data link). If yes, then the subsequent fields are not applicable. You should specify the modem type and speed used. For more information about the fields on this screen, press the F1 key.

Next, choose the Server-to-Server Links option, located under This Server option in the Main Menu, and then choose to configure an Outbound Async Links.

Select the CompuServe link and fill in the necessary information, such as the phone number of your local CompuServe access node, and the Hub Service Login (see figs 23.53 and 23.54). Make sure that you entered your CompuServe ID and password.

Finally, change the Contact Messaging Server entry from NHUB to CompuServe (see fig. 23.55). You access this screen from the Main Menu by choosing Foreign Domains, choosing Public Hubs, and then choosing Foreign Domain Information.


If you do not make this change, all unresolved workgroup mail messages are routed to NHUB at Novell!

From the Main Menu, you can verify if your outbound mail is being sent to the right hub by looking at Maintenance and then choosing Queues. It should list CSERVE as the Messaging Server if you are sending to CompuServe (see fig. 23.56).

Shutting Down GMHS


If you are using Global MHS 2.0b or lower, the following instructions must be adhered to when you shut down your GMHS server. Otherwise, you risk abending your server or damaging your file system. (In standard NetWare terminology, abend means an abnormal END)!

It is uncertain when this problem will be fixed in future releases. Check the README.TXT file that comes with your set of disks or the product documentation.

The only way to shut down GMHS is to unload the NGM.NLM module. The server informs you that several processes are still running and it is not safe to unload NGM at this time. When you are prompted by

Do you want to unload anyway?

you should answer N. This enables NGM to complete whatever it is processing currently, unload the related NLMs, and then unload itself (see fig. 23.57). This can take more than five minutes.

MHS Connectivity

One of the most commonly asked questions in networking (other than "How do I connect my networks?") is "How do I exchange mail with other people?" If the same product is used among your sites, then the solution is usually straightforward. Most e-mail packages provide a gateway option to exchange mail between "post offices." But what if you need to exchange mail with people who use an e-mail package different from yours? What if they are not even running DOS?

Connecting to LAN-Based E-Mail

Some of the more popular e-mail packages used by medium- to large-sized companies are cc:Mail (now Lotus Mail), Microsoft Mail (MS Mail), and WordPerfect Office (WPO). So how I can exchange mail between my cc:Mail setup and the MS Mail someone else is running? The easiest way, if not the only way, is to use MHS! Both Lotus and Microsoft have an MHS gateway for their respective products. Similarly, WordPerfect offers a WPO-to-MHS gateway.

Some of the major vendors have announced application program interfaces (APIs) for accessing their message transport services. These APIs are similar to the concept of SMF for MHS. The Lotus specification is called VIM (Vendor-Independent Messaging); it was endorsed by Novell, Apple, Borland, and (to a limited extent) IBM. Microsoft's specification is called MAPI (Messaging Applications Programming Interface) and is a Windows-centric API. API libraries for VIM and MAPI, however, are not yet readily available. The MHS route remains the most wide-open solution today.


Novell has released a MAPI interface for MS Mail that enables the user to make use of MHS directly, rather than requiring an MS-Mail-to-MHS gateway.

Interested users can download the file MSMAIL.EXE from the NOVLIB forum on CompuServe.

Connecting to Non-LAN-Based E-Mail

The major connectivity issue you are likely to face today—apart from making connections between LAN-based e-mail systems—is connecting your LAN-based e-mail system to another platform (such as UNIX, AS/400, or an IBM mainframe).

A number of existing commercial and shareware programs enable you to connect your MHS e-mail system to UNIX systems. The connection can either be through UUCP (UNIX-to-UNIX CoPy) or SMTP (Simple Mail Transfer Protocol). For example, Novell has a SMTP protocol module for its Global MHS product, and WordPerfect's WPO v4 also has a SMTP option. These are commercial solutions.

Among the shareware SMTP solutions is XGATE from DAC Micro Systems (805-264-1700). You can download XGATE3.ZIP from the NOVUSER forum library on CompuServe.

UGATE is a shareware MHS-to-UUCP gateway with a twist. Rather than registering the product with the author, you are asked to send the registration fee to The Hunger Project, a global, nonprofit organization headquartered in New York City. You can download UGATE.ZIP from the NOVUSER forum library on CompuServe.

The MESSENGER AS/400 Gateway, a commercial product from Blue Rainbow Software International Corporation (404-612-1949), provides MHS connectivity to AS/400 computer environments running Office Vision/400.

Connections to IBM mainframes (DISOSS) can be achieved using, for example, the SNADS protocol modules for GMHS from Novell.

Gateways that connect MHS to X.400, MCIMail, AT&T Mail, FidoNet, Wang Office, VAXMail, and so on, are available from a number of vendors. Consult the NetWare Messaging Solutions Guide from Novell for details.

Connecting through CompuServe

Having a connection to CompuServe's MHS mail hub is one of the easiest ways to gain connection to other MHS sites, Internet, MCI Mail, AT&T Mail, Sprint Mail, and so on.

CompuServe's mail hub offers global connectivity. It enables you to communicate—economically and easily—to users all around the world. Anywhere you can access CompuServe, you have access to its mail hub.

You can readily access the CompuServe network in most of North America with a local telephone call, and throughout the world there are gateway connections to CompuServe. Consult your local carrier.

At the present time, CompuServe supports e-mail exchange between the following services:

You also can make use of CompuServe's fax gateway. To access any of the services just listed, you must have a CompuServe user ID, and you must register your workgroup with the hub. There is no registration fee.


Here are some examples of how to exchange mail with CompuServe members and Internet users.

To send mail from MHS to a CompuServe user, enter the following line:

MAIL@CSERVE {cis id}

For example: MAIL@CSERVE {555,1212}

To send mail from CompuServe mail to a MHS user, enter the following line:

For more details on using CompuServe's MHS hub, registering your workgroup, and addressing information for other mail services, contact CompuServe Customer Service at 800-848-8990 in North America, or call 614-457-8650 to obtain a number for your country. If you already have a CompuServe user ID, use !GO MHS.


This chapter reviewed Novell's Message-Handling Service (MHS)—what it is, how it works, and how you can take advantage of this services to help your users be more productive. You learned the installation procedures for Basic MHS and Global MHS and examined some MHS-based e-mail and gateway options. Finally, this chapter discussed how you can take advantage of CompuServe's global network and its MHS mail hub to exchange mail with users on other networks.

| Previous Chapter | Next Chapter |

| Table of Contents | Book Home Page | Buy This Book |

| Que Home Page | Digital Bookshelf | Disclaimer |


To order books from QUE, call us at 800-716-0044 or 317-361-5400.

For comments or technical support for our books and software, select Talk to Us.

© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.

netware, novell, network, nos