Copyright
©1996, Que Corporation. All rights reserved. No part of this book
may be used or reproduced in any form or by any means, or stored in a database
or retrieval system without prior written permission of the publisher except
in the case of brief quotations embodied in critical articles and reviews.
Making copies of any part of this book for any purpose other than your
own personal use is a violation of United States copyright laws. For information,
address Que Corporation, 201 West 103rd Street, Indianapolis,
IN 46290 or at support@mcp .com.
Notice: This material is excerpted from Special Edition Using Microsoft Exchange Server, ISBN: 0-7897-0687-3. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
This chapter's primary focus is on migration to Microsoft Exchange from host-based systems, but also includes a brief overview of Migration strategies from SMTP mail and foreign X.400 messaging systems. This chapter covers both the use of Exchange as gateway to these other systems and the process of transferring users to Exchange as the primary messaging system.
This chapter covers the following issues:
Migrating from a Host-Based System to Microsoft Exchange Server
The first messaging systems were proprietary For example, PROFS, was the most popular proprietary messaging system established. There are about 6 million PROFS users today. Proprietary messaging systems like PROFS were designed to provide messaging within organizations rather than between organizations. Also, with the advent of GUI interfaces, client/server architecture, open systems architecture, and the need for inter-LAN messaging, it is likely that first-generation tools like PROFS will be eclipsed by technologies such as Microsoft Exchange.
Quickly review the benefits of Exchange over a legacy host system like PROFS:
In addition to the peceding advantages, new Exchange clients also get to enjoy the advantages of group scheduling, powerful enterprise-wide workgroup applications, and one-stop enterprise-wide administration. In summary, migrating from a host-based system such as IBM PROFS[rt] to Microsoft Exchange offers several significant advantages, including the potential for enormous cost savings, communication between organizations,and freed host resources.
Review the following for migration from host-based systems:
Information that applies to IBM PROFS also applies to IBM OfficeVision/VM.
The following list shows data that you can migrate from IBM PROFS by using Exchange's broad migration features:
When a large organization moves to a new messaging infrastructure, it's a good idea to break down the project into a series of steps. The major steps of migration can be divided as follows:
1. Using the MAPI driver (optional).
2. Create directory and mailbox entries.
3. Extract accounts, Load accounts.
4. Set up connectivity (gateway).
5. Migrate the server contents.
6. Move the user data.
7. Setup directory synchronization.
8. Update the directory.
The following sections cover the main elements of Microsoft Exchange's Migration package. These tools and components to the Exchange system provide an easy and effective way to implement Exchange in your environment. Additionally, the migration tools are used in a similar manner for each e-mail system migrated to Exchange.
The following three tools are included with Exchange to provide an easy way for you to migrate from an existing email system to Exchange. These tools extract the email address information from the legacy system and guide you through the conversion and migration into Exchange.
The Connector is the main link between users of Exchange and external systems, such as SMTP/MIME/Internet connector for UNIX, X.400 connector, and, of course, Microsoft Mail (PC) postoffices.
The Microsoft Exchange gateway for PROFS/OfficeVision provides seamless message transfer with Microsoft Exchange server. The gateway supports all the features of the existing Microsoft gateway for IBM PROFS version 3.4, but with tighter calendar and directory integration. The PROFS/OfficeVision gateway encapsulates Microsoft Exchange messages sent to other Microsoft Exchange users of a PROFS backbone to maintain data integrity.
Directory Exchange Agent
The Directory Exchange Agent (DXA) in Microsoft Exchange enhances directory synchronization with flexible scheduling, better time zone management, and update scheduling. Its multithreaded design improves throughput. Because the DXA includes multiple server support, the directory synchronization load is distributed across multiple "dirsync" servers for increased reliability and faster response. This setup reduces address list maintenance, increases security, and assures that updates occur more promptly. The DXA agent can only function if the proper connectivity exists between the email systems. The DXA operates through the gateway to the legacy email system.
Microsoft Schedule+ Free and Busy Gateway
The Microsoft Schedule+ Free and Busy Gateway allows users who remain on Schedule+ version 1.0 and use MS Mail 3.x servers to see free/busy information in the planner view of users who are on the new release of Schedule+ on the Microsoft Exchange Server computer, and vice-versa. The data from each server platform is replicated across the connector to appear to users on the other platform.
Passthrough Connectivity
Microsoft Exchange Server offers hardy group distribution list support and enables MS Mail users to send messages to X.400 and SMTP environments through the Microsoft Mail Connector. Messages sent from the MS Mail 3.x users through the Microsoft Exchange Server computer can use the Microsoft Exchange X.400 Connector and the Internet Mail Connector to interchange messages with these environments. Alternatively, Microsoft Exchange users can send messages through any Microsoft Mail gateway by using the Microsoft Mail Connector.
Using the Migration Wizard
You can use the Migration Wizard to migrate one or more mailboxes on a Microsoft Mail for PC Networks post office. When each mailbox on the post office is migrated, you have a choice of the information to migrate:
In this sample, a shipping company head-quartered in Los Angeles has branch offices in Dallas and Boston. The headquarters has a mix of IBM PROFS and MS Mail users. Both customer service and accounting departments need constant access to information on the host, communicating by way of the IBM PROFS system. Users in sales, marketing, and both branch offices are all on MS Mail post offices. Both branch offices are connected to the headquarters by T1 lines. PROFS users are linked to Microsoft Mail users through the Microsoft Mail gateway to PROFS (see fig. 8.1).
Fig. 8.1
Exchange has connector support for Profs via the Attachmate Zip office gateways for Exchange.
First, the Microsoft Exchange client is installed on all workstations over time, both at headquarters and in the branches. Microsoft Exchange clients that work with the Microsoft Mail post offices have the rich e-mail functionality in Microsoft Exchange and are still fully compatible with existing Mail clients.
Exchange client talks to the PROFS host via the MS Mail Connector to PROFS.
Microsoft Exchange is then installed on the Windows NT–based server at the headquarters, and both PROFS users and MS Mail post offices are migrated to the Microsoft Exchange Server. This action consolidates the PROFS gateway and two MS Mail post offices on one Microsoft Exchange Server, combining the functions of three machines on one (see fig. 8.2). (The customer also can continue to use the Microsoft Mail–based PROFS gateway.)
Fig. 8.2
Both PROFS users and MS Mail post offices are migrated to the Microsoft Exchange Server.
The automated Migration Tool in Microsoft Exchange works with most common host-based systems as easily as it works with LAN-based systems to automatically extract data and convert it to the Microsoft Exchange system.
The following data is migrated from host-based system to Microsoft Exchange: notes, notelogs, calendars, reminders, and address books (nicknames).
The following data is not migrated: personal address information, preferences and settings, binary file attachments. After all headquarters users are migrated, they have access to the complete functionality of Microsoft Exchange. They also can exchange messages, attachments, OLE objects, and scheduling information with Microsoft Exchange clients who are working against the Microsoft Mail 3.x post offices in the branch offices.
At the headquarters, before the Microsoft Exchange gateway to PROFS was installed, messages were routed to PROFS users from Microsoft Exchange users working against MS Mail post offices through the Microsoft Mail gateway to PROFS. PROFS users also routed their messages back through the Microsoft Mail gateway.
Windows NT–based servers are added to the networks in both branches and Microsoft Exchange is installed on each server (see fig. 8.3).
Fig 8.3
The final configuration.
Now the power of Microsoft Exchange is unleashed across the enterprise. All users have access to rich text formatting of messages and exchanged documents, rules, public folders, forms, group scheduling, remote functionality, and more. Relevant customer service and accounting data from the host can be extracted and put in public folders that are available to all or specified users both at headquarters and at the branches. With immediate access to the same information, users across the enterprise can respond faster to market demands and make better-informed decisions.
In figure 8.4, the message originates from PROFS and is routed by the PROFS gateway directly to the Connector post office in-queue, and routed as are all other messages bound for Microsoft Exchange users.
Fig. 8.4
The message flow from IBM PROFS users to Exchange users.
It's helpful to illustrate the message flow process. When using Microsoft Mail gateways with PROFS, it's a natural development to have Microsoft Mail gateways in coexistence with Exchange Server.
The preceding diagram outlines the flow of a message that originates from PROFS and is routed to the MS Mail user through the Microsoft Exchange gateway to PROFS.
The message is passed through the PROFS gateway to the Microsoft Exchange Information Store. The gateway converts the PROFS message into a standard MAPI message.
When the message arrives in the Information Store, it follows the same message flow as if it originated as a Microsoft Exchange message. Going the other direction, a message from a MS Mail user destined for a PROFS user takes the following route through the Microsoft Mail Connector:
In the reverse situation, a message originates from Microsoft Exchange and is routed through the Microsoft Mail Connector to the MS Mail post office with a PROFS gateway installed.
In this case, the message from the Microsoft Exchange user is stored in the Microsoft Exchange Information Store, and is then sent by the Information Store to the Microsoft Exchange MTA. From there, it's routed by the MS Mail Interchange to the Connector post office. The message then is routed from the Connector post office to its final PROFS destination directly by the Microsoft Mail PROFS gateway.
Going in the other direction, PROFS users who send messages to Microsoft Exchange users use the PROFS gateway in MS Mail.
The message from Microsoft Mail is picked up by the MS Mail Connector (PC) MTA and placed in the Connector post office in-queue. Once there, the message is handled exactly the same as all other messages.
Using a PROFS MAPI client provider for the Microsoft Exchange Client is an alternative to or a variant of multiphased migration. Using Attachmate's ZIP! Office Client Connection product, the Microsoft Exchange Client can be used to connect to the IBM PROFS system, Microsoft Exchange Server, or both systems.
With some programming, you can make a multiphased migration user-managed and user-driven. For example, the mailboxes for all users can be created in Microsoft Exchange server computer, but made hidden. When a user accesses their new mailbox and no longer needs the IBM PROFS system, they can send a special custom form. This form is already addressed to a mailbox. When the message is received, a program creates an account file with the sender's host account information, and then runs the source extractor. After the source extractor is finished, the files are copied to a network share and the Migration Wizard is started in batch mode. It imports the data into the empty mailbox, and logs that this user has been migrated.
The IBM PROFS source extractor is a multithreaded application when migrating messages. It runs in a specially defined MIGRATOR VM ID. Each thread takes the next VM ID from the list of VM IDs to be migrated and attempts to autologon this VM ID. If successful, it invokes the MIGVIZ EXEC from a common mini disk. This EXEC links to the MIGRATOR's 191 mini disk, from which it can access the migration parameters and other migration programs. These programs extract the relevant data from notelogs, files, calendars, nicknames files, and distribution lists and send the data to a file transfer VM ID. When it completes extracting all the data or when the maximum-wait time limit is reached, the thread goes on to the next unmigrated VM ID in the list.
Before installing the software, you need to create two VM IDs MIGRATOR and MIGXFER, as described in the following sections.
A class B VM ID so it can perform the autolog function or a class G VM ID that can perform this function. This ID must have the following:
The following code shows a sample directory entry for the MIGRATOR vmid:
USER MIGRATOR password 4M 8M B
ACCOUNT
IPL CMS
CONSOLE 009 3215
SPOOL 00C 2540 READER *
SPOOL 00D 2540 PUNCH O
SPOOL 00E 1403 A
MDISK 191 3380 ccc 016 vvvvvv MR readpw writepw
LINK xxxDBM 191 395 RR
MIGXFER
This class G VM ID may be used to receive the files generated during migration process from the reader to a minidisk. This VM ID requires a minidisk large enough to store all notelogs, calendar, mailed documents, and nickname information from the group of users participating in the migration run. Optionally, the Administrator may choose to designate the MIGRATOR VM ID to receive these files, rather than creating a second VM ID. The documentation assumes that there are two VM IDs.
The following code shows a sample directory entry for the MIGXFER vmid:
USER MIGXFER password 4M 8M B
ACCOUNT
IPL CMS
CONSOLE 009 3215
SPOOL 00C 2540 READER *
SPOOL 00D 2540 PUNCH O
SPOOL 00E 1403 A
MDISK 191 3380 ccc 100 vvvvvv MR readpw writepw
To install the Microsoft Exchange Server IBM PROFS source extractor with a MS-DOS 3270 Emulator, use the following procedures:
1. Log on as the MIGRATOR VM ID.
2. Insert the floppy disk with the PROFS Source extractor code into the A drive of the computer.
3. From the a:\ prompt, type UPLOAD <path to terminal emulation software> and press ENTER. Do not include a trailing backslash on the path.
4. Move the file MIGVIZ EXEC to a common mini disk.
5. Repeat this process for the file transfer VM ID.
If you don't use terminal-emulation software, the files can be transferred to the MIGRATOR's 191 minidisk with the sample RUNBATCH.EBM macro.
You may need to customize the files, MIGLOGON EXEC and MIGLINKP EXEC to work with your system. Before using MIGLOGON EXEC, you must change the variables, rdpass and vmdir. Before using MIGLINKP, you may need to change the text for sysadmin.
During migration, you need to keep directories in both systems current. You can use the migration tools to export and import directory information, as described in the following sections.
If you don't have a directory synchronization requestor for your host system, then you need to handle the following:
Mail sent in Microsoft Exchange server computers and incoming mail from Microsoft Exchange Server gateways can be routed to the PROFS addresses. You can use this rather than using directory synchronization but you have to repeat the process on a regular basis to update the Microsoft Exchange Server directory with changes in the existing system directory.
Extract a file of IBM PROFS addresses. Move the file to the Microsoft Exchange Server computer. Import the IBM PROFS address file into Microsoft Exchange server with the Migration Wizard to create custom recipients.
The custom recipient information is created with PROFS target addresses. If mail sent from Microsoft Exchange Server mailboxes is routed through X.400 or SMTP to reach the PROFS host, you must modify the custom recipient data before importing it to have the proper address type and address.
1. On the computer where you installed the source extractor, log on as the MIGRATOR VM ID.
2. Type MIGWIZRD and press ENTER to start the source extractor. The screen displays the following code:
Source Extractor for IBM (R) PROFS (R) and OfficeVision (TM)
Microsoft Exchange Server Migration Wizard
The following parameters are specified in MIGPARMS DATA file.
You can change these parameters using this menu, or by using XEDIT.
OV/VM (PROFS) Nickname File: File name: File type:
Accounts File: File name: File type:
PROFS Calendar MIGRATOR vmid (PROFS system only)
Notify VM id : HOWARDS
File Transfer VM id : MIGXFER
Thread timeout (min) : 30
Spool Console required (TRUE/FALSE) : FALSE
Number of migration threads : 05
Replace previously migrated accounts (TRUE/FALSE) : TRUE
-------------------------------------------------------------------
<< BACK NEXT >> FINISH CANCEL HELP
F10/F22 F11/F23 F12/F24 F3/F15 F1/F13
1. (Optional) In the OV/VM (PROFS) Nickname File field, type the name and file type of the nickname file. If this field is not filled in, the source extractor uses OFSUAD FILE, if access to this file is available.
2. (Optional) In the Accounts File field, type the name and file type of the accounts file with a list of VM IDs for which you want to create custom recipients. If you plan to create custom recipients for all VM IDs, skip this step.
3. Anywhere from one to all VM IDs can be specified in an account file. The account file has one VM ID on each line.
4. In the Notify VM ID field, type the VM ID to which alert messages are sent. This VM ID doesn't need to have administrator privileges.
5. In the File Transfer VM ID field, type the VM ID to which all the extractor data should be written.
6. Press the F11 key to continue. The screen displays the following:
7.
Source Extractor for IBM (R) PROFS (R) and OfficeVision (TM)
Microsoft Exchange Server Migration Wizard
What information would you like to migrate?
Type Y to select option, or N to reject it.
Y Remote addresses creation information (REMADDR FILE)
N Mailbox creation information (MAILBOX FILE)
N Email messages (Notelogs and In-basket)
From: 1994/10/28 to 1995/10/28
N Schedule information (Calendars and Reminders)
From: 1995/10/28 to 1996/10/28
N Documents from OFSINDEX FILE
From: 1994/10/28 to 1995/10/28
N Personal Address Book (Nicknames and Distribution lists)
-------------------------------------------------------------------
<< BACK NEXT >> FINISH CANCEL HELP
F10/F22 F11/F23 F12/F24 F3/F15 F1/F13
1. Set the Remote Addresses Creation Information to Y. Set all other options to N.
2. To continue, press the F11 key. The screen displays the remote address file.
3. 10. Edit the remote address file as needed to remove VM IDs for which you don't want Microsoft Exchange Server custom recipients, or to change the display names. The source extractor uses XEDIT as the editor, and all XEDIT commands and subcommands are available.
4. 11. Press F12 to complete the process.
5. This procedure creates REMADDR FILE on the MIGRATOR 191 mini disk and sends REMADDR PRI and REMADDR PKL to the reader of the file transfer VM ID. The REMADDR PRI and REMADDR PKL files are in ASCII format.
To move the REMADDR address to the Microsoft Exchange Server, take these steps:
1. Log on as the MIGXFER VM ID.
2. Type MIGXFER and press ENTER to start the transfer tool.
3. The transfer tool modifies the file named REMADDR FILE to the migration file format and transfers it from the reader to the minidisk. The MIGXFER EXEC also creates MIGXFER BAT, MIGRATOR PKL, and MIGPURGE EXEC on the minidisk.
4. Download the MIGXFER BAT file to the personal computer.
5. From the personal computer type the following:
6. MIGXFER <path to your terminal emulation software>
7. to transfer the REMADDR FILE and packing list file to the personal computer as REMADDR.PRI and MIGRATOR.PKL.
8. On the host, type MIGPURGE to remove the files from the reader.
9. (Optional) Edit the REMADDR PRI file to remove addresses, modify display names, change the target address type, or add additional directory import fields and data. For example, if you want all the custom recipients to have telephone number data, you can add the field, Telephone-Office1, to the end of the first line in the directory section, and then add telephone numbers to the end of each line of data.
The migration files now can be imported into Microsoft Exchange Server with the Migration Wizard. See the following section, "Importing Migration Files," for the next step.
The procedure for creating mailboxes is exactly the same as for creating custom recipients except that, in step 8 of the extracting process, set Mailbox Creation Information to Y. A MAILBOX file is created in place of the REMADDR file.
The process of migrating data creates secondary files, and autologs onto the VM ID that are being migrated. The VM IDs to migrate cannot be in use during the extracting process.
To extract e-mail data, take the following steps:
1. Log on as the MIGRATOR VM ID.
2. Type MIGWIZRD and press ENTER to start the source extractor. The screen displays the following information:
Source Extractor for IBM (R) PROFS (R) and OfficeVision (TM)
Microsoft Exchange Server Migration Wizard
The following parameters are specified in MIGPARMS DATA file.
You can change these parameters using this menu, or by using XEDIT.
OV/VM (PROFS) Nickname File: File name: File type:
Accounts File: File name: File type:
PROFS Calendar MIGRATOR vmid (PROFS system only) :
Notify VM id : HOWARDS
File Transfer VM id : MIGXFER
Thread timeout (min) : 30
Spool Console required (TRUE/FALSE) : FALSE
Number of migration threads : 05
Replace previously migrated accounts (TRUE/FALSE) : TRUE
-------------------------------------------------------------------
<< BACK NEXT >> FINISH CANCEL HELP
F10/F22 F11/F23 F12/F24 F3/F15 F1/F13
1. (Optional) In the OV/VM (PROFS) Nickname File field, type the name and file type of the nickname file. If this field is not filled in, the extractor uses OFSUAD FILE.
If you are migrating only a few accounts, create an accounts or nickname file with these accounts in it and set the appropriate field to point at the file.
1. (Optional) In the Accounts File field, type the name and file type of the accounts file with a list of VM IDs for which you want to create custom recipients.
2. (Optional) If you are migrating calendars from a PROFS system, enter the corresponding VM ID in the PROFS Calendar MIGRATOR VM ID field. Ignore this step if you are migrating calendars from OfficeVision.
3. In the Notify VM ID field, type the VM ID to which error message are sent. This VM ID doesn't need to have administrator privileges.
4. In the File Transfer VM ID field, type the VM ID to which all the extractor data should be written.
5. In the Thread Timeout field, type the maximum number of minutes it should take to migrate each VM ID. When this time runs out, the MIGWIZRD EXEC reuses the thread.
6. In the Spool Console Required field, set the value to TRUE to send console updates to the MIGRATOR VM ID to monitor progress.
7. Alternatively, set the value to FALSE so that the console updates are not sent.
8. In the Number of Migration Threads, set the number of VM IDs that will be migrated simultaneously. If you set this number too high, it can affect performance and resources on the host computer.
9. In the Replace Previously Migrated Accounts field, set the value to TRUE if you want to migrate data for VM IDs that previously were migrated.
10. Alternatively, set the value to FALSE if you do not want to migrate previously migrated VM IDs.
11. Press the F11 key to continue. The screen displays the following information:
12.
Source Extractor for IBM (R) PROFS (R) and OfficeVision (TM)
Microsoft Exchange Server Migration Wizard
What information would you like to migrate?
Type Y to select option, or N to reject it.
N Remote addresses creation information (REMADDR FILE)
N Mailbox creation information (MAILBOX FILE)
Y Email messages (Notelogs and In-basket)
From: 1994/10/28 to 1995/10/28
Y Schedule information (Calendars and Reminders)
From: 1995/10/28 to 1996/10/28
Y Documents from OFSINDEX FILE
From: 1994/10/28 to 1995/10/28
Y Personal Address Book (Nicknames and Distribution lists)
-------------------------------------------------------------------
<< BACK NEXT >> FINISH CANCEL HELP
F10/F22 F11/F23 F12/F24 F3/F15 F1/F13
13. Set the options to Y or N, based on the information you need to migrate. Also, update the date range for each type of information that is being migrated.
The date range doesn't dynamically update. To avoid not migrating recent items, set the To dates to a future date, in case you forget to update them.
14. Press F11 to continue. The screen displays the accounts file.
15. Edit the accounts file as needed to remove VM IDs that you do not want to migrate.
16. The status field can have the following three possible values:
17. Init—Not migrated yet but will be migrated.
18. Timeout—Attempted to migrate VM ID, but reached the timeout limit before migration was finished. Will be migrated.
19. Done—Exported data from this VM ID in the past. Will be migrated only if Replace Previous Migrated Accounts field is set to TRUE.
20. (Optional) If you didn't create a small nickname file or accounts file with your list of VM IDs to be migrated, pare down the full list of users to only the ones you want to migrate.
21. Press F12 to start extracting data. The screen displays the following information:
Source Extractor for IBM (R) PROFS (R) and OfficeVision (TM)
Migrating mailbox information...
Migrating users...
Max_threads=05. Replace=1
N_input=63
AUTO SUFINE EXEC MIGRATE MIGRATOR READ
AUTO STGRAY EXEC MIGRATE MIGRATOR READ
RUNNING MSVM7
22. When the MIGWIZRD EXEC is finished, type SHUT to end the program.
This process creates several items in the reader of the file transfer VM ID, depending on the options selected in the second screen, which are described in the following table:
| Item Name | Description | |
| MAILBOX FILE | Information to create mailboxes | |
| <VM ID> PKL | Packing list for the migration files of the VM ID | |
| <VM ID | PRI Primary intermediate file for the migration files of the VM ID | |
| <VM ID | SEC Secondary intermediate file for the migration files of the VM ID | |
These files are stored in ASCII format and should not be edited. For each VM ID there can be multiple primary intermediate files.
To move the migration files to Microsoft Exchange Server, follow these steps:
1. Log on as the MIGXFER VM ID.
2. Type MIGXFER and press ENTER to start the transfer tool. The screen displays the following information:
Source Extractor for IBM (R) PROFS (R) and OfficeVision (TM)
There are 180 K bytes available on A disk.
Total size of selected files is 1892 K.
Select a subset of files that can be transferred by editing this file.
User ID File Size
00000 * * * Top of File * * *
00001 REMADDR 6080
00002 MAILBOX 4960
00003 EAST03 1328
00004 EAST02 36628
00005 EAST01 10064
00006 CENT01 98776
00007 CENT02 309728
00008 CENT03 282512
00009 CENT05 4344
00010 WEST01 16416
00011 WEST02 22004
00012 CENT04 1044180
-------------------------------------------------------------------
FINISH RECALCULATE CANCEL
F12/F24 F10/F22 F3/F15
====>
1. (Optional) Select a subset of files to transfer by editing this list. If limited by space on the minidisk, press F10 to recalculate the total size of selected files.
2. The transfer tool modifies the files to the migration file format and transfers them from the reader t the minidisk. The MIGXFER EXEC also creates MIGXFER BAT, <VM ID> PKL and MIGPURGE EXEC on the minidisk.
3. Download the MIGXFER BAT file to the personal computer.
4. From the personal computer, type MIGXFER <path to your terminal emulation software> to transfer the migration files to the personal computer as *.PRI, *.SEC and <VMID>.PKL. This step also consolidates all packing list files (PKL's) into one file.
5. On the host, type MIGPURGE to remove the files from the reader.
6. If you want, edit the MAILBOX.PRI file to modify information such as directory names or to add additional directory import fields and data. For example, if you want to migrate department information with each mailbox, you can add the field, Department, to the end of the first line of the directory header, and then add department names to the end of each line of data.
Important: If you need to change directory (common-name) names, do it before importing the migration files. After creating mailboxes, the directory name can be changed only by deleting the mailbox and creating a new one.
Importing Migration Files
The Migration Wizard reads files created by the extractor and automates simple administrative tasks, such as creating mailboxes and custom recipients.
Import the migration files with the Migration Wizard. See Chapter 7, "Migrating to Microsoft Mail Systems," for steps on how to use Migration Wizard.
Migrating from SMTP (Internet) Mail Systems
This section is relevant if your organization currently has a mail system with a proprietary gateway into the Internet or if you use an SMTP POP mail server connected directly to the Internet.
Any reference in this section about connecting to the Internet also applies to connections with other SMTP-based systems.
The Microsoft Exchange Internet Mail Connector provides connectivity with any SMTP-based mail system. In the past, with a PC-based messaging system, it was necessary to connect a separate SMTP gateway PC to access the Internet or other SMTP system. Exchange is designed to talk to the Internet directly and, because of its other connectors and gateways, is well-suited for use as a gateway for other systems.
You will Encounter two types of migration when implementing Exchange in an SMTP (POP mail) environment, which are described in the following list:
You can use Exchange to replace the current SMTP Gateways in your organization. If you currently use the MS-DOS-based SMTP gateway for Microsoft Mail, you want to do this as soon as possible. Exchange provides a far more reliable and efficient method for bridging your organization into SMTP-based systems such as the Internet.
If your organization uses an SMTP Mail (POP) mail servers for user accounts, consider the following points about migration to Exchange.
First, POP mail provides the flexibility to check messages from any point on the Internet with several commonly available mail clients (such as Qualcomm's Eudora, or even with an advanced World Wide Web browser, such as Netscape's Navigator). Although Exchange has excellent remote uses support (for all its functionality, such as public folders and so on), it does currently require that you use the Microsoft Exchange client only to retrieve messages. This section provides some suggestions for migrating users to Exchange and beyond.
Unlike the X.400 connector option of sharing address spaces with a foreign systems, this isn't an option in the SMTP world. Therefore, it's not a practical method for gradual migration from a POP mail to Exchange. If you do happen to have a large number of POP Mail users that you want to migrate to Exchange, the best way probably will be to build all your accounts on parallel system. Then, you have to "throw the switch" and redirect mail to your Exchange server when it's all set up.
For example, for "YOURCORP" organization, the Internet domain is YourCorp.com. We can temporarily set up an offline Exchange server to receive mail at popmail.YourCorp.com for testing. We create all the necessary user accounts on this parallel system, and test for proper routing to this address. Then at a specified time, we modify the entry in the DNS (Domain Name Server) to route all YourCorp.com mail to the machine previously designated as popmail.YourCorp.com.
If you have users that must retain a POP Mail account for some reason (for example, to check mail remotely without an Exchange client), then you can implement the following tricks.
After switching your main organization to Exchange from POP mail, you can concurrently maintain a true POP Mail server to use (popmail.YourCorp.com) for certain user accounts. Then, configure a specific user's mailbox to forward mail to the POP account.
You can accomplish this in the following ways:
Exchange offers excellent support for remote users, so use these methods only when a remote user does not have access to an Exchange client while on the road.
Migrating from Foreign X.400 Messaging Systems
The X.400 Connector for Microsoft Exchange provides all the connectivity needed for replacing a foreign X.400 system in your organization. This connectivity includes gateways for connecting to any system that uses X.400 standards.
As in connecting and migrating form SMTP mail, there two kinds of migration, which are described in the following list:
Sharing Address space with X.400 systems
When switching to Exchange from a foreign X.400 system, user migration will probably be a gradual process. During migration there obviously will be some users on Exchange and others still using the foreign X.400 system simultaneously. Microsoft Exchange allows you to share the X.400 address space with a foreign system to provide coexistence during the migration process.
For example, the Melbourne site is connected to the Los Angeles site through a public X.400 network. Originally, the messaging system in Melbourne was a foreign X.400-based system, but now is being migrated to Exchange. Suppose that 65 percent of the Melbourne users were migrated (using the included migration tools) to Exchange. To maintain coexistence, you set up Exchange to share an address space with the foreign X.400 system (in the Site Addressing property page), which means that messages can arrive for users on both Exchange and the foreign X.400 at the same address.
The following list shows the message route in the preceding example:
1. A message from the public X.400 network enters through the Microsoft Exchange X.400 connector.
2. If the user is an Exchange user (or a user on another system connected to Exchange through another connector), the message is delivered normally.
3. If the user isn't on the Exchange system, it will be routed to your foreign X.400 system and delivered to the user in that mailbox.
With this system, users can be migrated to Exchange at your pace, knowing that both systems will run side-by-side provided that you need them to do so. This approach also reduces the amount of non-deliverable messages often encountered when switching over to a new system.
Another common system migration scenario is to replace your current MS Mail X.400 gateways with a more robust Exchange server with both the X.400 and MS Mail connectors.
In this scenario, Exchange receives incoming X.400 messages thorough the X.400 connector, and routes it through, using the MS Mail connector. Because there will not necessarily be any mail user on the Exchange servers, no user migration is needed.
However, the next step is to migrate the users from MS Mail to Microsoft Exchange, but this topic is covered in its entirety in chapter 6, "Planning Connections to MS-Mail."
From Here...
This chapter has covered migrating from the PROFS, X.400, and Internet based (SMTP) messaging systems. As shown, Exchange can serve as a gateway between itself and your current messaging systems as well as provide a rich set of tools to smoothly migrate your users into Exchange.
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation