A paper presented at the 1997 DECUS Symposium - Gold Coast, QLD
John Marshall
Riverwillow Pty Ltd
[Hyperlinks updated on 22 November 2002]
For many different reasons, corporations with established minicomputer-based messaging platforms are deciding to switch to Microsoft Exchange as their corporate mail platform. The object of this paper is not to examine the reasons or merits of such a move, but rather to examine what some of the issues are which have to be addressed by the IS department when it is faced with the task of implementing the change. Besides the obvious technical challenge of designing and building the new messaging infrastructure, there is the challenge of overcoming the resistance to change, winning employee confidence in the new platform and ensuring that all mail continues to be delivered reliably throughout the transition. These issues are examined in the specific context of a large corporation migrating from DIGITAL's ALL-IN-1 Office Server to Microsoft's Exchange Server.
There are, no doubt, many reasons why you may find yourself in the position of having to migrate your corporation from one mail platform to another. Hopefully the decision is based upon good business reasons, and not merely the notion that it might be a good idea.
The background against which this paper is written is that of migrating a large corporation from DIGITAL's ALL-IN-1 Office Server to Microsoft's Exchange Server. No inference regarding the relative merits of these two mail platforms should be drawn from this example. The same principles would hold true in a corporation migrating from another mail platform to an ALL-IN-1 Office Server environment.
Once the decision has been made, and you have been given the job of implementing it, the reasons become largely irrelevant and your thoughts should focus on how best to manage it.
The first question posed is, Should you cut over to the new platform or gradually migrate your user-base?
The underlying imperative in this exercise must be that your company's business is not disrupted as a result of the implementation. All users of your mail system must continue to receive all their mail, and must be able to send mail to all those to whom they were able to send mail using your former mail system.
Cut-over may be the cheaper alternative, since your administration and support effort would shift from one mail system to another overnight, but can you afford the risk?
Are all your users trained? Are they all confident that the new mail platform will meet all their messaging needs? Is the mail client installed and configured on everybody's P.C.? Does everybody have a P.C.? Will all your out-of-office users have access to a properly configured mail client and your network when they need to send and receive mail? Are you sure you know what everybody does with your existing mail system? Are you sure that any existing mail and fax gateways work properly with the new platform, and that your users know how to access them? Will mail from external sources still reach your users with the same mail address? Are you sure that none of your users will have need to make use of mail stored on the old server?
If you can confidently answer all questions in the preceding paragraph in the affirmative, you are ready to adopt a cut over strategy.
Now that you have decided to adopt a migration strategy, we shall examine some of the issues involved.
Before starting to move users to Exchange, it is assumed that your NT/Exchange infrastructure is in place and tested; and that your support staff is trained in the use, administration and support of Exchange and your migration process. It is also assumed that you will have decided upon, and implemented, the means of communication between the two mail platforms.
Running both mail systems in parallel provides some important benefits:
In order to run both mail systems in parallel successfully, some careful thought needs to be given to mail directories and distribution lists.
Unless your company uses a directory service which is accessible by both mail systems, mail directories on both platforms will need to reflect the same user population, and will need to be synchronized with any changes to either system.
All your staff must be addressable from both mail systems. You will probably want to create mailboxes on your Exchange server for all your ALL-IN-1 users and initially set forwarding addresses which point back to their ALL-IN-1 accounts. This way, everybody's name will appear in the Exchange Global Address List. The fact that particular users are actually ALL-IN-1 users is transparent to the Exchange user who is addressing the message. As users migrate to Exchange, the forwarding address is removed from their Exchange mailbox, and an auto forward address is set on their ALL-IN-1 account to redirect their mail to Exchange.
When users have migrated to Exchange and their ALL-IN-1 accounts are deleted, entries should be made in the ALL-IN-1 mail directory so that those users are still addressable from within ALL-IN-1. This may be the ALL-IN-1 Network Profile file (OA$DATA:NETWORK.DAT), DDS, or X.500. The ALL-IN-1 Directory entries for these users would, of course, display their Exchange mail address. It is also important, during the transition period, to remember to add entries to the ALL-IN-1 Directory for new Exchange users (who have never had ALL-IN-1 accounts.
Even if the user's ALL-IN-1 account is to be retained for some time following migration, the mail directory should still be updated to reflect the fact that the user's primary mail address is no longer ALL-IN-1. The ALL-IN-1 profile field MNODE should be set to "N", any ALL-IN-1 Directory entry containing the user's ALL-IN-1 address should be deleted, and a new ALL-IN-1 Directory entry reflecting the user's Exchange mail address should be created.
As will be seen subsequently, there are a number of updates, besides the mail directory, which must occur for each user who migrates to Exchange. The best way to avoid upsets, save time, and ensure that nothing is missed, is to automate the migration process. An ALL-IN-1 script which takes ALL-IN-1 and NT usernames as parameters via an entry form, was used in this case. This method also allows bulk migration by taking input from a data file. System administrators need only to clear the forwarding address on the user's Exchange server, enter both usernames into the migration form on the user's ALL-IN-1 system, and the migration process is complete.
In order for system distribution lists to be effective, they must be kept up to date on both platforms. This is of particular concern on the ALL-IN-1 servers where the users' mail address changes upon migration. Nothing will break as long as the user's ALL-IN-1 account remains (forwarding to Exchange), but by the time the user's ALL-IN-1 account is deleted, the distribution lists must direct mail to the user's Exchange mailbox. This can be achieved by means of an automated process which rebuilds your ALL-IN-1 system distribution lists on a regular basis, extracting the users' mail addresses from the ALL-IN-1 Directory file.
If you have users with "captive" ALL-IN-1 accounts, you may have set their VMSmail profile to forward mail to their ALL-IN-1 account. If their ALL-IN-1 profile is deleted at some stage during the migration process, mail sent to their VMSmail address won't reach them. Users' VMSmail profiles need to be set to forward mail to their Exchange mailboxes as part of the migration process.
The ALL-IN-1 pseudo distribution list "SUBSCRIBERS:" is intended as a mechanism for sending mail to "All ALL-IN-1 subscribers on this node". Companies which use ALL-IN-1 as their corporate mail platform tend to equate the SUBSCRIBERS: address with "All electronic mail addresses in my company". Users who have migrated to Exchange will no longer be reached by addressing ALL-IN-1 mail to SUBSCRIBERS:. A separate distribution list should be set up on the ALL-IN-1 server(s) which captures all your staff. Such a list could include SUBSCRIBERS: (to catch all the ALL-IN-1 users) and an entry for each user who has migrated to Exchange (specifying their Exchange mail address). This list would obviously need to be maintained in an automated fashion like other system distribution lists.
Once users think that all their mail is being delivered to Exchange, finding new mail sitting in their ALL-IN-1 account can damage their confidence in the migration process. For this reason delivery of SUBSCRIBERS: mail should be disabled to ALL-IN-1 accounts of users who have migrated. This can be achieved by setting the RCV$SUB field in the user's ALL-IN-1 profile to "N".
If one of your short-term goals is to retire your ALL-IN-1 servers, then you will need to provide tools for your users to be able to move mail and documents from their ALL-IN-1 accounts to the Exchange environment. Apart from reference purposes, there is the need to reply to, or forward, messages which have been received recently. If you don't need to retire your ALL-IN-1 servers, you may consider the alternative of providing users with access to their ALL-IN-1 File Cabinets from their P.C. Mail Client.
Your users are the ones who must decide what messages and documents they wish to move to the new platform. If they can't be bothered sorting through what they have, or if they are convinced that they can't possibly live without the lot, they are going to cause you grief and pain with respect to disk space in the Exchange environment.
Beware of rapid consumption of disk space! Consider the example of an ALL-IN-1 user who may have plenty of room to spare in the 10,000 block (5MB) quota allowed him for his ALL-IN-1 file cabinet. The same user's file cabinet may be referencing anything from 100,000 blocks (50MB) to 400,000 blocks (200MB) of mail messages stored in ALL-IN-1's shared mail areas.
Mailboxes on an Exchange server are stored in a database. The database has an architectural limit of 16GB. If 320 ALL-IN-1 users are each allowed to copy 50MB worth of mail messages and documents to their Exchange mailboxes, the Exchange server database will be full and will be rendered useless. If 640 ALL-IN-1 users are each allowed to copy 25MB worth of data, you have the same problem. For this reason it is vital that your training emphasizes the use of Personal Folder Files (PST's) which can be created on a file server or the user's P.C. These files provide Exchange client accessible storage outside the constraints of the Exchange Server database.
This tool, produced by I/G OpenWare, Inc. is a special purpose tool designed to migrate documents, mail messages and distribution lists from DIGITAL ALL-IN-1 or MailWorks Servers to Microsoft Exchange. The tool prompts for logon information to allow it to connect to both servers. It then presents the user with a hierarchical folder representation of the ALL-IN-1 File Cabinet and the Exchange mailbox, and allows the user to select documents, folders, drawers, or the entire file cabinet for migration to Exchange. The user is able to specify preferences for many things including document conversion. A Lotus ScreenCam Demonstration of the product is available from the company's web site at http://www.openone.com/software/Direct-TO-1/.
This driver is a DIGITAL product which enables Exchange clients (Outlook, Exchange, Windows Messaging) to access DIGITAL Office Servers. The DIGITAL Office Server service is added to the user's Exchange profile and the file cabinet appears as another mailbox on the client. The user is able to access mail on both the ALL-IN-1 and Exchange servers from the same client. Further details can be found on the DIGITAL web server at http://www.compaq.com/info/SP6143/SP6143PF.PDF.
Version 3.0 of the product is a 16-bit client and provides MAPI functionality for access to DIGITAL Office Servers and Microsoft Exchange Servers.
John Marshall
After nine years' experience in the Avionics and Electronics industries, the latter five of which included management and programming of real-time computer systems, John Marshall took up the position of Systems Manager with the New South Wales Fire Brigades, where he was responsible for the management, operation and programming of their VMS systems and networks. After 13 years with the New South Wales Fire Brigades, John launched out into the wide world of VMS consulting, where he has been for the past two years. Part of his brief in his most recent consulting assignment has been to migrate some 2,000 users from ALL-IN-1 servers to Exchange.