How many different e-mail systems make up your companies entire messaging system today? You may have a mixture of LAN- and host-based systems that may or may not be interchanging messages. You might even have just one messaging solution in place that
must be able to communicate with systems external to your company, such as the Internet. In any of these scenarios, you should realize the challenges involved in getting these systems to interoperate to meet your company's messaging needs. You only need to
review the history of messaging covered in Chapter 20, "Exchange Server and Mail Overview," to realize how your company's messaging system got to where it is today.
Migrating from your current system to Exchange can seem like a scary endeavor. Chances are your current messaging system is capable of providing basic messaging services and may even suit the company's business needs today. Unless your current messaging
system is embracing open standards, such as X.400/X.500 or SMTP, its future is very limited. Microsoft listened to its customers concerns and developed very powerful and easy-to-use migration tools. Migration wizards and source extractors are available for
Microsoft Mail Server for PC and AppleTalk networks, cc:Mail, DEC All-In-1, IBM PROFS, OfficeVision/VM, and other host-based and LAN-based systems.
This chapter covers the issues facing companies that have decided to migrate to Exchange, and explains how Exchange can interface with current messaging systems. There are many tools and procedures that can help make your migration go smoothly, and you
learn about them in this chapter. Because each messaging system is unique, I outline the methods for migration and coexistence separately for each system. Extracting the current messaging information such as mailboxes, address lists, and public data should
be easy and practical, enabling you to spend more time running your business and less time managing the keyboard.
This chapter places special consideration on the requirement to keep messaging information flowing smoothly. Keep in mind the importance of maintaining your messaging system is compounded by the business processes that are utilizing it. Even a few hours
of downtime can cost your company money in lost revenue. Your migration plan should recognize the current business processes utilizing your messaging system, and establish how they may be affected. Properly defining and executing your migration plan can
help to reduce the risk of lost messaging functionality and business processes.
Whether you are planning to replace your current e-mail system with Exchange or need to integrate Exchange into your existing messaging environment, you need to come up with a plan to address the many coexistence issues. Each individual e-mail system
has a certain way of getting business done and may have certain features that cannot easily be translated to other systems. Users are not concerned with the details involved in moving to a new system, but do not want to experience downtime or loss
messaging capabilities. Here are the key issues to keep in mind when planning for migration and coexistence follow
To address these issues, your company should put together an implementation team. Depending on the size of your organization, it may be only a few individuals or multiple groups of people. You should include individuals that are supporting the current
system, as well as people that understand the network and server systems. You might also have representation from the user community, but be careful that they do not turn your migration plan into a new feature implementation.
Before putting together a plan for migration or integration of Exchange into your current messaging system, your project team must properly define what the current system is doing. In my business, this is called creating a project scope with well
defined purposes and objectives. This involves documenting the current messaging services, external connectivity, message volume and routing, group and collaborative functionality, and business processes that depend on the existing system. From this
documentation, the team will map out how the functionality of the existing system will match to solutions available in Exchange.
The team should also define the various phases and time frames for the project. This will include phases for the initial installation, proof of concept, time of integration and coexistence, migration of messaging resources, and removal of the old
system. Larger organizations may select to address the coexistence issues first and migrate the users over a longer period of time. Smaller organizations may have the luxury of skipping coexistence altogether and cut to the new system almost overnight.
Your company's strategy will probably fall within these two extremes and should address the goals and objectives defined in the project scope.
Microsoft Exchange Server is designed to coexist with many of the most popular messaging systems and uses open standards to help solve interoperability issues. Before you can begin to migrate user accounts or claim true integration between systems, both
systems must be set up to coexist. This is best demonstrated in a multiphased migration strategy, where the two systems will interoperate for an extended period of time. Coexistence is achieved when the following conditions are met:
Connectivity between the two systems for messages is the core component for coexistence. This connection can be through a custom gateway written specifically to link the systems, or through a third entity such as the Internet or a Public X.400 network.
Custom-written connection software, such as the one to MS-Mail connector for Exchange, will best support translation of the message properties between the two systems but may not be readily available. Using an open connection such as the Internet or an
X.400 backbone to connect the systems may be a better option, but introduces problems with message security and reliability.
The connection between the two systems must be reliable because the systems will need to interoperate for an extended period of time. Carefully plan and monitor the connections you make between the systems to eliminate potential bottlenecks. Add
additional connectors with similar costs if message transfer between the systems is expected to be heavy. Tools such as the link monitor can be used to watch the connection, and the administrators should keep an eye on the message queues for the MTA.
Depending on the type of connection you select to link your messaging systems to Exchange, expect that some features will not translate across the gateway. For instance, electronic forms created and mailed in Exchange will not be able to viewed by users
on the connected system. Advanced security features such as encryption and digital signature are not currently supported for non-exchange recipients. Identify the features on each system that cannot cross the connection, and publish this information to the
user community. If a group of users needs a particular feature for business purposes, make sure they are all on the same system.
Users on the connected systems will have trouble addressing messages if there are no address lists for them to pick from. The directories on each of the systems that must coexist should have entries for the users on the other systems. This can be done
by a manual process initiated by the administrators, or setup for automatic maintenance if the systems share a common directory synchronization protocol.
Special consideration is needed to properly support distribution lists, commonly referred to as groups in other systems. For example, do you want to maintain a list of the finance users on each system, remembering to add a new user to all occurrences of
the list? The solution you choose to address this issue is dependent on the way you administer the systems and the flexibility of the directory exchange. The best solution is to move the distribution lists to the Exchange platform, because it supports
having custom recipients as members of distribution lists. You can also choose to maintain the lists separately, but if you are planning to migrate it is best to have the distribution lists located on the Exchange Server.
Migration is the process of moving information from an existing system to Exchange to support user connections to the new server. Exchange includes tools that will assist administrators in performing a migration. These tools leverage the existing
information already contained in your current system, reducing the need to retype user information. The migration process should also preserve as much of the user's custom setups as possible.
Even though migrating to an Exchange messaging solution is a straightforward process, your project team will need to address a few issues. They need to plan for training, support, naming conventions, coexistence, and solid contingency procedures.
Training for the users should coincide with the migration of their mailboxes, and administrators should be well-versed in the product before you start. The team should take a long look at the current naming conventions and change them to meet the changing
needs of the company. Coexistence between the systems is crucial if the migration will happen in multiple phases. You should also have change control and fallback procedures in place should unexpected problems arise.
Establishing a well-thought-out migration plan will pay off during the implementation portion of the migration. Depending on the system you are migrating from, different tools and processes are available to make it progress easier. There are two basic
migration strategies, single-phase and multiphase, that can be modified to meet your company's migration needs. The strategy you use will depend on the size and complexity of your organization, and should leverage the resources you already have within your
organization.
The single-phase migration is often referred to as the "hot cutover." It is best used in smaller organizations that have the resources to support such a conversion. It does require that you have existing Exchange Servers in place, which does
not allow for recycling of server hardware. Coexistence issues need not be addressed unless you are using this strategy for branch locations within a larger migration.
An example of a single-phase migration would be if you were moving a single MS-Mail post office with less than fifty users to an Exchange Server. You would first deploy the Exchange client to the user's workstations, having it access the current MS-Mail
post office. Then you could use the migration wizard to migrate the user mailboxes on a Friday night and send out a command to run the NEWPROF.EXE utility to setup the profiles for the users Monday morning. If you have done your planning correctly and all
goes well, your company could be converted to Exchange over a single weekend.
Multiple phased migrations are more in tune with the needs of a larger organization. Due to the size and complexity of their messaging systems, it is neither feasible or cost effective to do a single-phased migration. This migration strategy allows the
implementation team to recycle existing hardware and leverage the stability of a known good system for fallback purposes. As explained previously, coexistence between the systems is critical to keeping messages flowing before, during and after the
migration.
An example of a multi-phased migration would be for a medium sized organization with ten locations that have MS-Mail post offices separated by WAN links. First the company's headquarters, the current routing hub, is integrated with an Exchange Server
running the MS-Mail connector. User migration can proceed while the server implementation team moves their focus to the branch offices. Exchange Servers are brought on-line at each of the branch offices, and the mailboxes are migrated individually or by
post office depending on the number of users involved. Special planning for message routing and directory synchronization should be done before any of the branch offices are installed.
The Microsoft Mail for PC Networks messaging product line has withstood the test of time, addressing many company's messaging needs for four years longer than expected. Built upon a courier database developed in the 80s and sporting a flashy but usable
client, it has outlived much of the competition of the same period. It's distant cousin, MS-Mail for AppleTalk Networks, does have a client/server architecture, but lacks the features necessary for tomorrow's business environment. As we put these faithful
companions out to pasture, we can move foreword to an Exchange messaging solution knowing that migration and coexistence issues will be kept at a minimum.
As with any major product upgrade or replacement, moving to the new product should be as painless as possible. The developers of Exchange included some powerful tools and connectors to easily integrate into the MS-Mail environment. Customized migration
tools and source extractors enable administrators to move users to the Exchange system in only a few clicks of the mouse. A very flexible and feature rich connector is included that will seamlessly integrate Exchange into an existing MS-Mail environment.
The directory synchronization agent for Exchange will act as both a requester and/or a server to the directory process used to keep addresses updated in MS-Mail.
Before you attempt to setup the MS-Mail connector and directory synchronization with your existing MS-Mail environment, take some time to verify the health of the system. Run the PODIAG utility on each post office until all errors are corrected. Remove any unnecessary external post office definitions or they will be uploaded into the connector. Use the process of documenting your current configuration to identify things that can be cleaned up, as you do not need to drag any garbage into your brand new Exchange messaging system.
The Microsoft Mail Connector is specifically designed to link an Exchange Server to a pre-existing Microsoft Mail 3.X post office for either PC or AppleTalk networks. Because it was designed from the ground up to be fully compatible with these systems,
interoperability issues are kept at a minimum. This connector also allows you to leverage the gateways available for MS-Mail, which may provide connectivity not currently available in Exchange. If you have a good understanding of what makes MS-Mail tick
this section should be very easy to grasp.
The MS-Mail connector is made up of four distinct components:
The connector post office component, commonly referred to as the "Shadow post office," has just enough of the database structure to support gateway access components and MTA connections. Used as temporary storage of messages going between
Exchange and MS-Mail, it does not support native client connections or require any direct administration. The Connector MTAs and the MSMI take care of moving messages in and out of this post office to route them to the appropriate destination.
The MS-Mail Connector Interchange is a Windows NT service responsible for moving messages between the Exchange MTA and the connector post office. It takes messages originated by Exchange clients, converts it into MS-Mail format, and places them in the
connector post office for pickup by the MS-Mail MTA. Messages that are received at the connector post office are picked up by the MSMI and converted to the Exchange format so the Exchange MTA can deliver them to the appropriate Exchange recipient. The MSMI
also interacts with the AppleTalk MTA by transferring messages to the connection store located on the shadow post office.
The MS-Mail Connector PC MTA is a Windows NT service that transfers messages between the connector post office and MS-Mail for PC Networks native post offices. This MTA is very similar to the NT MMTA available in version 3.5 of MS-Mail, except that is
has smarter routing and better reliability. The MS-Mail Connector AppleTalk MTA is a service that works with the Macintosh gateway extension to transfer mail between Exchange and AppleTalk mail servers. It works just like the MS-Mail 3.2 Connection Gateway
product used to connect PC mail with AppleTalk mail, sending and receiving messages from the \MACGATE\STORE\PCTOMAC and MACTOPC directories on the shadow post office.
Exchange Server 4.0 shipped with an older version of the gateway extension, version 3.1a. You should update this software component to the 3.1d version located on the disks for the 3.1d version of AppleTalk Server. You should also install and run this extension on the same Macintosh that has the AppleTalk server with the gateway component installed. This will prove to be more reliable and reduce problems related to network connectivity.
The MS-Mail Connector object(s) can be found in the connections container located under the configuration object for the site. Each Exchange Server that has an instance of the MS-Mail Connector installed will show up here, and can only be configured
from this location. Typically, you will only need one MS-Mail Connector for each site, but multiple connectors in a site can provide backup routing if the proper costs are associated.
To configure the connector, open the properties for the MS-Mail connector to view the following Interchange Properties page in Figure 24.1. If this is the first time you have accessed the connector properties, you will need to click on the Change button
next to the administrators mailbox field to select a mailbox to receive administrative messages. From here, you can select the primary language for clients, maximize compatibility of OLE messaging objects and enable message tracking.
The Maximize MS Mail 3.X compatibly checkbox will enable creation of two versions of OLE objects to support previous versions of OLE, and will increase the size of messages with embedded objects. You can also enable the MS-Mail AppleTalk MTA by clicking
on the configure button in the appropriate section of the page, which will only install the service. You will need to setup the Macintosh component separately to complete the configuration for message transfer.
FIGURE 24.1. Interchange Properties page for the MS-Mail Connector.
Select the Local Postoffice Properties page seen in Figure 24.2 to set the address space Exchange will use for Exchange address generation. Enter an appropriate name for the network, post office, and password fields to match the naming conventions you
established in your planning sessions. After you change these names, click on the Regenerate button to have the system attendant update the MS proxy addresses for the Exchange recipient objects at the site.
FIGURE 24.2. Local Postoffice Properties page for the MS-Mail Connector.
Select the Connections Properties page seen in Figure 24.3 to set up connections to existing MS-Mail for PC Networks post offices. You will need to click the create button for each direct connection to an MS-Mail post office, because you will upload
routing for all indirect post offices.
FIGURE 24.3. Connections Properties page for the MS-Mail Connector.
Clicking the create button will bring up the screen in Figure 24.4 to configure a new connection to a post office. For a LAN-connected post office, click the change button and enter the full UNC path to the post office you want to connect to, such as
\\servername\maildata. Enter an account and password if the server you are connecting to will not allow the Exchange service account to make a connection, such as a Novell server or an untrusted NT domain, and click on OK. The information for the post
office is automatically filled in, and you should only need to modify the connection attempts to reduce NDRs for slow connections. Click on the update routing button, which brings up the downstream post offices summary page, to automatically upload and
configure all post offices that are defined as indirect to this connection.
FIGURE 24.4. New Post Office Connection window.
If you choose the Async or X.25 connection type, you will need to enter the network, post office, signon, X.25, and password information manually. You will also not be able to automatically update routing and will need to create connections that are
indirect via this post office manually using the same procedure and selecting the Indirect connection type. Make sure to remember to configure a MTA of type Async to handle messages for this connection.
To finish the setup of the MS-Mail connector, you create MTAs from the Connector MTAs Properties page displayed in Figure 24.5. Click on the New button to create a new MTA to service connected post offices. Enter an appropriate name for the MTA and set
the options according to your needs. When naming MTAs keep in mind that the name you give them will determine where the service will show up in the NT service manager, with ones starting with the letter A at the top and letter Z at the bottom. Create at
least one MTA of each type, such as LAN, Async, and X.25, that you need to service connected post offices. Select the MTA you just created and click on the List button to configure which post offices this MTA will service. Remember to use the MS-Mail admin
program to create a Direct-via-DOS-drive route on each connected post office to the shadow post office, or messages will not be delivered. This concludes the setup of the MS-Mail Connector for your Exchange Server.
FIGURE 24.5. Connector MTAs Properties page for the MS-Mail Connector.
Do you need to make your Exchange PC MTAs WAN friendly? When a MTA is WAN friendly, it will only deliver mail from post office to post office without distributing it to the users or checking for outgoing mail over the WAN link. This configuration requires a MTA locally at each post office on the end of the WAN link to perform the rest of message transfer. This feature is available in the 3.5 MMTA as the Enable WAN Drives option, but is missing from the Properties page of the Connector MTA. The same functionally can be achieved by disabling the mailer from the MTA Properties page, and selecting the "Do not pick up mail at this post office" selection for the connected post office. This will reduce the load on your WAN link by at least three fold, freeing up valuable bandwidth.
To have Exchange participate in the MS-Mail directory synchronization (DirSync) process, you need to set up and configure the Directory Exchange Agent (DXA) on a server within the site that a MS-Mail connector is configured. The DXA can act as both a
server and a requester to the MS-Mail system, giving administrators added flexibility to control the DirSync process. Your planning sessions will help determine whether you will use the DXA as a server or a requester depending on your migration plan and
address list needs. Using the DXA as both a server and a requester can create a multitiered configuration to get around some of the limitations of the MS-Mail native process. An example of this multitiered approach is displayed in Figure 24.6.
FIGURE 24.6. Using the DXA server and requester to create a multitiered DirSync process.
To configure the DXA to be a DirSync server to MS-Mail, select the New Other option from the File menu in the Exchange administrator, then select the DirSync Server option. This will bring up the General Properties page displayed in Figure 24.7. Click
on the DirSync Administrator button to select an account to receive DirSync messages, and check the boxes for copying and forwarding DirSync messages to the administrator as needed. Next, click on the Schedule tab to display the times when the server
should send messages to the requesters, referred to in DirSync terminology as the T2 time.
FIGURE 24.7. General Properties page for a DXA DirSync server.
You will now need to create Remote DirSync Requesters for the post offices that will use the server you just configured. Select the New Other option from the file menu in the Exchange administrator, then select the Remote DirSync Requester option. You
will see a list of the MS-Mail post offices available through the MS-Mail connector, so select the post office you want to configure. This will bring up the General Properties page for the remote requester as seen in Figure 24.8. The DirSync address field
will automatically be filled in, so enter an appropriate password and select which address types are supported on this post office.
FIGURE 24.8. General Properties page for a remote DirSync requester.
On the Import Container Properties page, you select in which container the addresses from this requester will be stored. I suggest that you create separate recipient containers for each requester post office, which will help with troubleshooting and
maintenance. On the Export Containers Properties page, select the containers you would like exported to this requester and the trust level for address filtering. If an Exchange recipient has a trust level higher than the level set here, the information on
that account will not be sent. This adds an extra level of configuration to the DirSync process that could be used to keep certain addresses from showing up in the MS-Mail global address list. Remember to use the MS-Mail admin program to register the
address of the DirSync server for each post office you define in this manner. This concludes the setup of the DXA as a DirSync server to MS-Mail.
To configure the DXA to be a requester to an existing MS-Mail DirSync server, select the New Other option from the File menu in the Exchange administrator, then select the DirSync Requester option. You will be prompted to select the address of the
MS-Mail DirSync server from the list of connected post offices. This will bring up the General Properties page displayed in Figure 24.9. You should give the requester an appropriate name and enter the appropriate password for the requester. The Schedule
Properties page enables you to configure the send and receive update times, referred to as T1 and T3. Configure the Import and Export containers Properties pages appropriately. You must also register this newly created requester with the MS-Mail DirSync
server from the admin program for MS-Mail, assigning it the password you entered on the General Properties page.
FIGURE 24.9. General Properties page for a DXA DirSync requester.
Migrating from MS-Mail to Exchange is a simple process, assuming you have planned accordingly and have set up the systems to coexist. Establishing coexistence involves setting up the MS-Mail Connector, configuring the DXA, configuring MS-Mail to use
Exchange connectors, installing gateway access components on the shadow post office, and planning your routing topology. The degree of coexistence and transfer-of-gateway functionality is fully dependent on your company's willingness to use the various
features of Exchange. You may want to leave the existing MS-Mail network routing and DirSync configuration intact because it is know to be in working order. If you decide to migrate routing, DirSync, and gateway services to the Exchange platform, you will
benefit from the additional control and features inherent to the Exchange messaging solution.
The following list is an example of the suggested twelve steps for migration, but your plan may or may not include all the steps or be in this exact order:
Migrating an existing MS-Mail 3.0 SMTP gateway to the Exchange IMC can be a tricky process. You need to make sure that each MS-Mail custom recipient in the Exchange directory has a secondary proxy address that matches their original address from the MS-Mail SMTP gateway. This address will be username@po.domain.com, where username is the mailbox of the user, and po is the name of the post office. You could export the custom recipients to a file, and use Excel or Access to add the Secondary-Proxy-Addresses field to the file to be re-imported. There is a better option. Use the MIGSMTP utility from the Web site since it will automatically update the MS-Mail custom recipients, based on the configuration of the MS-Mail SMTP gateway in a very timely manner. You should make sure that the DirSync process is working correctly before using this utility.
Lotus Development Corporation, a subsidiary of IBM, currently offers the Lotus Notes and cc:Mail messaging products. Lotus Notes has evolved over the years from a Groupware application to a full-featured messaging and Groupware solution, and is
Exchange's major competition. The cc:Mail product is an SFS-based messaging product that is similar in design to MS-Mail, with the message transfer engines located at the client and router applications. Both products have gateways, offered by Lotus and
third-party vendors, to connect to external systems via X.400 or SMTP messaging standards. Even though native gateway offerings, such as LinkAge, are currently available to connect Lotus messaging products directly to Exchange, they can be connected by
using open standards such as SMTP or X.400 or through an existing MS-Mail to cc:Mail gateway.
Because Microsoft has not proposed a connectivity option to link Lotus Notes and Exchange, you need to use the X.400 or SMTP connectors. Both systems have native gateways to support these standards, which do support message content and attachment
transfer. Managing directory information will be a manual process, involving the export and import of the entire recipients lists for each system. Public folder and Notes database information cannot be natively exchanged between the two systems, unless you
use a third-party product such as MESA Jumpstart.
Using the SMTP standard to connect Exchange to Notes has some distinct drawbacks. Messages need to be converted into simple text format, which loses any of the rich text formatting or imbedded objects. File attachments will be handled correctly, and you
should configure the connection to use the MIME encoding method for the best performance. You should configure the IMC to never send rich text to the SMTP domain name for the Notes server, and disable any rich-text properties from the Notes side.
Third-party products, such as LinkAge, DiamondNet SoftSwitch, or Control Data Systems Mailhub, can be used to link the two systems via X.400 and support directory exchange for X.500 objects. These solutions are mentioned because they will assist larger
organizations in managing the massive volumes of messaging data, using reliable and open standards for coexistence. The project planning team should research the available connectivity solutions to link Notes to Exchange, and select the product that meets
the company's long term messaging goals.
Integrating an existing cc:Mail messaging system to Exchange Server has many challenges, namely in directory exchange and feature mapping. Microsoft is currently developing a cc:Mail connector to link Exchange to cc:Mail post offices. This product is
planned to support the following features:
This connector will run as a Windows NT service and support intelligent routing and message content conversion for rich text and OLE objects. Messages that are destined for a cc:Mail recipient will be converted to support the features of that platform,
removing or modifying parts of the message appropriately. Additionally, it will enable the Exchange Server to participate as a member of the cc:Mail Automated Directory Exchange (ADE) process. This will create custom recipients in the Exchange directory
for cc:Mail recipients, and put Exchange mailboxes in the address lists of cc:Mail.
The options for connecting these two systems today utilize the X.400 or SMTP connectors built into Exchange, or existing MS-Mail to cc:Mail gateways. These options do require that the cc:Mail system have the appropriate gateway installed, which are
available from Lotus or third-party vendors. If you use the X.400- or SMTP-based solution, directory updates to both systems will be a manual process. Many of the gateway products designed to link MS-Mail to cc:Mail support the DirSync process, which will
enable the Exchange directory to automatically send and receive updates with cc:Mail via DirSync.
The migration wizard tool included with the Exchange Server has the ability to extract information about mailboxes, messages, attachments, and public bulletin boards. The source extractor does not support copying public and private mail lists, post
office address books, post office remote address lists, or propagation lists. Migration can be a one-step or a two-step migration, depending on whether you need to change directory names. In the two-step migration, you have the ability to edit the
migration file before you import it into the Exchange system. The migration process using the Migration Wizard is similar to that for MS-Mail, and is discussed later in this chapter.
Many large organizations have lots of time and money invested in host-based messaging systems. Most of these systems were developed in the early to late 1980s and still provide messaging functionality to large numbers of users. As mentioned in Chapter 20, these systems were not known for their interoperability or ease of use, but did meet the needs of an entire organization. As messaging standards evolved, host-based systems began to embrace these standards to facilitate
message transfer outside the organization. This section focuses on two of the most popular host-based messaging systems: IBM PROFS/OfficeVision/VM and Digital ALL-IN-1.
As you assemble your migration team, keep in mind the size and complexity of your company's host-based messaging system. You will need to have membership in the group from host administrators, LAN/WAN specialists, desktop support staff, and consultants.
The consultants should have practical experience in your host messaging system, as they will need to bring an objective view to the process of downsizing your messaging system. This team will be responsible for the host-based migration utilities and source
extractors, as well as for solving any issues relating to the host or migration process.
Exchange Server ships with several applications that will extract and import addresses, mailboxes, messages, shared folders, and scheduling information from your host-based system. The source extractors are used to copy directory, messaging, and
scheduling information from your current system into a standard migration file. The migration wizard will read the migration file and transfer the information into the Exchange directory and information stores. The administrator program for Exchange will
be used to export and import directory files that can be used to manually update both systems. If your host messaging system does not have a source extractor available, you can write one yourself by referring to the Creating a Source Extractor document
included on the Exchange Server CD-ROM.
The best method of migration from PROFS (Or OfficeVision/VM) to Exchange is a multiphase migration, but you could perform a single-phased migration if you have a limited number of users. To establish coexistence between the host and Exchange, you need
to connect the systems with either Attachmate's ZIP! Office Exchange gateway, MS-Mail PROFS gateway, or SMTP. The Attachmate ZIP! Office Exchange gateway has the added benefit of managing the directory syncronization between the two systems.
To begin the migration, you need to install, configure, and run the source extractor on the VM host. This includes transferring the migration software through a 3270 emulator, setting up the accounts to use for the extractor, configuring the host
executables, and launching the extractor process. The migration extractor will log on each VM ID and launch a program to extract information to do the following:
Once you have used the source extractor to generate standard migration files, run the migration wizard to import the information from the migration files into the Exchange directory and information stores. An alternative to migrating the users in phases
is to use the PROFS MAPI service provider in Attachmate's ZIP! Office Client Connection product. You could use the source extractor to create the Exchange mailboxes, then link the Exchange client to PROFS and the Exchange Server. When you perform the full
migration process for a user, you only need to send out a command to run the NEWPROF utility to remove the PROFS MAPI service provider.
It is also best to use the multiphase migration for moving users from a Digital ALL-IN-1 host messaging system to Exchange. You should be running version 2.2 or later of ALL-IN-1 to be able to use the source extractor for migration. To connect the
Exchange Server and the ALL-IN-1 messaging system, you use the X.400 connector or the IMC for the Exchange side, and one of the following for the ALL-IN-1 system:
Before you begin the migration process, you need to get the directories on both systems copied to each other. This can be done with the directory import/export from the administrative client, using Digital's Directory Synchronization Utility. You also
can use a third-party program. Plan for naming convention changes, because ALL-IN-1 supports accounts of up to 30 characters, but Windows NT accounts are limited to 20 characters.
To install the source extractor on the ALL-IN-1 system, create an account named EX_MIGRAGE with the XOWN privilege to run scripts and access the forms libraries. Grant this account the READALL and SYSPRIV privileges, so it can access the users
mailboxes. Transfer the script files and forms from the \MIGRATE\TOOLS\HOST\ALL-IN-1 directory to the ALL-IN-1 directory for EX_MIGRATE. For the ALL-IN-1 profile for EX_MIGRATE, specify EDT as the default editor, include EXFORMS as a default form library,
and include EX_MENU as the initial form. From the $ prompt in the ALL-IN-1 directory for EX_MIGRATE, run the command @EX_INST to build the EXFORMS library and rename files.
Log back on as the EX_MIGRATE account, select the MIG command from the menu, and specify the desired parameters. Run the extractor in batches of less than 100 users, and limit the extractor to batches of up to 950 users. Review the log file from the Log
menu and then transfer the created migration files to the Exchange Server in binary mode. Now run the Migration Wizard to process the migration files to load the data into the Exchange directory and information stores. The migrated clients should now be
able to open the Exchange client and see their messages, folders, and migrated address lists. They will need to send any pending deferred mail from their inbox, and reshare any shared folders by dragging them to the public folder hierarchy.
One thing you should keep in mind when migrating from either of these host systems is the effect the migration process will have on the space messages use. Both PROFS and ALL-IN-1 host messaging systems support the single message instance to save space.
When you use the source extractor to migrate messaging information, each user will get a copy of that single stored message, increasing the amount of space that will be needed on Exchange. Have the users clean up their mailboxes before you run the
extractor, and figure from ten to fifteen percent additional space requirements for migration.
If your company is currently using a UNIX-based SMTP or Post Office Protocol 3 (POP3) messaging server to provide internal e-mail capabilities, Exchange will easily coexist with these systems. The Internet Mail Connector (IMC) fully supports the RFC
#821 and #822 specifications for message transfer to and from SMTP-based systems. This connectivity option also supports UUENCODE and MIME encoding techniques for attachments to messages and extended message bodyparts.
Because these systems do not normally have built-in directories or global address lists, you need to create custom recipients for each of the mailboxes on the foreign system. Many third-party POP3 servers have proprietary methods for providing users
with address lists, but normally the users need to know the address of someone they want to send messages to. These systems also lack any Groupware or public folder capabilities, which only simplifies any migration processes.
If you are planning to migrate users from SMTP- or POP3-based systems, the process of connecting the systems and moving user mailboxes will not be very complicated. First, you must decide on which system will be the primary recipient for any external
mail from other systems or the Internet. The best choice is to use Exchange to front-end all incoming mail and have Exchange foreword messages to the SMTP host computer. You can configure the default address space in Exchange to be the primary e-mail
domain name, and configure the IMC to foreword all mail for the SMTP native users to the IP address of the SMTP host. You should already be running DNS at your site, and can use MX records to make sure all incoming mail is first sent to the Exchange IMC.
You should build custom recipients in a recipients container within the Exchange site with the primary e-mail address set to username@otherhost.domain.com, for example. You can dump the existing list of users from the SMTP host with your favorite UNIX
tool, then convert that file to the directory import format for use in the directory import tool from the administration application. Make sure to use the type of Remote in the import file, and do not create the Windows NT accounts unless you will need
them for other purposes.
Moving users from the SMTP host is not possible with any source extractor or migration tool at this time. Install the Exchange client for the users you wish to migrate, and set up their profile to use the Internet Mail service provider configured for
the SMTP host. You should then use the file you exported from the SMTP host to create an import file that can be used to create mailboxes and NT accounts for the users you want to migrate. Once you have created the mailboxes and removed the custom
recipients, new messages destined for the users should start being received in the Exchange mailbox. You should then change the user's Exchange client profile to only use the Exchange service provider, removing the Internet Mail provider connection to the
old SMTP system.
If your location has users that are on UNIX-based workstations, the Exchange client is not an option. You will want to leave the SMTP native host in place to support these users, but still use Exchange to front-end all incoming message traffic. The next
version of Exchange is slated to support native POP3 connections to Exchange mailboxes. This will enable you to configure UNIX workstations to use the Exchange Server as their e-mail server, with all the benefits of administrating Exchange native
mailboxes. The next version should also support LDAP and IMAP4 standards to enable Light Web-based clients to access Exchange native mailboxes and the Exchange directory.
If your Exchange Server site has more than one server, and requires a connection to the Internet, you have the option of increasing the security for the internal SMTP connections. One IMC can be configured to connect to the Internet, with very little restrictions on what hosts can make connections. The other IMC can be set up with the address space of @host.domain.com to match the internal SMTP host, and restrict access to allow connections only from that host. You should also update your internal DNS record for the internal host with an MX record for better performance.
Of all the connector options used for coexistence with foreign messaging systems, the X.400 connector is the most robust and reliable. It is hard to find an enterprise level messaging system that does not support native X.400 connectivity, either by
design or by gateway options. Exchange Server has gone through extensive conformance and interoperability testing to prove that it subscribes to the standard, and it can communicate with other systems that subscribe to the X.400 recommendations. The
following systems have been tested using the OSINET and EUROSINET interoperability test suites for 1984 and 1988 X.400 conformance using the P1, P2 and P22 protocol scenarios:
The Exchange X.400 MTA was tested for conformance with the following network configurations over the three most popular standard OSI transports—TP0/X.25, TP4/CLNP, andTP0/RFC1006 to TCP/IP:
This extensive testing with other vendor's systems does not guarantee complete conformance with the standards, but it is a good indicator of how well the Exchange X.400 connector can "play with others." The capability of Exchange to connect to
other vendors systems is very important for larger customers, because they already have these and other systems that use the X.400 standards for interconnectivity. Many of the hub-and-switch technologies used to interconnect the messaging infrastructures
of global corporations employ X.400 and X.500 standards to create robust routing backbones and directory services.
The X.400 connector is normally used as a coexistence connector to support a multiphase migration from another messaging system, so it is unlikely that you will need to convert from an X.400 native messaging system. The source extractors for the system
you are converting from will extract the messaging information to a common format that can be imported into Exchange by the Migration Wizard. This is why there are no source extraction programs to extract messaging information from X.400-based systems.
The X.400 connector supports sending and receiving messages from other X.400 mail systems operating as a relay MTA. It can also operate as a PRMD-to-PRMD (Private Management Domain) MTA to provide standalone message backbone services for customers that
do not want to subscribe to a public X.400 service to connect their systems. This flexibility extends the options companies have to interconnect existing Exchange and foreign X.400 messaging systems.
The Exchange directory service and X.400 name space can include addresses from external X.400 systems to enable customers to mail to recipients on those systems. The directory import tool enables administrators to bulk import X.400 addresses into
recipient containers as custom recipients. These addresses are then automatically replicated throughout the Exchange organization by the directory replication process. Users at other Exchange sites will then see those recipients in their global address
list and do not need any custom procedures to mail to these recipients. Users also have the option of creating X.400 address recipients in their personal address list as long as they know the address of the person they wish to mail to.
The X.400 connector and MTAs are not limited to just connecting to external systems. Robust message routing and fault-tolerant message transfer can be established between Exchange sites and Exchange organizational messaging systems. You can even connect
two MS-Mail systems through Exchange if they have the X.400 gateway access components installed. This enables the messaging infrastructure architects to use Exchange to build a corporate backbone without the need for proprietary third-party software
solutions.
The X.500 directory schema defines the object properties for all Exchange recipients, which third-party directory services can use to replicate to other systems. Future versions of Exchange will support access and update methods for lookup and
modification to the Exchange directory, such as the Lightweight Directory Access Protocol (LDAP) standard. As Exchange is updated and enhanced in new releases, this directory information will be the cornerstone used to build new applications and create a
detailed view of the entire organization.
If you use X.400 connectors to connect your sites, make sure to set the conformance options the same for both ends. If you change the conformance options on the Advanced Properties page for the connector only at one site, message transfer will immediately stop between the sites. I suggest that you always create a X.400 connector that will be used exclusively for connections to other Exchange sites, with separate connectors for external or foreign X.400 systems.
Earlier sections in this chapter have already covered the various source extraction tools used to create migration files for a two setup migration process. This section covers the use of the Migration Wizard to import those files, as well as the
one-step migrations available for MS-Mail and Lotus cc:Mail. These tools provide administrators and migration specialists with time- and labor-saving processes that enable them to focus on the migration and coexistence issues, reducing the headaches they
may have experienced in previous migrations for other systems.
The Exchange Migration Wizard, MAILMIG.EXE, is installed in the directory \EXCHSRVR\BIN on every server within the organization. It can be copied to an administrative workstation as long as the Exchange administration program is installed and working
correctly. It is a Windows NT 32Bit application that does take advantage of some multithreading capabilities. Performance can suffer if it is used to migrate information to a server that is separated from the machine running the program by slow or
unreliable links. For performance reasons, run the Migration Wizard from the Exchange Server you are migrating data to. It should generally be run after normal business hours if you are importing large amounts of data. As you use this tool to import new
information to your Exchange Servers, you will get a pretty good picture of how well your servers will perform under heavy loads.
Once you are finished with the source extraction process from your existing system, the migration files will need to be processed by the Migration Wizard. The source extractors will create three files: the packing list file, the primary migration file,
and the secondary migration file. You should make any directory object naming changes to these files prior to moving to the next step. The following list explains the purpose of each file:
Depending on the amount of information you are migrating, these files can range from a few hundred kilobytes to a few hundred megabytes. They may need to be stored on a system with plenty of temporary drive space, and your migration plan should include
procurement of this hard drive space. Before you import the files into your Exchange system, you should run the verification process on the migration files to check them for errors. There is nothing more frustrating than to come into work to find that the
import process you started last night hung up on the fifth recipient because of a syntax error. See Figure 24.10 for an example of the import file page and verification options.
FIGURE 24.10. Migration Wizard import file page with verification option enabled.
After you have verified the integrity of the three migration import files, you should use the Migration Wizard to start the process. This can take as little as two minutes or two hours, depending on the number of users and the volume of messages. The
status screen in Figure 24.11 illustrates the progress and elapsed time for the migration process. It may be informative, but it is as interesting as watching grass grow. This is a good time to review your migration project milestones to make sure you are
on target.
FIGURE 24.11. Migration Wizard status page.
Once the process is complete, review the migration wizard error file and the Windows NT event viewer. The wizard error file will contain information from the primary migration file, in the same format, that the process had problems with. It can also
contain pointer information from the secondary file that was in error. Edit these entries as needed and run the migration wizard on the corrected file to retry those entries. The Windows NT event viewer will have informational and error messages from the
migration wizard application, or from other processes such as the proxy address generation done by the system attendant. Once the migration is completed without errors, review the mailbox and distribution list objects that were created for accuracy.
The Migration Wizard will perform the source extraction and import processes for migration of MS-Mail and cc:Mail messaging systems. You can perform a one-step migration from the wizard, or do a two-step migration if you need to edit any information
before it is imported. The screens and selections for MS-Mail and cc:Mail are practically identical, so this section will use a MS-Mail migration in the example. If you elect to perform a two-step migration for either of these systems, the three migration
files will be created and should be imported as outlined in the previous section.
When you start the Exchange Migration Wizard, you will see the following screen in Figure 24.12. From this page, make the selection for MS-Mail for PC Networks and click on the next button. You will then see information concerning coexistence between
the two systems to support the migration process. Click on next in this window to continue.
FIGURE 24.12. Migration Wizard selection type page.
You will now see the screen in Figure 24.13, prompting you for the location and security information for an existing post office. Enter the full UNC address of the MS-Mail post office, such as \\servername\maildata. Enter the administrator's mailbox and
password for the security information, then click on the next button after you have entered the appropriate information. You will now be prompted to select a one-step or a two-step migration. In this example, you are going to perform a one-step migration
and you make the appropriate selection and click on the next button.
FIGURE 24.13. Migration Wizard post office and security page.
If you receive an error message that the selected post office is read-only, then users may have the file MASTER.GLB or FLAG.GLB locked. Use server manager to close any connections to either of these files. If you are at the server that has the post office on it, you can issue the command net files | find /I "GLB" to list the user connections to these files. Use the command net files XXXXXX /c where XXXXXX is the file connection number for the file you want to close. After the MASTER.GLB and FLAG.GLB are closed you can continue with the migration wizard by clicking on next.
The next screen in Figure 24.14 will enable you to select the information to convert. There are selections for the mailboxes, e-mail messages by range, personal e-mail addresses, schedule plus information, and shared folders. You should make appropriate
selections for the information you want to migrate. Remember to migrate the shared folder information only once, because you will receive a message in the event viewer if you try to convert the shared folders more than once. Click on the next button to
continue.
FIGURE 24.14. Migration Wizard items to convert selection page.
The next page you will see will give you a list of the user mailboxes on the selected post office in Figure 24.15. Select the user mailboxes you want to migrate, and if you are going to do the entire post office deselect the admin and any nonuser
mailboxes. Click on the next button to continue.
FIGURE 24.15. Migration Wizard mailbox selection page.
If you selected to migrate shared folder information, you will be prompted to select what type of default access permissions to assign to the public folder that will be created. Be careful if you select the no access selection, because only the folder
owner will be able to access and manage the new public folder that will be created. Click on the next button to continue.
The next selection screen will prompt you for the Exchange Server to use for the migration. Enter the server name of the Exchange Server you want to put the user accounts on and click on the next button. The next screen in Figure 24.16 will enable you
to select the recipients container and the template mailbox to use for mailbox creation. Choose the recipients container you want the new addresses to appear in, and choose an appropriate template account that has previously been set up. The template
account should only include properties that you want all the mailboxes you are migrating to have, so be very careful which one you select. Click on the next button to continue.
FIGURE 24.16. Migration Wizard Recipients Container and Template Mailbox page.
The next screen (see Figure 24.17) enables you to select whether you want NT accounts to be created, the passwords to use, and the domain to create them in. If your users already have NT accounts, the migration process will attempt to match an NT
account to the mailbox value. If you need NT accounts that will differ from the user mailbox, select to not create accounts. Select also the appropriate Windows NT domain you want the Migration Wizard to use. Click on the next button to continue.
FIGURE 24.17. Migration Wizard Windows NT account and Domain page.
The Migration Wizard will now display the status window that will tell you how the migration is proceeding. There is information on the number of accounts, messages, and folders that are being and have been migrated. The number of warnings and errors
are also listed. This process will run for as long as there are messages and accounts to be migrated. The length of time it will take is fully dependent on the amount of data to be converted and the connection speed you have to both systems. Remember to
avoid running this process across a slow link, because it will take extraordinarily long to complete.
When the process is finished, review the migration log and the NT event viewer application log for errors and warnings. If all has gone well, you have successfully migrated a number of users to Exchange and set up the directory object properties. You
will want to review the mailboxes you just migrated to make sure they have the proper primary NT accounts selected and have the users validate that their messages and personal address lists have been properly migrated.
Many companies have complex messaging systems that are made up of different messaging products. The challenge is to connect these systems to Exchange to establish coexistence for interoperability or support of a migration. Coexistence is a key component
for any multiphase migration project to make sure the various systems can interchange messages and directories. Planning your company's migration strategy by utilizing a diverse project team is critical to the success of your endeavor. Users should not
experience loss of messaging functionality during the conversion, and directory information must be kept up-to-date on both systems so that users can still find individuals that have and have not been migrated.
Microsoft Exchange includes various tools and connectors to help systems coexist and smooth the migration process. Source extractors are available for the most popular proprietary host- and LAN-based messaging systems, and are used to extract valuable
information from your current e-mail system to be loaded into Exchange's directory and information stores. The included Migration Wizard simplifies the process of extracting and propagating the information from the migrated system into the Exchange
messaging system. The connector solutions that are used to interconnect Exchange to current messaging systems include the X.400 connector, the Internet mail connector, the MS-Mail connector, and various third-party solutions. Exchanging directory
information between the systems during coexistence will reduce user addressing problems, and help make the transition much more seamless. Smaller companies may have the luxury of skipping the coexistence phase of a migration and switch to Exchange
practically overnight.
Chapter 25, "Exchange Server Performance Tuning and Scaling," covers Exchange Server performance tuning and scaling. I attempt to help you answer the famous question, "How many users can I put on a single Exchange Server?" The chapter also outlines techniques that can be used to tune and monitor your Exchange Servers in a production environment. The need for various utilities and tuning methodologies are balanced against the need to keep your system running reliably. Chapter 25 should be fun for both you and me because it will enable us to get under the hood of Exchange to see just how powerful it really is.
