Migrating to GroupWise from Message Handling Services
Articles and Tips: article
Product Manager
GroupWise Division
01 Jun 1997
For those who still have old MHS-based e-mail systems in place, there's never been a better time to switch to GroupWise. This AppNote tells you the whys and hows of taking the GroupWise plunge.
- Introduction
- A Quick Review of MHS
- GroupWise Improvements over MHS
- Steps for Migrating to GroupWise
- Migrate the Message Database
- Conclusion
Introduction
Message Handling Services (MHS) is a basic message engine that is available free with NetWare 4.x. It is a store-and-forward platform on which runs any MHS application that supports Standard Message Format version 71 (SMF-71). Shipping with NetWare, it is the preferred messaging platform on which many third-party applications run.
With the advent of IntranetWare, GroupWise has improved significantly on the features offered by MHS. System Administrators contemplating migrating to IntranetWare would do well to consider the benefits of also migrating to GroupWise. For example, GroupWise improves upon many of MHS's transport features. GroupWise can process 70 messages per second; MHS can handle about one message per second. GroupWise runs on multiple operating systems, including NetWare, Microsoft NT, and UNIX; MHS is limited the NetWare platform. The benefits in migrating MHS to GroupWise are substantial.
This AppNote details the steps involved in migrating to GroupWise from MHS. In doing so, these four aspects of migration will be considered:
The different MHS products, their functions, and their appeal to users
What enhancements are needed for MHS to function as a full-featured transport mechanism in an intranet environment
Description of those enhancements which already exist in GroupWise
Steps for migrating from MHS to GroupWise
The following tools are available to help in migration to GroupWise:
GroupWise MHS Gateway
GroupWise MHS Services Adapter
GroupWise MHS Conversion Utility
GroupWise API Gateway
A Quick Review of MHS
Description of MHS Products
Over the years, Novell has designed several MHS products with the end in mind of making MHS a better transport platform for Novell and third-party messaging applications. Such network e-mail packages as DaVinci Mail, for instance, work exclusively on the MHS platform. Exclusively Novell products for MHS range from the basic MHS engine that ships with all NetWare 4.x packages to various protocol modules used to link MHS to external messaging systems.
Global MHS 2.x. Global MHS (GMHS) is Novell's primary MHS engine. Running as an NetWare Loadable Module (NLM), it is supported on NetWare 3.x and NetWare 4.10. GMHS is not supported on NetWare 4.11, and it does not use Novell Directory Services (NDS). It supports SMF-70, and SMF-71 applications, and has directory synchronization.
MHS 1.5. All versions of this product (N ,M, and P) form a basic DOS-based MHS engine that supports applications that use SMF-64 and SMF-70; however, it does not SMF-71. Because it is based on DOS and has a simple file access, it will run on many networks.
Remote MHS. Remote MHS is a standalone MHS system designed to run on a laptop or personal computer for retrieval of mail over a modem from a network. Remote MHS retrieves mail redirected from MHS 1.5 or Global MHS and supports modem connections up to 14,000.
Protocol Modules. Protocol Modules link GMHS to external messaging system, such as:
SMTP
X.400
SNADS
Notes
What Makes MHS Attractive
There are two main reasons why MHS has become so popular over the years among developers and users.
MHS is an open transport system. Because MHS is an open transport system, built on a simple open file base API (SMF-64, SMF-70, and SMF-71), MHS was attractive to developers who could easily write applications to run on MHS. Many mail clients and gateways were created over the years for MHS.
MHS is NetWare-centric. Because MHS was designed to be NetWare-centric, many MHS engines were built around NetWare, and were often sold by Novell. NetWare customers could be assured that an application running on MHS would operate flawlessly with the rest of NetWare.
MHS Deficiencies
The features in the various MHS products are wonderful as far as they go. But as system administrators consider migrating from internets to intranets, the limits of MHS become readily apparent. For MHS to be a truly effective message transport system for today's networks, it would have to be significantly enhanced. As it is, MHS has several significant deficiencies that prevent it from being the full-featured product it could be.
Weak Transport Engine. First of all, MHS would need a stronger transport engine. With a local area network enclosed in one building, GMHS' ability to handle about 1 message per second is no longer robust enough. Not only that, but GMHS' directory table has only been proven to support 10,000 to 20,000 users.
In today's messaging environment where millions of messages needed to be processed between thousands of users, Global MHS could not keep up with the workload.
Not Multi-Network. Many, if not most, of today's network span several platforms, including NetWare, Microsoft NT, and UNIX. GMHS, and MHS Services only support NetWare, and do not scale to other environments. Just to become a viable player in the intranet, MHS would have to be ported to other network platforms.
No Security. SMF is a simple file-based messaging format without any built-in security. SMF messages are open to "traps" where unauthorized individuals could read messages as they were transmitted. It practically goes without saying that such lax security features are unacceptable in today's Internet world.
Poor Administration. G MHS uses a distributed administration model. This model requires that administration tasks be performed at the physical location of the users accounts, and on the NetWare console screen. It doesn't take much imagination for the experienced system administrator to see how impractical this administration paradigm is in a business environment where hundreds and thousands of user are communicating over networks in various part of the world.
MHS has rather primitive user management features, even by LAN standards. For instance, such basic features such as "Move User", or "Rename User" are not included in the MHS administration module.
Cumbersome Remote Solution. Because MHS simply re-directs messages to a remote station, its remote messaging solution is rather weak, resulting in users having to manage multiple message databases or one remote message database, and one network message database. Each of these databases would have different mail massages depending on how they were picked up. Because of this users were either in full time remote mode, or did not user remote at all.
No Message Transport Control Over Message Store. MHS a simple transport, so there are no provisions for handling the message store. Because of this there were incompatibilities between different applications at the message store level. Also, the messaging application, not MHS, was responsible for handling all incoming mail, and processing any rules. This would sometimes delay the messaging application.
No Integration of Group Activities. Though an effective platform exists with MHS for delivering calendaring, scheduling, and workflow services, the services themselves are provided solely by third-party developers. This oversight, and the fact that MHS is so open, leads to applications of disparate quality with regards to user interface.
GroupWise Improvements over MHS
GroupWise is such an enhancement over MHS that it offers a practically irresistible migration path from NetWare to IntranetWare. GroupWise enhancements as a message engine are significant and cover the gamut from improvements in message transport features to increased migration and link tools.
Transport Improvements
GroupWise provides many transport improvements over MHS. It can:
process 70 messages per second.
run on multiple operating systems, including NetWare, Microsoft NT, and UNIX.
transport mail over IPX, and IP natively.
transport securely with built-in encryption.
Communication Improvements
The GroupWise system also provides more communication tools than MHS:
Stronger Async Support, supporting high speed modems
Communication Links to SMTP, x.400, Profs/Snads, CC:Mail, MS Mail, Lotus Notes
Additional Communication Tools include the Fax Gateway, Pager Gateway
Telephone Access Server
Administration Improvements
GroupWise also has better administration tools which allow central and distributed administration. Administration tasks can be completed at remote locations or from a central office. By supporting NDS, administrator's can enjoy a significant time savings. All GroupWise administration is through Novell's NWAdmin Interface.
Remote Improvements
GroupWise provides better remote solutions then MHS by enabling users to:
Manage one message store, and GroupWise will synchronize between a remote message store, and the network message store
Connect to GroupWise through many different modems at high speeds
Use the network to update a remote message store.
Client Improvements
The GroupWise client not only handles standard e-mail, but the client also goes beyond what is available to MHS applications by supporting:
Personal and Group Calendar/Scheduling
Task Management
Shared Folders
Document Management
Rich Text
Workflow
Imaging
Web Pages
All these types are presented in an easy to manage "Universal In-box."
Supports Popular MHS Features
GroupWise hasn't totally abandoned MHS. In fact, it supports the features that made MHS popular.
Open Messaging Structure As an Open messaging transport, GroupWise supports:
MAPI (Client base messaging API)
POP3, and IMAP4 (Internet client based messaging APIs)
CMC/CSA (Server based messaging API)
GWAPI, and C3PO (GroupWise specific client based messaging API)
GroupWise API Gateway (File based messaging server API)
NetWare-Centric As Novell's messaging platform, GroupWise will run on NetWare 3.x, and NetWare 4.x. GroupWise is fully integrated with NDS, and Novell's NWAdmin.
Third-Party Support With the popularity of GroupWise growing, many third party companies have begun to support GroupWise to provide additional services.
Migration/Link Tools These tools are needed during the migration process to GroupWise:
GroupWise MHS Gateway -The GroupWise MHS Gateway is a link between GroupWise and legacy MHS systems. It is designed to work with MHS 1.5, and Global MHS. The GroupWise MHS Gateway will also share directory information between GroupWise and Global MHS. (MHS 1.5 does not support directory synchronization.) The GroupWise MHS Gateway ships for FREE on the GroupWise CD.
GroupWise MHS Services Adapter - The GroupWise MHS Services Adapter is a link between GroupWise and MHS Services for NetWare 4. This adapter is designed to share directory information between MHS and GroupWise. It provides ongoing support for SMF applications in GroupWise.
The following tools are used during the migration process to GroupWise:
MHS Message Conversion Utility (MHSMCU) - The MHSMCU is used to convert message stores (mail) from MHS applications into GroupWise. The MHSMCU will work with Beyond Mail, DaVinci Mail v.2.5, First Mail, Pegasus, and other MHS applications that store mail is SMF format.
|
Note: The MHSMCU is available for FREE as a downloadable file from http:www/novell.com. |
GroupWise API Gateway - The GroupWise API Gateway is used with the MHSMCU to convert MHS message stores into GroupWise. The GroupWise API Gateway can also be used with in-house applications to submit and read e-mail. (Convert in-house SMF applications to GroupWise.)
|
Note: The GroupWise MHS Gateway is available for FREE as a downloadable filefrom http://www.novell.com. |
Steps for Migrating to GroupWise
Consider User Requirements
Before any migration should occur, the needs of the users should be first in mind. Here is just a sample of common requirements that users may insist upon during the migration.
One Day Migration The users may insist that the migration take place during the night. This way, the users do not experience any time in which they can access their mail.
No Loss of New Mail During Migration Users usually expect that they get all mail that is sent to them between the last time they checked e-mail, and the time that they begin using GroupWise. Care should be taken to ensure that messages are redirected at the correct time.
Access to previous stored mail - Users may, or may not, require that old messages that are stored are migrated to GroupWise. If mail is to be moved, a process should be in place to migrate mail.
No message flow downtime - If the migration takes place over several days or weeks, other users, who are not migrating at that time, expect mail to continue to flow. The existing structure should be maintained during the migration.
Limited client downtime - After the migration, users would expect that they can run the GroupWise client application without delay. Support should be in place to help users after the migration.
Other Requirements - There may be other requirements that need to be addressed. Make sure that the users are aware of the migration before hand, and that they have had an opportunity to raise any concerns.
Build GroupWise Structure
After you've determined the user requirements as described above, you're ready to begin the migration process. The first step in that process is to make all necessary changes to the GroupWise server (see Figure 1):
Set up Primary Domain - The Primary domain will need to be setup before any migration can occur.
Set up Secondary Domains and Post Offices as needed - Although the entire GroupWise structure does not need to be built prior to migrating users, Secondary Domain,and Post Offices that will be used during the migration should be in place.
Set up Client Software - Finally the client software should be installed, set up and tested.
Figure 1: The first step in migrating MHS to GroupWise is to build the GroupWise structure.
Link MHS and GroupWise
Depending on which version of MHS you're using, make the following changes:
On Global MHS, define GroupWise Gateway -Using NGMADMIN, define a SMF gateway on the NGM server that will be linked to GroupWise.
Note: Optionally,you can define a Messaging Server for GroupWise: using NGMADMIN,under Local Domain/Messaging Servers, define a Messaging Server for GroupWise, and using a Generic Link link it to the GroupWise Gateway.
On MHS 1.5 , define GroupWise Gateway -Define a SMF gateway on the MHS host that will be linked to GroupWise.
On MHS Services for NetWare 4 - Install the GroupWise MHS Services Adapter. Run the PINSTALL.NLM for the GWMSA. This will automatically set up the link in MHS Services.
On GroupWise (For Global MHS, and MHS 1.5)- Run the GroupWise MHS Gateway install program. Add and setup the GroupWise Gateway to the GroupWise Domain that will link to MHS.
(For MHS Services) - Add and set up the GroupWise MHS Services Adapter to the GroupWise domain that will link to MHS.
Install the API Gateway
On GroupWise - Run the install program for the API Gateway. Add and setup the API Gateway on the domain that will be used for the migration (Figure 2).
Figure 2: Installing the API Gateway.
Migrate the MHS User Directory Information
By migrating the MHS directory information into GroupWise, user information need not be retyped when creating the GroupWise users. MHS User information can be migrated using the GroupWise MHS Gateway, the GroupWise MHS Services Adapter, or the GroupWise API Gateway. These three methods of directory migration will result in a GroupWise Foreign Domain and Foreign Post Offices, with MHS users registered as users on the Foreign Post Office (see Figure 3).
GroupWise MHS Gateway - The GroupWise MHS Gateway can only be used with Global MHS for Directory migration. This is done by turning on directory synchronization in Global MHS to the Gateway, and by turning on directory synchronization in GroupWise for the Gateway.
The GroupWise MHS Services Adapter - The GroupWise MHS Services Adapter is used for directory synchronization with MHS Services. All that is needed is to turn on directory synchronization in GroupWise for the GroupWise MHS Services Adapter.
The API Gateway - The API Gateway can also be used to migrate directory information. The API Gateway is more flexible, but does require more work. A file with directory information will need to be built, and placed in the API gateway directory. The API gateway will take the information and import it into GroupWise. Here are the steps:
Create a foreign domain called MHS, and several post offices on that domain.
Link the MHS domain through the GroupWise MHS Gateway.
Place the file in the API Structure.
Figure 3: Migrating the MHS directory information.
Migrate Users to GroupWise
On GroupWise, add users. There are three ways to add the GroupWise accounts in GroupWise:
Move Method (for GroupWise 4.1 only) - Using the GroupWise Admin, Highlight the user to be added to GroupWise Edit the properties for the users. Change the postoffice from the MHS foreign post office to the destination GroupWise post office. This will "Add" the user on the GroupWise postoffice and domain.
API Method (for GroupWise 4.1) - Use the API gateway to create user account Create a GroupWise API file with instructions to add the specific users to a GroupWise Post Office. Place the file in the GroupWise API directory structure.
Import Method - Create a file that contains the user information about the users to be added in GroupWise. This file should be formatted according to the GroupWise import format. Using GroupWise import, import the file to create GroupWise users
|
Note: With GroupWise 5, the import will also create NDS accounts for these users. |
On MHS, reroute user mail. On the server where the MHS users exists, delete the MHS user account using NGWADMIN. Add users to the GroupWise gateway, or to a server connected through the gateway.
|
Note: Use DIRADM to add many users. |
|
Caution: Be careful to only delete the account information in MHS. Make sure thatthe e-mail application using MHS will not delete the message store if the account ismissing from MHS. If the e-mail application will delete the store, migrate the messagestore before rerouting mail. |
Figure 4: Migrating users to GroupWise.
Migrate the Message Database
Use MHS Mail Conversion Utility (MHSMCU) to submit mail to the API Gateway, and to the GroupWise user account. MHSMCU will convert mail on a single user base. It can be used in a batch file to migrate the message databases for a large number of users. MHSMCU is used to convert message stores from MHS applications into GroupWise (see Figure 5). The MHSMCU will work with Beyond Mail, Da-Vinci Mail v.2.5, First Mail, Pegasus, and other MHS applications that store mail is SMF format.
Figure 5: Migrating the message database.
Migrate In-House Applications
In-house applications that were written to work with MHS by using SMF as a file base API can be easily reconfigured to use the file base API of the API Gateway (see Figure 6).
Figure 6: Migrating in-house applications.
Remove MHS Structure
Once the migration to GroupWise is complete, MHS 1.5 and Global MHS can simply be unloaded (see Figure 7). In most cases there will not need to be any directory cleanup on Global MHS. Once MHS is unloaded and message databases are migrated, the MHS directory structure can be cleaned up. Since MHS Services is registered in NDS, MHS Services servers will need to be unloaded, and ten deleted from NDS through NWAdmin. Once this is complete, the MHS directory structure can also be cleaned up.
Figure 7: Removing MHS structure.
Conclusion
MHS is a good, open transport, excellent for users of NetWare 4.x. However, for administrators wanting to upgrade to IntranetWare, MHS falls short of providing basic intranet message services. For this reason, it behooves those who want to take full advantage of what IntranetWare has to offer to migrate from MHS to GroupWise. GroupWise is the ideal upgrade, yet maintains openness and backward compatibility with MHS.
* 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.