The first messaging systems were proprietary. For example, PROFS was the most popular proprietary messaging system established. There are about six million PROFS users today. Proprietary messaging systems like PROFS were designed to provide messaging within organizations rather than between organizations. Today, with the advent of GUI interfaces, client/server architecture, open systems architecture, and the need for inter-LAN messaging, first-generation tools like PROFS are likely to be eclipsed by technologies such as Microsoft Exchange.
Here's a quick review of the benefits of Exchange over a legacy host system like PROFS:
In addition to the preceding advantages, new Exchange clients also 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 to Microsoft Exchange offers several significant advantages, including the potential for enormous cost savings, communication between organizations, and freed host resources.
This chapter reviews the following for migration from host-based systems:
NOTE: 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:
The following sections cover the main elements of Microsoft Exchange's Migration utilities. These tools and components of the Exchange system provide an easy and effective way to implement the system 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 e-mail system to Exchange. These tools extract the e-mail address information from the legacy system and guide you through the conversion and migration into Exchange.
Connectors are the main link between users of Exchange and external systems. The Enterprise Edition of Exchange 5.5 includes two new connectors: the Connector for IBM OfficeVision/VM and the Connector for SNADS. These connectors provide coexistence for both messages and directories between Exchange and host systems.
Both connectors require the Microsoft SNA Server for host connectivity, though they do not require installation of any code on the host. Each also includes the optional ability to prevent attachments from being sent to the host mail system from Exchange. Either connector, when connected to an Exchange system that also houses an Internet Mail Service, can provide host users with access to Internet e-mail.
NOTE: At the time of this writing, the author team had the most current release of the Exchange 5.5 Release Candidate 1. Unfortunately, the PROFS and SNADS Connectors were not included in that version. Check the Que Web site for more complete information on these connectors. You will find this and other updates at www.mcp.com.
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 function only if the proper connectivity exists between the e-mail systems. The DXA operates through the gateway to the legacy e-mail system.
Microsoft Schedule+ Free and Busy Gateway Free and busy times are the times when people are available and unavailable, respectively. The connector processes users' free and busy information from Microsoft Mail PC Post Offices and updates the information in Schedule+ Free and Busy system folders. It then sends updates on free and busy information from Microsoft Exchange for Microsoft Mail PC Post Offices.
Schedule+ 7.0 can access information from Schedule+ 1.0 users and access details about other Schedule+ 7.0 users. With the two together, Schedule+ 1 and Schedule+ 7 can do the following:
However, because the file formats of Schedule+ 1.0 and Schedule+ 7.0 differ, Schedule+ 1.0 users cannot access the detailed information of Schedule+ 7.0 users.
The Microsoft Exchange gateway for PROFS/OfficeVision does not currently support integration with Outlook. However, future versions of the gateway may offer this functionality.
Microsoft Exchange Server offers hardy group distribution list support and enables Microsoft Mail Post Office users to send messages to X.400 and SMTP environments through the Microsoft Mail Connector. Messages sent from the Microsoft Mail Post Office 3.x users through the Microsoft Exchange Server computer can use the Microsoft Exchange X.400 Connector and the Internet Mail Service to interchange messages with these environments. Alternatively, Microsoft Exchange users can send messages through any Microsoft Mail gateway by using the Microsoft Mail Connector.
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. For more information on the Migration Wizard, see Chapter 8, "Migrating from Microsoft Mail Systems," and Chapter 10, "NetWare Considerations/Migrating from GroupWise."
Software Spectrum is headquartered in Garland, Texas, and has branch offices in London and Los Angeles. The headquarters has a mix of IBM PROFS and Microsoft Mail Post Office 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 consulting offices are all on Microsoft Mail post offices. Both consulting 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 Figure 11.1). Migration will occur in three phases, as described in the following sections.
FIG. 11.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 text e-mail functionality in Microsoft Exchange and are still fully compatible with existing Mail clients.
Exchange clients talk to the PROFS host through the Microsoft Mail Post Office Connector to PROFS.
Microsoft Exchange is then installed on the Windows NT-based server at the headquarters, and both PROFS users and Microsoft Mail post offices are migrated to the Microsoft Exchange Server. This action consolidates the PROFS gateway and two Microsoft Mail post offices on one Microsoft Exchange Server, combining the functions of three machines on one (see Figure 11.2). (The customer also can continue to use the Microsoft Mail-based PROFS gateway.)
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 a host-based system to Microsoft Exchange: notes, notelogs, calendars, reminders, and address books (nicknames).
FIG. 11.2 Both PROFS users and Microsoft Mail post offices are migrated to the Microsoft Exchange Server.
The following data is not migrated: personal address information, preferences and settings, and 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 Microsoft 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 Figure 11.3).
FIG. 11.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 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 regional offices. With immediate access to the same information, users across the enterprise can respond faster to market demands and make better-informed decisions.
In Figure 11.4, the message originates from PROFS and is routed by the PROFS gateway directly to the Connector post office in-queue, as are all other messages bound for Microsoft 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 coexist with Exchange Server.
Figure 11.4 outlines the flow of a message that originates from PROFS and is routed to the Microsoft 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 Microsoft Mail Post Office user destined for a PROFS user takes routes through the Microsoft Mail Connector as described in the following section.
FIG. 11.4 The message flow from IBM PROFS users to Exchange users.
In the reverse situation, a message originates from Microsoft Exchange and is routed through the Microsoft Mail Connector to the Microsoft 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 Microsoft 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.
The message from Microsoft Mail is picked up by the Microsoft 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.
Going in the other direction, PROFS users who send messages to Microsoft Exchange users use the PROFS gateway in Microsoft Mail Post Office.
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 a Microsoft Exchange Server computer, but made hidden. When a user accesses his or her new mailbox and no longer needs the IBM PROFS system, he or she 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 autolog on this VM ID. If successful, it invokes the MIGVIZ EXEC from a common minidisk. This EXEC links to the MIGRATOR's 191 minidisk, from which it can access the migration parameters and other migration programs. These programs extract the relevant data from notelogs, files, calendars, nickname 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. Create either a class B VM ID that 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 VM ID:
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 the migration process from the reader to a minidisk. This VM ID requires a minidisk large enough to store all notelog, 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 VM ID:
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 an MS-DOS 3270 Emulator, use the following procedures:
In addition to using a MS-DOS 3270 Emulator, you can install the Exchange Server IBM PROFS Source Extractor with a Windows 3270 Emulator. 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.
Customizing EXECs After Installation 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.
Maintaining Directories During a Multiphase 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.
Creating the REMADDR File To create custom recipients, 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. To do this, complete the following steps:
NOTE: 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.
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
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
Moving the REMADDR Address to the Microsoft Exchange Server To move the REMADDR address to the Microsoft Exchange Server, take these steps:
MIGXFER <path to your terminal emulation software>
The migration files now can be imported into Microsoft Exchange Server with the Migration Wizard. See the section, "Importing Migration Files," later in the chapter 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.
Migrating Data The process of migrating data creates secondary files, and autologs onto the VM IDs that are being migrated. The VM IDs to migrate cannot be in use during the extracting process.
Extracting E-Mail Data To extract e-mail data, take the following steps:
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
TIP: 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.
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
CAUTION: The date range doesn't update dynamically. To avoid not migrating recent items, set the To dates to a future date, in case you forget to update them.
Init--Not migrated yet but will be migrated.
Timeout--Attempted to migrate VM ID, but reached the timeout limit before migration was finished. Will be migrated.
Done--Exported data from this VM ID in the past. Will be migrated only if Replace Previous Migrated Accounts field is set to TRUE.
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
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.
Migrating Files to Microsoft Exchange Server To move the migration files to Microsoft Exchange Server, follow these steps:
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 ====>
NOTE: Important: If you need to change directory (common-name) names, do it before importing the migration files. After you create mailboxes, the only way to change the directory name is to delete the mailbox and create a new one.
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, "Planning Connections to Microsoft Mail Systems," for steps on how to use the Migration Wizard.
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.
NOTE: Any reference in this section about connecting to the Internet also applies to connections with other SMTP-based systems.
The Microsoft Exchange Internet Mail Service 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:
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 to SMTP-based systems such as the Internet.
If your organization uses 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). In Exchange 5.0 Microsoft added a POP client giving it the same flexibility as all the other clients. This section provides some suggestions for migrating users to Exchange and beyond.
The X.400 Connector option of sharing address spaces with a foreign system isn't an option in the SMTP world. Therefore, it's not a practical method for gradual migration from 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 systems. Then you have to "throw the switch" and redirect mail to your Exchange server when it's all set up.
For example, for Software Spectrum, the Internet domain isswspectrum.com, we can temporarily set up an offline Exchange server to receive mail at popmail.swspectrum.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 allswspectrum.com mail to the machine previously designated as popmail. swspectrum.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 create two profiles on their client: one pointed at their Exchange server and the other pointed at the old server, thus giving them access to both areas.
Exchange offers excellent support for remote users, so use this method when a remote user does not have access to an Exchange client while on the road.
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 from SMTP mail, there are two kinds of migration:
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.
In the previous example, the Sydney site is connected to the Los Angeles site through a public X.400 network. Originally, the messaging system in Sydney was a foreign X.400-based system, but it is now being migrated to Exchange. Suppose that 65% of the Sydney 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 properties 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:
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 Microsoft Mail X.400 gateways with a more robust Exchange server with both the X.400 and Microsoft Mail connectors.
In this scenario, Exchange receives incoming X.400 messages through the X.400 connector, and routes them through, using the Microsoft Mail connector. Because there will not necessarily be any mail user on the Exchange servers, no user migration is needed. The next step is to migrate the users from Microsoft Mail Post Office to Microsoft Exchange, but this topic is covered in its entirety in Chapter 7, "Planning Connections to Microsoft Mail Systems."[dagger]l