Chapter 4
Migrating from Microsoft Mail for PC Networks
Before moving users from Microsoft Mail for PC Networks [MS Mail (PC)] to Microsoft Exchange Server, you need to know the following:
	Users running the Microsoft Exchange Client with a Microsoft Windows operating system can use MS Mail (PC) postoffices.
	Microsoft Exchange Server users can send and receive mail through Microsoft Mail (PC) gateways.
	Users running the Microsoft Exchange Client can work with custom forms, commands, and MSMAIL.INI and SHARED.INI files.
	Directories can be synchronized during multiphase migration.
	Users in both the existing and the new system can view schedule information.
	All applications based on Common Messaging Calls (CMC) and Simple MAPI work with Microsoft Exchange Server.
	Both administrators and users can use migration tools to migrate messages in mailboxes, mail message files (MMFs), personal address book (PAB) entries, shared and private folders, and Schedule+ calendars.
	Personal address lists (PAL) and template information are not migrated.
To perform the migration, you do the following:
	Determine what scenario best describes your current installation.
	Make decisions on issues that are relevant to your scenario.
	Familiarize yourself with the migration tools.
	Test your plan.
	Put your plan into action.
Scenarios
Your migration plans should be based on your situation, your current installation, the Microsoft Exchange Server organization, and resources.
One Postoffice
If your organization has just one or a few postoffices in a site, you might be able to move everyone to the new system at the same time. However, you should test your plan beforehand. Configure monitoring, a public folder hierarchy, permissions, replication, mailboxes, distribution lists, gateways, custom forms, and client installation points, and then test your plan. You can create mailboxes first and migrate contents after testing.
Situation	See section	
		
Currently using electronic forms	Electronic Forms Designer Forms	
Have SMTP gateway installed	Migrating to the Internet Mail Connector	
Have X.400 gateway installed	Migrating from an X.400 Gateway to an X.400 Connector	
Some users are using remote clients	Remote Users and Offices	

In addition, you should read the following sections: “Mail Message Files,” “Personal Address Books and Lists,” and “Schedule+ Messages and Calendars.” Then skip to the “Migration Tools” section to learn more about the Migration Wizard.
Few Postoffices Migrating to One Site
You need to decide how quickly you plan to migrate to Microsoft Exchange Server. If you can do it in a single phase, then you can skip reading sections in this chapter about multiphase migrations. You should look at the table in the previous section to see if any of the situations match your current installation, and if so read the appropriate sections. In addition, you should read the following sections: “Mail Message Files,” “Personal Address Books and Lists,” and “Schedule+ Messages and Calendars.” Then skip to the “Migration Tools” section to learn more about the Migration Wizard.
If you can’t migrate in a single phase, you should read all of this chapter.
Multiple Postoffices or Mail Systems Migrating to Multiple Sites
Most multiple site organizations need to migrate using a multiphased approach. This chapter covers many of the issues that you will face in planning, coexistence, and rollout.
If you have the resources to migrate in a single phase, then you should install, prepare, and test your enterprise completely before users are migrated to the system. Configure and test monitoring, public folder hierarchy, permissions and replication, mailboxes, distribution lists, gateways, custom forms and client installation points. Mailboxes can be created prior to the switch-over, and then contents migrated after testing is completed. You should look at the table in the section One Postoffice to see if any of the situations match your current installation, and if so read the appropriate sections. In addition, you should read the following sections: “Mail Message Files,” “Personal Address Books and Lists,” and “Schedule+ Messages and Calendars.” Then skip to the “Migration Tools” section to learn more about the Migration Wizard.
Issues to resolve
Not all of these issues will apply to your installation. For all issues that do apply, you need to understand how they impact your migration plans.
Using Microsoft Exchange Clients with the 
Microsoft Mail (PC) Information Service
Microsoft Exchange Clients running under Windows platforms can be used as clients for Microsoft Mail (PC) postoffices by adding the Microsoft Mail information service to the profile. This can be done before migration or before and during phased migration to move users to the new client while retaining the postoffice infrastructure. The users benefit from some of the new features, including rich text, AutoSignature, and views. You also have a consistent user interface between those that have migrated and those that haven’t.
However, before you roll this out, you may need client hardware upgrades. For example, remote clients that upgrade require Remote Access Servers (RAS) or the equivalent instead of the computer running EXTERNAL.EXE. Also, two configurations of the client software must be made on every desktop—one at Setup to connect to the postoffice and another after migration to connect to the server.
Using the Microsoft Mail (PC) Information Service
Depending on your overall migration strategy, there are several ways to use the information service:
Strategy	Using the MS Mail (PC) information service	
		
Single-phase migration	Use it before migration to give users some of the features while you are planning and testing the enterprise design.	
Multiphase migration	Move the company over to a consistent user interface as you migrate mailboxes in stages.	

Use the Setup Editor to make the Microsoft Mail (PC) information service the default for the profile, and install the Microsoft Exchange Server information service. When the user installs the Microsoft Exchange Client, the Profile Wizard pulls most of the default information for connecting to the postoffice from the MSMAIL.INI file.
The user then needs to import the contents of the mail message files (MMFs). If the MMF is in the postoffice, the user should first connect to the postoffice with the old client and move the MMF to the local disk or a viewable network share before importing the contents. If the MMF file is left on the postoffice, the contents will be migrated to Microsoft Exchange Server when the mailbox is migrated.

Note
Once a user begins using Microsoft Exchange Client, there is no easy way to migrate the messages they receive to an MMF or mailbag file. They can copy the messages to a shared folder and then retrieve them with the old client. However, this does not guarantee privacy.

If users previously used the MS-DOS or Apple® Macintosh client, the contents of their inboxes will be automatically transferred to personal folder files by the Microsoft Exchange Client. If users have private folders, the Microsoft Exchange Client with the MS Mail information service can’t access these folders. Before switching to the Microsoft Exchange Client, the user can either install the Microsoft Mail Windows client and migrate these folders into an MMF or move the folders to the server (if they are stored locally) and wait until they are moved to Microsoft Exchange Server when the mailbox is migrated.
Upgrading to Microsoft Exchange and the 
MS Mail Information Service
Microsoft Exchange Client users must migrate their MMFs to a personal folder file. When MMFs are stored on a postoffice, you can use the MMFClean utility to manage their size and the age of messages. Personal folder files should not be stored on the postoffice because after the administrator migrates everyone from the postoffice, the postoffice share should be made inaccessible.
The MMF migration tool does not delete the MMF when it creates the personal folder file. Move MMF files locally, or delete them after their contents are migrated to personal folder files.
Schedule+ Coexistence with the MS Mail 
Information Service
Users who switch to the Microsoft Exchange Client must also switch from Schedule+ 1.0 to Schedule+ 7.0. When they run Schedule+ 7.0 for the first time, it migrates their CAL (Schedule+ 1.0 calendar format) file to SCD (Schedule+ 7.0 calendar format) file.
Schedule+ 7.0 can read CAL, POF (Schedule+ 1.0 postoffice free/busy times) and SCD files, but Schedule+ 1.0 can read only CAL and POF files. If you have heavy Schedule+ users, switch everyone over to the new client at the same time. If only some switch to Schedule+ 7.0, the rest cannot view their calendars or act as delegates.
Hardware Requirements for Clients
The minimum hardware requirements for the Microsoft Exchange Client are higher than those for Microsoft Mail (PC). Increased client hardware requirements may delay some users from migrating until their hardware is upgraded. For more information on hardware requirements for the client, see the Introduction.
Phased Migration Options
Your plan needs to include how many mailboxes will migrate to Microsoft Exchange Server at a time. Generally, migrating the entire postoffice (every mailbox) will be easier to plan for, implement and maintain than migrating a partial postoffice. Migrating a partial postoffice is more likely to occur during a pilot or limited rollout, when the number of users is small and the issues are easier to solve or work around. The following section explains why this is so.
Migrating a Partial Postoffice
When you migrate a partial postoffice, the MS Mail (PC) 10/10/10 (Network/Postoffice/Mailbox) address is not retained, which is a disadvantage for the following reasons:
	Routing to the postoffice from other postoffices and gateways must be maintained so that the remaining mailboxes continue to receive mail. 
	Mail sent from foreign systems through an MS Mail (PC) gateway to an old address is delivered to the old address (if the mailbox hasn’t been deleted) or returned as undeliverable, so the user has to check for mail on both systems. Administrators for the foreign system need to replace the old address with the new one in the system address list, and users in that system need to update their personal address books. 
	Directories in MS Mail (PC) postoffices and foreign systems that have an old address have to be updated immediately because the old address is invalid. If you configure directory synchronization with Microsoft Exchange Server, this updating occurs automatically. If you want to leave the old mailboxes on the postoffice but remove them from the global address list, you can modify the mailbox. In the MS Mail (PC) Administrator program, change the Include User in Directory Synchronization option to No.
	Replies from MS Mail (PC) users to mail received in the past from a user who has since migrated are delivered to the old MS Mail (PC) mailbox if the mailbox hasn't been deleted, or returned as undeliverable. Users should try to resend their mail, using the MS Mail (PC) global address list.
	Mail messages that are migrated to Microsoft Exchange retain only the display name of the sender with the exception of sender and recipients that have SMTP or X.400 type addresses, which are preserved. Reply messages need to resolve this display name and match it to one in the Microsoft Exchange global address list or the PAB. If the display name has changed, or the name does not resolve to a unique entry, then the user must select the name from an address list.
	MS Mail (PC) personal address book (PAB) entries of users who have already migrated are invalid. Users should try to resend their mail, using the MS Mail (PC) global address list. Users can synchronize their PAB with changes in the global address list using PABCheck.

Routing Change
No changes in the routing of e-mail from other postoffices and gateways are allowed when doing a partial postoffice migration. The mailboxes remaining on the postoffice need mail addressed to them to continue to be delivered.
MS Mail Gateway passthrough
Mail sent from external sources through Microsoft Mail (PC) gateways to the old address will be routed to the Microsoft Mail (PC) postoffice. This could cause mail to be returned as undeliverable or delivered to an unused mailbox.
To avoid this, you can update the gateway’s mapping table (if there is one) so that mail is routed to the new address. For example, the Microsoft Mail (PC) X.400 gateway has an address mapping table so that mail addressed to the old X.400 address is redirected to the new MS type e-mail address of the Microsoft Exchange Server mailbox. Updating the mapping table works well during a pilot rollout, but isn’t recommended when you’re migrating thousands of mailboxes at once, because gateway performance will be affected.

Tip
Move users who send mail to each other frequently at the same time.

PABs for users who haven’t migrated
Mail sent with old PAB addresses in Microsoft Mail (PC) will try to go to the old mailbox. If the mailbox has been deleted, the message will be returned as undeliverable. The sender can try to resend it using the Microsoft Mail (PC) global address list, which may or may not have been updated yet with the new address, depending on whether the directory synchronization cycle has completed. Users can synchronize their PAB with changes in the global address list using PABCheck.
Migrating an Entire Postoffice
If you migrate every mailbox on a postoffice at the same time, you can retain the original Microsoft Mail (PC) 10/10/10 (Network/Postoffice/Mailbox) addresses as their MS type e-mail addresses. This has many advantages, as follows.
	Since the addresses of the old and new mailboxes are the same, you can route mail that has an old address. You have few routing changes and no interruption in mail delivery. However, you do need to adjust the routing in MS Mail (PC) to the old postoffice so that it’s indirect through the Microsoft Mail Connector postoffice. If you used a hub-and-spoke routing system, you have to make changes to only a few postoffices. The Microsoft Mail Connector has the old postoffice removed from its routing information. When mail addressed to one of the migrated mailboxes is routed to the Microsoft Mail Connector postoffice from the Microsoft Mail (PC) side, the Microsoft Mail Connector resolves the address as one belonging to a Microsoft Exchange Server mailbox and forwards the mail.
	Mail that passes through a Microsoft Mail (PC) gateway to migrated mailboxes is delivered. The Microsoft Mail Connector postoffice must have an access component for the gateway. Because the addresses for migrated mailboxes have not changed, mail is routed from the gateway to the Microsoft Mail Connector and from there to the Microsoft Exchange Server mailbox.
	Directories in MS Mail (PC) postoffices and foreign systems that have old addresses are valid. Therefore, mail sent from foreign systems and routed through MS Mail (PC) are delivered to the migrated mailbox without your needing to change gateway mapping tables or update directories.
	Users still on Microsoft Mail (PC) can reply to mail they received in the past from a user who has migrated. MS Mail (PC) messages retain the full address of the sender. Replying to a message automatically addresses it to the same address. Mail is routed to the Microsoft Mail Connector postoffice and then on to the Microsoft Exchange Server mailbox. 
	MS Mail (PC) personal address book entries of users who have already migrated are valid because old and new addresses are the same. 
	Migrated PAB entries for MS Mail (PC) mailboxes which have been migrated are invalid. Mail is routed to the Microsoft Mail Connector, which doesn't have a postoffice configured with that address and returns the mail as undeliverable. This undeliverable mail can be readdressed from the Microsoft Exchange Server global address list and delivered normally. There is no tool that updates the user’s PAB entries as changes are made in the Microsoft Exchange Server global address list. To prevent undeliverable mail, users can remove all PAB entries of MS type from their PAB after they migrate to Microsoft Exchange Server.
	Mail messages that are migrated to Microsoft Exchange retain only the display name. Replies to these messages need to resolve the address against the Microsoft Exchange Server global address list or an accurate PAB. Mail messages that have sender or recipients with SMTP or X.400 addresses are migrated with the complete address and can be replied to without address resolution.

PABs for users who haven’t migrated
PAB entries function similarly to replies. For Microsoft Mail (PC) users, their PAB addresses continue to work for migrated mailboxes because the addresses are the same.
Migrated PAB entries will work for Microsoft Mail (PC) mailboxes that have not migrated. Mail addressed with the migrated PAB to mailboxes that have since migrated will get routed to the Microsoft Mail Connector. The Microsoft Mail Connector does not have a postoffice configured with that address and will return the mail as undeliverable. This undeliverable mail can be readdressed from the Microsoft Exchange Server global address list and be delivered normally.
There is no tool that updates the user’s PAB entries as changes are made in the Microsoft Exchange Server global address list. To prevent undeliverable mail, users can remove all PAB entries of MS type from their PAB after they are migrated to Microsoft Exchange mailboxes.
Gateway Passthrough Support
Microsoft Exchange Server users can send and receive mail through gateways installed on Microsoft Mail (PC) postoffices. The Connector postoffice needs to have the access component or gateway installed, and the Microsoft Exchange Server site needs address space mapped. Custom recipients for Microsoft Mail (PC) mailboxes might need to have their default e-mail or proxy address updated so that mail sent to the old address can be resolved to match the custom recipient. 
Migrating to the Internet Mail Connector
For your users to send to and receive mail from the Internet, you need to replace the MS Mail (PC) SMTP connector with the Internet Mail Connector. The following requirements must be met before you make the switch:
	Mail addressed with the global address list and sent between Microsoft Mail (PC) and Microsoft Exchange Server is routed and delivered without any problems. The easiest way to do this is to connect the two systems with the Microsoft Mail Connector, but any type of connection can be used.
	All Microsoft Mail mailboxes that will send or receive mail through the Internet Mail Connector with their current address must be in the Microsoft Exchange Server global address list as custom recipients. The easiest way to do this is to configure directory synchronization and wait for the custom recipients to be created. You can skip this step, but the SMTP addresses of MS Mail (PC) users default to: IMCEAMS_<network>_<postoffice>_<mailbox> @<site>.<organization>.<domain>
	All Microsoft Mail postoffices have an access component for the SMTP gateway.
	The Internet Mail Connector is configured and tested on a server in any site in the organization. Mail sent from Microsoft Exchange Server mailboxes is delivered to the Internet or SMTP system.

After these conditions have been met in this order, make adjustments to addressing and routing on Microsoft Exchange Server and on the Domain Name System (DNS) MX record for the site’s domain before the gateway can be shut down and the use of the gateway is migrated. This process depends on your configuration.
Migrating from the Microsoft Mail (PC) SMTP Gateway to the Internet Mail Connector

How you migrate to using the Internet Mail Connector depends on how you were using the SMTP gateway and how you plan to use the Internet Mail Connector. The following table summarizes the three approaches.
SMTP gateway uses	Internet Mail Connector uses	
		
Primary connection to the Internet.	Primary connection to the Internet.	
Another system connects to the Internet, and the SMTP gateway handles mail for MS Mail users only.	Another system connects to the Internet, and the Internet Mail Connector handles mail for MS Mail and Microsoft Exchange Server users only.	
Another system connects to the Internet, and the SMTP gateway handles mail for MS Mail users only.	Internet Mail Connector connects to the Internet and handles routing for all e-mail systems in your organization.	

Addressing has been improved with the Internet Mail Connector, so Microsoft Exchange Server recipients can have up to five SMTP addresses. This allows you to maintain your existing addresses if you want to change address conventions.

Addressing configured for an SMTP gateway	Addressing configured for the Internet Mail Connector	

Method	
			
Uses default structure: user@postoffice.network.domain	Use default for site:user@domain	Switch address conventions	
Uses default structure: user@postoffice.network.domain	Preserve addresses for migrated users	Maintain internal addressing conventions	
Uses alias table to hide default structure from outside world	Preserve outside world addresses	Maintain external addressing conventions	
Uses default structure: user@postoffice.network.domain	Use default for site:user@domain but support old addresses	Use multiple e-mail addresses	

Switching Address Conventions
Migrating to Microsoft Exchange Server can give you a chance to start over with standardized addresses. When new mailboxes are created, an SMTP address is generated based on the rules in the Site Addressing property page. This address can be replaced or supplemented with other e-mail addresses. Set up this before beginning to migrate mailboxes. 
This is the easiest way to reduce directory synchronization chores during migration. However, there are some additional steps you need to take for this approach to succeed:
	Install and test the Internet Mail Connector.
Establish a new MX record for the new address. Mail sent to the new addresses will be routed to the Internet Mail Connector, while mail sent to the old addresses is routed to the SMTP gateway.
	Inform users of their new SMTP addresses after their mailboxes are migrated.
As users migrate from Microsoft Mail to Microsoft Exchange Server, their SMTP address changes. The users must let their correspondents know of the changes to their address. You can use directory export to create the list of addresses.
	Retain the Microsoft Mail address as the primary or secondary Microsoft Mail type e-mail address of the Microsoft Exchange Server mailbox when migrating entire postoffices.
If users retain their Microsoft Mail address, and mail sent to their postoffice is routed to the Microsoft Mail Connector, mail arriving at the SMTP gateway addressed to the old address is routed to them.
	After migrating all mailboxes to Microsoft Exchange Server mailboxes, continue operation of the SMTP gateway until the flow of mail is reduced significantly. 
Inform those users still receiving mail from the SMTP gateway that mail addressed to the old SMTP address used by the SMTP gateway will not be delivered. Shut down the gateway.

Maintaining Internal Addressing Conventions
By default, the SMTP gateway creates addresses for all Microsoft Mail mailboxes based on their network, postoffice, and mailbox names. You use retain those addresses and migrate to the Internet Mail Connector by updating the e-mail addresses for the custom recipients and mailboxes in Microsoft Exchange Server with directory import. You need to update all the custom recipients after directory synchronization is completed the first time. If you don’t replace custom recipients with mailboxes, you must update every mailbox as it is created on a Microsoft Exchange Server. If you ever change the site’s e-mail addressing properties, update all the mailboxes in the site.
	To create the import file for modifying all the custom recipients
	1.	Create a text file with this header:
Obj-Class,Common-Name,Target-Address,Proxy-Addresses

	2.	Use the Directory Export command to export custom recipients to the text file.
	3.	Modify the proxy-addresses field based on the target-address field without changing X.400 and other address types. This can be done with a macro or a custom program.

Important
Microsoft Excel and other spreadsheet programs have a 256-character limit per cell. The proxy-addresses field can have more than 256 characters. Do not import the directory export file into Microsoft Excel or any other spreadsheet with this limitation because any characters beyond the first 256 are truncated and lost without warning. Use a database program such as Microsoft Access or Microsoft Visual FoxPro™ to get around this limitation.

	4.	Save the modified file in CSV format.
	5.	If the modified file’s proxy-addresses field contains all the e-mail addresses for the recipient, use directory import with the Overwrite option selected in the Directory Import dialog box.
– or –
If the modified file’s proxy-addresses field contains just the new SMTP e-mail address for the recipient, use directory import with the Append option selected in the Directory Import dialog box.

The DNS can now be updated to route all mail for this domain to the Internet Mail Connector instead of to the SMTP gateway. The Internet Mail Connector resolves each address as belonging to a Microsoft Exchange Server recipient — mailbox, custom recipient, public folder, and so on — and routes the mail accordingly. When the SMTP gateway stops receiving mail, you know this change has been made in the DNS.
Next, the other postoffices need to have the access component reinstalled to route outbound SMTP mail to the Microsoft Mail Connector postoffice. Migration to the Internet Mail Connector is now complete.
As mailboxes are migrated from Microsoft Mail postoffices, the custom recipient for the mailbox is removed, and a mailbox is created. If you have this configured to replace the custom recipients with mailboxes, the e-mail addresses are preserved. 
Otherwise, the mailboxes should have their e-mail address updated as they are created or immediately thereafter. This can be done as part of the migration user list file or as a separate directory import file. To get the correct e-mail addresses, use directory export to create a file of custom recipients and their correct e-mail addresses before you begin to migrate mailboxes. 
Maintaining External Addressing Conventions
Some Microsoft Mail networks have a host with an alias table which maps a simple external SMTP address to the more complex address that the SMTP gateway understands. For example, if external mailboxes have simple addresses, such as name@domain, the mapping table converts them to mailbox@postoffice.network.domain.
You can switch to that simpler address when migrating to the Internet Mail Connector. This preserves the addresses that your users and their correspondents are used to. You need to use the Directory Export and Directory Import commands to modify the e-mail addresses of custom recipients and migrated mailboxes.
The difference between this scenario and the previous one is that the source of the new e-mail address is the alias table. After modifying all recipient addresses in Microsoft Exchange Server, the MX record in the DNS can be modified and the alias table removed. After this is done, the postoffices can have their gateway access component removed and reinstalled as needed.
Migrating to Microsoft Exchange Server and 
Using an SMTP Gateway
If you migrate mailboxes to Microsoft Exchange Server before installing the Internet Mail Connector, you can configure your system to allow Microsoft Exchange Server users to use the SMTP gateway. Install an access component on the Microsoft Mail Connector postoffice pointing to the Microsoft Mail postoffice with the gateway, and configure the Microsoft Mail Connector address space to route mail sent to SMTP from Microsoft Exchange Server.
Because routing in Microsoft Mail is based on network and postoffice names, routing mail to Microsoft Exchange Server mailboxes is handled in one of the following ways:
Situation	Addressing solution	
		
Using an alias table on SMTP host to map friendly addresses to Microsoft Mail gateway SMTP addresses.	Change the alias table to route mail to the appropriate Microsoft Exchange Server mailbox’s MS type e-mail address.	
Migrating partial postoffices and not using an alias table.	Microsoft Exchange Server mailboxes have a new SMTP address based on the Microsoft Mail Connector network and postoffice name.	
Migrating entire postoffices and preserving Microsoft Mail type and SMTP e-mail addresses on migrated mailboxes. No alias table is used.	The old SMTP addresses route to the new Microsoft Exchange Server mailboxes without modifying the SMTP address.	

Command Line Options
This section consists of an alphabetical list of the SMTPGATE program options and how those features are set or utilized in the Internet Mail Connector.
Command line:	In the Internet Mail Connector use:	
		
-BDmm-dd-yy
-BThh:mm
-BRdd:hh:mm	The Internet Mail Connector runs continuously and does not support these features.	
-C[newdi]	Logging is controlled from the Administrator program.	
-Dd	No longer needed.	
-G[acnsy]	No equivalent.	
-H	Help on the Internet Mail Connector is available in the Administrator’s Program.	
-HA	By recipient instead. See MAPI Recipient checkbox on Advanced property sheet of the recipient.	
-I<size>	No equivalent.	
-L[acnsy]
-MR
-MS	Logging is now controlled in the Administrator Program.
Set in the Diagnostic Logging property page.
Set in the Diagnostic Logging property page.	
-MD	No longer needed.	
-O<size>	Set in the General property page.	
-Qnnn	Set in the General property page.	
-P0nn	No longer needed.	
-RE	No longer needed.	
-RR		
-T		
-V20	No longer needed.	
-Wnnn	Set in the Connections property page.	
-X	No longer needed.	

Migrating from an X.400 Gateway to an X.400 Connector

The Microsoft Exchange Server MTA can be used to replace an existing Microsoft Mail (PC) X.400 gateway. Users of Microsoft Mail for PC and AppleTalk networks can take advantage of the X.400 Connector. The following requirements must be met before you can migrate from the Microsoft Mail X.400 gateway to the Microsoft Exchange Server MTA:
	Mail addressed with the global address list and sent between Microsoft Mail postoffices and Microsoft Exchange Server computers is routed and delivered without any problems. The easiest way to do this is to connect the two systems with the Microsoft Mail Connector, but any connection method can be used.
	All Microsoft Mail mailboxes that will send or receive mail through the X.400 MTA and want something other than a default address must be in the Microsoft Exchange Server global address list as custom recipients. The easiest way to do this is to configure directory synchronization and wait for the custom recipients to be created.
	The X.400 Connector is configured and tested on a server in any site in the organization. Mail sent from Microsoft Exchange Server mailboxes is delivered to the X.400 system. Do not configure the connector to accept all incoming mail from your private management domain (PRMD) at this time. Just set up a narrow address space for testing.
	All Microsoft Mail postoffices must have access components for the X.400 gateway.

After these conditions have been met, make adjustments to addressing and routing before the gateway is shut down and the use of the gateway is migrated. This process depends on your configuration.
Addressing Schemes
How you migrate to using the X.400 MTA depends on how you were using the X.400 gateway and how you plan to use the X.400 MTA. Every Microsoft Exchange Server recipient has one X.400 e-mail address. This address can be replaced or supplemented with other X.400 e-mail addresses. You should configure the site’s X.400 addressing system before beginning to migrate mailboxes. The following table summarizes the four possible approaches.
Addressing  configured with an X.400 gateway	Addressing configured with an X.400 MTA	Method	
			
Customized address maps and/or conversion strings.	Switch to default for site.	Switch address convention.	
Customized address maps.	Preserve addresses for migrated users.	Maintain mapped addresses.	
Address conversion strings.	Preserve addresses for migrated users.	Maintain conversion string addresses.	
Mixture of customized address maps and address conversion strings.	Preserve addresses for migrated users.	Maintain mixed addresses.	

One common strategy that the last three methods share is how to handle multiple X.400 addresses for one mailbox. The X.400 gateway supported this feature by having address mapping tables to convert X.400 addresses to Microsoft Mail addresses. The Microsoft Exchange Server MTA does not convert addresses; it looks them up in the directory. Since each recipient can have multiple X.400 type addresses, the Microsoft Exchange Server directory needs all the X.400 addresses for each recipient.
Maintaining Internal Address Conventions
By default, the X.400 gateway creates addresses for all Microsoft Mail mailboxes based on their network, postoffice, and mailbox names. You retain those addresses and migrate to the X.400 Connector by updating the e-mail addresses for the custom recipients and mailboxes in Microsoft Exchange Server with directory import. You need to update all the custom recipients after directory synchronization is completed the first time. If you don’t replace custom recipients with mailboxes, you must update every mailbox as it is created on a Microsoft Exchange Server. If you ever change the site’s e-mail addressing properties, update all the mailboxes in the site.
	To create the import file for modifying all the custom recipients
	1.	Create a text file with this header:
Obj-Class,Common-Name,Target-Address,Proxy-Addresses

	2.	Use the Directory Export command to export custom recipients to the text file.
	3.	Modify the proxy-addresses field based on the target-address field without changing SMTP and other address types. This can be done with a macro or a custom program.

Important
Microsoft Excel and other spreadsheet programs have a 256-character limit per cell. The proxy-addresses field can have more than 256 characters. Do not import the directory export file into Microsoft Excel or any other spreadsheet with this limitation because any characters beyond the first 256 are truncated and lost without warning. Use a database program such as Microsoft Access or Microsoft Visual FoxPro to get around this limitation.

	4.	Save the modified file in CSV format.
	5.	If the modified file’s proxy-addresses field contains all the e-mail addresses for the recipient, use directory import with the Overwrite option selected in the Directory Import dialog box.
– or –
If the modified file’s proxy-addresses field contains just the new X.400 e-mail address for the recipient, use directory import with the Append option selected in the Directory Import dialog box.

As mailboxes are migrated from Microsoft Mail postoffices, the custom recipient for the mailbox is removed, and a mailbox is created. If you have this configured to replace the custom recipients with mailboxes, the e-mail addresses are preserved. 
Otherwise, the mailboxes should have their e-mail address updated as they are created or immediately thereafter. This can be done as part of the migration user list file or as a separate directory import file. To get the correct e-mail addresses, use directory export to create a file of custom recipients and their correct e-mail addresses before you begin to migrate mailboxes. 
Switching Address Conventions
You can change to a company standard naming convention for your X.400 addresses as part of migrating to Microsoft Exchange Server. Your users that receive mail with their current X.400 address need to let their correspondents know their new address. The address is created based on the structure you define in the Site Addressing property page.
This is the easiest way to handle addressing conversion. The X.400 MTA has a connector configured to your administrative management domain (ADMD), and the X.400 gateway is brought down. All the postoffices that need to route X.400 mail a different way have their indirect access component reinstalled to route mail to the Microsoft Exchange Connector postoffice. Send a message containing new address information to each Microsoft Mail user once the conversion is complete.
X.400 users who cannot receive mail that is returned as undeliverable as a result of the address change can have secondary e-mail addresses created for them using their old address.
Coexistence with the AT&T® Gateway and the 
Internet Mail Connector
Microsoft Mail for PC Networks versions 3.2 and 3.5 included the AT&T® gateway. The following table presents some ways to configure coexistence during migration.
Gateways and Connectors	Approach	Results	
			
AT&T only	Install access component on Microsoft Exchange Connector postoffice. Set address space to SMTP.	Microsoft Exchange Server and Microsoft Mail (PC) mailboxes can send and receive mail through the gateway.	
AT&T and Internet 
Mail Connector	Install access component on Microsoft Exchange Connector postoffice. Set in the General property page. Set address space for AT&T to SMTP with a cost of 100. Set address space on Internet Mail Connector to SMTP:*@* with a cost of 0.	Microsoft Exchange Server and Microsoft Mail (PC) mailboxes can send and receive mail through the AT&T gateway. Microsoft Mail (PC) users can only receive mail from the Internet Mail Connector.	
AT&T version 1.1 and SMTP with address 
preprocessor	Install access component on MS Mail Connector postoffice. Set address space in Microsoft Exchange server for connector to SMTP.	Microsoft Exchange Server and Microsoft Mail (PC) mailboxes can send and receive mail through both gateways.	
Internet Mail Connector, AT&T, and SMTP with address preprocessor	Install access component on Microsoft Exchange Connector postoffice. Set address space for AT&T to SMTP with a cost of 100. Set address space on Internet Mail Connector to SMTP:*@* with a cost of 0.	Microsoft Exchange Server and Microsoft Mail (PC) mailboxes can send and receive mail through the AT&T gateway. Microsoft Mail (PC) users can send mail out through the SMTP gateway and receive mail from the SMTP gateway or Internet Mail Connector. Microsoft Exchange server users can mail out the Internet Mail Connector and receive mail from the SMTP gateway or the Internet Mail Connector.	

Depending on the approach you take, you might need to examine preserving addresses for migrated mailboxes.
Groups and Distribution Lists
Microsoft Mail (PC) supports groups in two ways:
	Groups with only local members
	Groups that span postoffices

Groups that are composed of local users can be included in directory synchronization. The Migration Wizard doesn’t migrate these groups. Any time after directory synchronization is configured between the organization and the Microsoft Mail PC postoffices, it is possible for you to move the groups. During migration, move these groups when one of the users in the group is migrated. Once users in this group are migrated, the group spans postoffices.
Groups that span postoffices have three limitations. First, all members of the group that do not belong to the postoffice must have their address added to the postoffice address list. Second, mail sent from one postoffice to a mixed-member group on another postoffice is delivered only to the local members of the group. For this reason, groups that span postoffices must either be created on all postoffices or must not be visible to users at other postoffices. Third, groups that span postoffices are not included in directory synchronization. It is assumed that if your organization has groups that span postoffices, you have created each of them on every postoffice. 
Microsoft Exchange Server distribution lists do not have any of the limitations of Microsoft Mail (PC) groups. For this reason, groups that span postoffices should be replaced with Microsoft Exchange Server distribution lists as soon as possible. The following are some of the advantages Microsoft Exchange Server distribution lists have over Microsoft Mail (PC) groups.
Issue	Microsoft Exchange Server DL	Microsoft Mail (PC) group	
			
Finding group membership	You can view a group, custom recipient, or mailbox and see their members or membership in groups respectively. You can do this with directory export once from any server in any site as well.	You can view a group to find its members. You can also print a group list from every postoffice and search for group membership.	
Maintenance during migration	Maintenance is automatic if custom recipients are replaced with mailboxes. Otherwise, you can remove custom recipients and add mailboxes with the Administrator program or in a batch method with the Directory Import command.	You must add the migrated mailbox to the postoffice address list and modify each group the user belongs to on every postoffice. This cannot be done in a batch method.	
Day-to-day maintenance	You can add or remove mailboxes as needed from the mailbox or distribution list property pages or in a batch method with the Directory Import command.	You must add users to the postoffice list and to the group on every postoffice or add them to a local group. This cannot be done in a batch method.	
Delivery	If the message is sent from Microsoft Exchange Server, the distribution list is expanded to its membership and delivered. If the message is sent from Microsoft Mail (PC), it must be moved to a Microsoft Exchange Server The distribution list is expanded, and the message is redirected to Microsoft Mail (PC).	If the message is sent from Microsoft Mail (PC), the group is expanded to its members and delivered. The group is not included in directory synchronization. The group can be added to Microsoft Exchange Server as a custom recipient with the Administrator program or directory import. If so added, a message sent from Microsoft Exchange Server must be delivered to the postoffice of the group. It will then be delivered only to local members of that group.	
Details in directory	All users in Microsoft Exchange Server can see the group membership. Microsoft Mail (PC) users cannot see group members.	All users on the postoffice where the group is created can see the group membership, as long as it does not contain local groups from other postoffices. Microsoft Exchange Server users cannot see details.	
Nested groups	Microsoft Exchange Server supports 
multilayer nested groups.	Microsoft Mail (PC) can support local groups of other postoffices only.	

The group information in an MS Mail postoffice can be printed by choosing Local-Admin:Group:Print in the Administrator program. This produces a file with display names, which may or may not be the same as the real display names if the user is on another postoffice. This file can be converted to directory import format. An alternative is to remove groups on the postoffices before migration begins and create distribution lists in Microsoft Exchange Server after migration is complete.
File Format API Applications
If you have applications or gateways created with the File Format API (FFAPI), they will continue to work with Microsoft Exchange Server. You need to plan what to do with them when all of your postoffices have been migrated to Microsoft Exchange Server. The Connector postoffice can be considered to be just like any Microsoft Mail 3.2 postoffice for purposes of FFAPI applications and gateways. 

Important
You need to use the -md switch on FFAPI to disable the mailer. If you don’t disable the mailer, mail going through the Connector postoffice may be returned as undeliverable.

After all postoffices are migrated to Microsoft Exchange Server computers, the FFAPI applications can continue to be used with the Connector postoffices as long as the Microsoft Mail Connector interchange and MTA services continue to run. Contact the application vendor to see if they have native Microsoft Exchange Server applications.
Custom Commands, Menus, and Message Types
Custom command entries in the MSMAIL.INI and SHARED.INI are used by Windows for Workgroups, Windows NT, and Windows 95 Microsoft Exchange Server clients as they are for a Microsoft Mail (PC) Windows client. The format is the same, and no changes must be made to menus or custom forms commands.
Extensions were implemented in Mail 3.x (16 bit), Mail 3.x for Windows for Workgroups (16 bit), and Mail 3.x for Windows NT (32 bit). Microsoft Exchange Client for Windows for Workgroups supports 16-bit extensions only. Microsoft Exchange Client for Windows 95, Windows 95 upgrade, and Windows NT support both 16-bit and 32-bit extensions.
Custom Menus
Custom menu extensions allow users to add top-level menus to the Microsoft Mail 3.x client. This feature is fully supported in Microsoft Exchange Client. A Tools menu is not available by default with Mail 3.x but is commonly added using custom menu extensions. Microsoft Exchange Client uses its native Tools menu in place of creating a second Tools menu. Therefore, custom menus with the tag 'Tools' in the [Custom Menus] section of the .INI file are ignored.
Custom Commands
Custom command extensions allow users to add new commands to the Microsoft Mail 3.x client. This feature is fully supported by Microsoft Exchange Server, although there are a few extensions that are not compatible.
Because the menus in Microsoft Exchange Server and Microsoft Mail 3.x differ, special handling of command extensions is necessary. When a command extension is to be added to the Microsoft Mail 3.x Mail menu, Microsoft Exchange Server adds it to its Compose menu. If a custom command is to be added to a Microsoft Mail 3.x Tools custom menu or Windows menu, Microsoft Exchange Server adds it to its Tools menu.
To provide compatibility, there are essentially two different types of command extensions.
	APPEXEC.DLL/APPXEC32.DLL
	Other extension DLLs including MEFLIB.DLL
Microsoft Exchange Server 16-bit Client With 16-bit Extension Support
Compatibility with the 16-bit Microsoft Exchange Client is quite straightforward because Microsoft Mail 3.x is a 16-bit application. On the Microsoft Exchange Windows 3.x client, APPEXEC is supported; and other extension DLLs are called directly as they were in Microsoft Mail 3.x.
Microsoft Exchange 32-bit Client With16-bit 
Extension Support
Compatibility with 32-bit Microsoft Exchange Clients (Windows 95 and Windows NT) is more complicated because the majority of extensions are 16-bit DLLs and cannot be called directly by 32-bit applications. Microsoft Exchange 32-bit clients support both 16-bit and 32-bit extensions.
Microsoft Exchange 32-bit clients cannot directly call 16-bit extension DLLs; therefore, a 16-bit proxy (ML3XEC16.EXE) is used for 16-bit extension DLLs. When a 16-bit extension needs to be called, a Microsoft Exchange 32-bit client launches ML3XEC16.EXE and passes it to the parameter block pointer and the name and path of the extension DLL. ML3XEC16.EXE then calls the DLL and passes it the parameter block pointer.
Microsoft Exchange 32-bit Client With 32-bit Extension Support
APPXEC32.DLL is supported as explained in a later section; and other extension DLLs are called directly as they were in Microsoft Mail 3.x.
MSMAIL[32].INI and SHARED[32].INI PARSING
Microsoft Exchange Server supports 16-bit and 32-bit extensions to make migrating from Microsoft Mail 3.x for Windows and Windows NT easy. The extensions that are loaded are determined by which .INI files are read during Microsoft Exchange Server startup.
Microsoft Exchange 16-bit Client
The Microsoft Exchange 16-bit Client is strictly an upgrade from Microsoft Mail 3.x; therefore, it does not support 32-bit extensions. It reads MSMAIL.INI and SHARED.INI in the same way as Microsoft Mail 3.x does. It searches the [Options] section of EXCHNG.INI for SharedExtsDir, SharedExtsServer, and SharedExtsPassword. If found, an anonymous connection to the server is made with the provided password if required and searches for the SHARED.INI file in the directory specified by SharedExtsDir.
The Microsoft Exchange 16-bit Client searches the MSMAIL.INI file for a SharedExtensionsDir entry. If found, Microsoft Exchange searches for the SHARED.INI file in the directory indicated by SharedExtensionsDir. Microsoft Exchange 16-bit Client never looks for MSMAIL32.INI or SHARED32.INI. If a SHARED.INI is found, Microsoft Exchange Server reads the extension entries specified in the [Custom Menus], [Custom Commands], and [Custom Messages] sections.
The 16-bit Client then reads the extension entries ([Custom Menus], [Custom Commands], and [Custom Messages] sections) specified in the MSMAIL.INI file. It ignores any extension entries whose version parameter is appended with a ',32' (for example, '3.0,32') because these are supported only by Microsoft Exchange 32-bit Clients. 
Microsoft Exchange 32-bit Client
Installing Microsoft Mail 3.x extensions on Microsoft Exchange 32-bit Clients is more complicated because the vast majority of installed extensions are for 16-bit Microsoft Mail 3.x, but 32-bit extensions for Microsoft Mail 3.x for Windows NT must also be supported. During Microsoft Exchange 32-bit Client startup, Microsoft Exchange (for both Windows NT and Windows 95) looks for extensions registered in HKEY_CURRENT_USER\Software\Microsoft\mail\microsoft mail. This is the location where extensions for MS Mail for Windows NT are installed. To be consistent across 32-bit platforms, this registry is also used on Microsoft Exchange for Windows 95.
The 32-bit Client looks in the registry for a SharedExtsDir entry under HKEY_CURRENT_USER\Software\ Microsoft\Exchange\Client\Options. If there, it also gets the SharedExtsServer and SharedExtsPassword entries. If not there, it looks in MSMAIL32.INI (which maps into the registry on Windows NT) for the Microsoft Mail 3.x SharedExtensionsDir entry. If not found, it uses MSMAIL.INI to look for the SharedExtensionsDir. If a SharedExtensionsDir entry is found, it is parsed into Microsoft Exchange Server equivalents. An anonymous connection to the server is made with the provided password if required.
The Microsoft Exchange 32-bit Client then looks in the shared directory for a SHARED32.INI. If found, it does not look for SHARED.INI. Next, it reads extensions [Custom Menus], [Custom Commands], and [Custom Messages] sections) from the SHARED32.INI if found previously.
It then reads extensions from MSMAIL32.INI. If SHARED32.INI wasn’t found, Microsoft Exchange 32 bit Client looks for SHARED.INI in the same location. Microsoft Exchange 32-bit Client then reads the MSMAIL.INI.
Microsoft Exchange Server supports an enhancement to the version parameter of the extension registration entry. The version number can be followed by a ',16' to indicate a 16-bit extension DLL or by ',32' to indicate a 32-bit extension DLL. If the version does not specify either of these settings, Microsoft Exchange Server assumes that the bits of the extension matches the bits corresponding to the file name. For example, MSMAIL32.INI -> 32 bits, SHARED.INI -> 16 bits. Specifying the bits of the extension in the version number results in a syntax error if read by Microsoft Mail 3.x for either Windows for Workgroups or Windows NT.
Custom Message Types
Custom message handlers allow for custom forms to be used in place of the standard mail send note. They also allow for messaging-based applications to send and receive messages. Microsoft Exchange Server provides complete support for custom message types.
Electronic Forms Designer (EFD) 1.0 Forms
If you have developed and installed electronic forms created with the Microsoft Electronic Forms Designer (EFD) version 1.0, you can continue to use those forms. Unmodified electronic forms will run on Windows 95, Windows 3.1, Windows for Workgroups, and Windows NT.
During migration, if you want to create one form to be used on both systems, create the form with the Microsoft Mail Electronic Forms Designer. Once all users are migrated to Microsoft Exchange Server, use Microsoft Exchange Server forms exclusively.

Note
There are no tools available to convert Microsoft Mail custom form 1.0 projects to Microsoft Exchange Server form projects. 

Sample forms include a variable named 'index' which is now a reserved keyword under Microsoft Visual Basic version 4. Developers recompiling under this version must rename the declaration and all uses of this variable.
Form Browser
The form browser for EFD is used to select a form to compose. The browser is actually a 16-bit program launched by MEFLIB.DLL as a custom command. The form browser is fully supported in Microsoft Exchange Server provided that the [custom messages] is registered in MSMAIL.INI or SHARED.INI and not the 32-bit counterparts. This is a requirement because the form browser was developed for 16-bit Microsoft Mail 3.x and is not aware of 32-bit forms or 16-bit forms registered in MSMAIL32.INI or SHARED32.INI.
MEFLIB.DLL and EFD on Windows NT
EFD does not work automatically on Windows NT because a 32-bit MEFLIB32.DLL does not exist. MEFLIB.DLL is included with the Microsoft Exchange Client. It is not part of the Windows 95 base client, but it is part of the upgraded Microsoft Exchange Server Windows 95 client. The new MEFLIB.DLL replaces the MEFLIB.DLL installed with forms runtimes.

Note
 If you are using EFD with the Windows 95 base client, you can install the MEFLIB.DLL by running the EFD runtime installer.

APPEXEC.DLL/APPXEC32.DLL
APPXEC32.DLL is used in Microsoft Mail 3.x custom commands to launch an executable file from a custom command with a list of command-line parameters. This is a frequently used extension. APPEXEC.DLL (16 bit) is used with Microsoft Mail 3.x for Windows for Workgroups. APPXEC32.DLL (32 bit) is used with Microsoft Mail 3.x for Windows NT. The Microsoft Exchange 16-bit Client supports APPEXEC.DLL. The Microsoft Exchange 32-bit Client supports both DLLs.
Remote Users and Offices
Windows remote client users who upgrade to the Microsoft Exchange Client can migrate their MMF to a personal folder file. Users of the MS-DOS remote client have no way to migrate their messages to a PST. They must forward them to themselves or print them to a printer or file if they want to preserve the information.
The Microsoft Exchange Clients with either the MS Mail information service or the Microsoft Exchange information service connect to retrieve mail using a method that is different from the MS Mail remote clients. Before migrating remote client users to the new client, you need to install, configure, and test the new connection method.
Hardware requirements for Microsoft Exchange Clients are greater than for Microsoft Mail clients. When planning migration, inventory remote client users to see if any of them need hardware upgrades.
As offices in one location migrate to Microsoft Exchange Server, remote offices can continue to connect with asynchronous and X.25 connections to the Microsoft Mail Connector (PC) MTA.
When remote offices migrate, work with them on naming conventions, directory replication, connections between sites, routing, public folders, and security. After they install a server and connect their server with your site, they can configure a Microsoft Mail Connector to communicate with the rest of their postoffices and bring down the asynchronous or X.25 external connection to your Microsoft Mail Connector (PC) MTA. This has to be a coordinated effort because you must change routing to their address spaces when the transition is made. 
Template Information
If you use template information in Microsoft Mail, the postoffice migration tool does not migrate that information to the directory of Microsoft Exchange Server mailboxes. If you want to migrate data, there are three methods: 
	Use directory synchronization with directory export and import.
	Use directory synchronization with custom recipient conversion.
	Export the data from the postoffice, convert the format, and import.

Choices you make for directory synchronization and how you are migrating users can limit which method you choose. For example, the first two options won’t work for single-phase migration unless you set up the MS Mail Connector and directory synchronization first. For more information on directory synchronization and the Directory Import and Directory Export commands, see the Microsoft Exchange Server Administrator’s Guide.
	To migrate with directory synchronization and export and import
	1.	Configure directory synchronization to send template data.
	2.	Before mailbox migration use the Directory Export command to export this data to an existing file with a header which specifies obj-class, common-name, and all the template-type fields.
	3.	Use the Migration Wizard to migrate the mailboxes from Microsoft Mail to Microsoft Exchange Server.
	4.	In the exported data, change the obj-class field from remote to mailbox. Add the mode column and set the value to modify.
 	5.	Use the Directory Import command to import the modified template data file. This modifies the newly created mailboxes with the template information.

	To migrate with directory synchronization and custom recipient conversion
	1.	Configure directory synchronization to send template data.
	2.	Use the Migration Wizard to migrate the mailboxes from Microsoft Mail to Microsoft Exchange Server.

	To migrate template information by converting the format
	1.	Use the Template utility in Microsoft Mail (PC) to convert the ADMIN.INF file which holds encrypted template information into an unencrypted text file called ADMIN.TXT. Convert to Directory Import format manually or with a macro or a custom program.
	2.	Use the Migration Wizard to migrate the mailboxes from Microsoft Mail to Microsoft Exchange Server.
	3.	Use the Directory Import command to import the converted template data file. 
This modifies the newly created mailboxes with the template information.

Mail Message Files
The mail message files (MMFs) store mail, attachments, and PABs for users of the Windows and OS/2® clients for Microsoft Mail (PC) 3.x. The MMFs can be stored in the postoffice share in the MMF directory, or they can be moved to another location by the client.
If the MMF for a mailbox is on the postoffice, it is migrated by the Migration Wizard to a Microsoft Exchange Server private information store. The PAB data is extracted and sent to the new mailbox. The MMF is not deleted and can be archived as a backup.

Important
If the MMF is copied to the correct directory in the postoffice and has the correct name, the Migration Wizard migrates it. If the user has already imported the messages into a Personal Information Store file, this could lead to duplicate mail.

If the MMF for a mailbox is on the workstation or stored on a server, the user migrates the contents. The Windows 95 Setup program, the Import command on the File menu in the Microsoft Exchange Client, or the Profile Wizard all attempt to migrate the MMF information to a PST file, private information store, or a default store and a PAB file. 
If the user has used multiple information services (such as AT&T, MHS, or CompuServe®) with this MMF, there may be multiple PABs in the MMF. If the MMF is migrated with the Profile Wizard or the Migration Wizard, all the PABs are migrated. If the MMF is migrated with the Import command, the user can choose which PABs to migrate.
	To import an MMF file with the Windows clients
	1.	From the File menu, choose Import.
	2.	In the Specify File to Import dialog box, select the MMF file.
	3.	In the Import Mail Data dialog box, type the password for this MMF file. 
	4.	Select Import Messages to import all messages and folders.
	5.	Select Import Personal Address Book Entries to create a Microsoft Exchange PAB file.
	6.	Choose OK.

The following table describes the options for MMF file location.
Location of MMF files	Benefits	Drawbacks	
			
Users can move MMFs to the postoffice.	MMFs can be purged of old information with MMFClean before migration.
Data is migrated with the Migration Wizard.
Reduces the burden on the Help Desk the day after migration.	Can add to the time the Migration Wizard needs to migrate the MMF.
Administrator can’t reset mailbox password until after MMF is migrated.
Users must import their PAB entries.
Space on the server for the postoffice could be insufficient.	
Users can move MMFs to local storage.	Migration Wizard can migrate the postoffice quickly.

Migration of the postoffice won’t log errors due to corrupt MMFs.	Adds extra burden on the users and Help Desk to support users migrating their own MMFs.
Prevents you from purging locally stored information .	
Users of the Microsoft Exchange Client with the MS Mail information service must move personal folder files to local storage.	Personal folder files do not need to be migrated.		

When migrating MMFs, keep the following points in mind:
Network errors
If there is a network failure during MMF migration, the client or Migration Wizard retries the network connection 4 times in the next 2 seconds, and then repeats these multiple retries every 10 minutes. An error message is displayed during the 10 minute retry time.
Error log
Any errors during client MMF migration are logged to a file in the client directory with the same file name as the MMF name and an extension of .LOG. You can view the log in Notepad or any other text editor.

Personal Address Books and Lists
Personal address books (PABs) are copied to Microsoft Exchange PAB files during migration. The PAB file is imported in a message to the new mailbox’s inbox. The PAB entries for users on foreign mail systems, such as SMTP, FAX, and X.400, will be valid. Any message addressed to these entries will be delivered as long as the mailbox’s site has a way to route the message. 
The PAB entries for PROFS and SNADS users will be migrated but will not be accurate. In MS Mail (PC), these addresses are stored in the format of <gateway>\node\user. Microsoft Exchange Server is expecting these addresses to be in the form of node\user, with the appropriate type information. The entries need to be modified before they can be used.
The entries of type MS will be routed to the Microsoft Mail Connector. If the address is to a mailbox that has been migrated to Microsoft Exchange Server, the message will be returned as undeliverable. If the address is to a mailbox that has not migrated yet, it will function normally until the mailbox is migrated. Changes in the Microsoft Exchange Server global address list do not update user’s PAB file entries.
If the MMF file is not on the postoffice, the personal address book entries are migrated from MMF files to a Microsoft Exchange PAB file when the MMF file is migrated to a PST file. This happens when the users upgrade their Windows 95 client or run the Profile Wizard after client Setup.
If MMF is on a server, the PAB entries are copied from the MMF file to a Microsoft Exchange PAB. The PAB file is attached to a message which is migrated into the user’s Microsoft Exchange mailbox. The message text explains how to save the PAB file and import it into the existing PAB. You can customize the text of this message as needed by modifying the PABMSG.TXT file in the EXCHSRVR\BIN directory.
Personal address lists (PALs) used by the MS-DOS and Apple Macintosh clients are not migrated. Personal groups in the PAB get migrated to personal distribution lists in the Microsoft Exchange PAB.
Shared and Group Folders to Public Folders
The postoffice migration tool copies shared and group folders. The folders are copied to the public folder store, and appropriate permissions are assigned to them as specified in the Migration Wizard. These folders should be migrated no more than once per postoffice.
After a copy has been migrated to a public folder on the Microsoft Exchange Server, there is no way to automatically replicate the differences between the two folders on Microsoft Mail and Microsoft Exchange Server. If you have a critical shared or group folder, migrate all the folder’s users at the same time.
Private Folders
Private folders created by the MS-DOS and Macintosh clients can be stored either on the postoffice or moved to local storage by the client. If they are moved to another location by the client, they must be moved back to the postoffice to be migrated. This can be done only from the client computers, not from the Administrator program.

Note
If the private folders are not moved to the postoffice before migration, the data in them is difficult to migrate. 

Before migrating mailboxes to Microsoft Exchange Server, you can use the Microsoft Mail Administrator program to determine if any of the users have moved their private folders to local storage. To view the location of private folders, choose Local Admin-Folders-Status. Advise the users to move the folders back to the server by selecting the appropriate command. In the MS-DOS client, choose Options-Folders-Private Storage-Server. In the Macintosh client, select Private Folders in the Microsoft Mail window, choose Get Info from the File menu, and set the location to server.
The main problem with moving private folders from local storage to the postoffice is that the private folders may require more space than your postoffice’s share or volume has available, and the user could run up against an owned space limitation on a Novell® NetWare® server when space limitations are used. You can reduce this by requesting users to delete mail and attachments in folders that are no longer available and using the FOLDCOMP.EXE utility to remove unused space from the private folders and reduce the file size.
Macintosh users can compress their folders by selecting them in the Private Folders window, choosing Get Info from the File menu, and selecting the Compress button in the Info dialog box. Or, after they move their folders back to the postoffice, you can recover unused space by compacting private folders with the Microsoft Mail Administrator program or with FOLDCOMP.
MS-DOS Client Messages
The MS-DOS client for Microsoft Mail (PC) can format messages with different color text and background. This formatting information is not preserved when the messages are migrated. 
Schedule+ Messages and Calendars
Migrate Schedule+ messages with the MMF file. Calendars are migrated the first time users use the new Schedule+. The new Schedule+ looks for the local copy of the CAL file. 
You can also use the Migration Wizard to migrate calendars. The migrated data is put in the mailbox’s server calendar in Schedule+ 1.0 format. This data is converted to Schedule+7.0 format the first time the calendar is opened. This is helpful to users who accidentally delete their local copy of the calendar file and to resource accounts that don’t have a local copy of the calendar file. 
Coexistence During Migration
The most important elements of coexistence are mail connectivity and directory synchronization. Microsoft Exchange Server includes features to make this easy.
Connectivity
There are many options for connecting Microsoft Exchange Server computers with Microsoft Mail postoffices.
Situation	Solution	Impact	
			
Both on a LAN or WAN	MS Mail connector, LAN option	None	
Remote location, currently connected asynchronously	MS Mail connector, async option	None	
Remote location, currently connected over the Internet with SMTP gateway	Replace the SMTP gateway with Internet Mail Connector in the Microsoft Exchange Server site	Update address space on Internet Mail Connector to include remote postoffices	
Remote location currently connected over AT&T with the AT&T gateway	Replace the AT&T gateway with the Internet Mail Connector in the Microsoft Exchange Server site or move the AT&T gateway to the Connector postoffice	Reconfigure the postoffice/AT&T gateway	
Currently backboned over PROFS	Move the PROFS gateway to the Connector postoffice, or install Attachmate’s ZIP Office Exchange Gateway.		

Directory Synchronization
Directory synchronization is important because the directory has major changes made to it with each phase of migration. If directory synchronization is planned, it can prevent undeliverable mail (except for mail addressed from PABs and PALS). You have several options:
	Add Microsoft Exchange Server sites as requestor postoffices.
	Reconfigure directory synchronization to point to one or more Microsoft Exchange Server sites.
	Migrate the directory synchronization postoffice first and have Microsoft Exchange Server handle the synchronization process.
	Move a postoffice each day or week to a directory synchronization server and have a server in the site act as a requestor.
	Reconfigure directory synchronization on a site-by-site basis to make upgrading custom recipients to mailboxes easier.

The first option takes the least amount of time to configure. The directory synchronization server postoffice adds the Microsoft Exchange Server site as a requestor postoffice. You create a directory exchange requestor in your enterprise and configure it.
All options except for the first require administration on all postoffices that currently participate in directory synchronization. The benefit from this choice is having the directory synchronization server processes running on the Microsoft Exchange Server. The advantages include:
	Multithreaded support.
	Windows NT memory management.
	Data is local to the process; no files are read over the network. This reduces network traffic and makes the T-2 process time smaller.
	Updates are processed as they are received, not in one big batch, reducing the T-2 process time to sending updates. This can dramatically impact the speed of the directory synchronization process.

The third option combines the ease of the first option with the reliability of Windows NT from the second option. However, proper planning is required. When the first server is installed in the site, the local postoffice name is changed in the connector to match the name of the directory synchronization server.
The users on the directory synchronization server postoffice are migrated to Microsoft Exchange Server or moved to other servers with the Move User utility. This happens after T3 but before T1 in the directory synchronization process.
For MS Mail (PC) postoffices, there are no routing or addressing changes. Every postoffice must send a full list of addresses and request a full list of addresses using the Config-Dir-Sync-Requestor Import and Export commands in the Microsoft Mail Administrator program. The External program INI files have to be updated so MS Mail (PC) externals and MTAs don’t deliver mail to the old postoffice. All mail sent to migrated users is delivered to their new Microsoft Exchange Server mailboxes. No configuration changes for directory synchronization are needed on any of the postoffices except to export and import addresses.
The order and planning of how you handle migration of the directory synchronization server to Microsoft Exchange Server is important. Part of migration is maintaining the global address list in postoffices and Microsoft Exchange Server computers as accurately as possible.
Consider the following:
	When do you want mail delivered to the new mailbox instead of the old one?
	Do you want to remove the old mailbox from directory synchronization or delete it?
	When do changes in the postoffice need to be sent for directory synchronization?
	How soon after migration does the user begin using Microsoft Exchange Server instead of Microsoft Mail?
	Does your directory synchronization plan consider upgrading custom recipients to mailboxes?

There are several ways to plan directory synchronization. You can:
	Maintain your current setup, and add Microsoft Exchange Server as one requestor.
	Maintain your current setup, and add each site as one requestor.
	Designate each site as a directory synchronization server.
	Designate one site as a directory synchronization server.

As mailboxes are migrated during phased migration, they need to be removed from directory synchronization. If you are migrating an entire postoffice, the directory synchronization server removes the postoffice during the process. If you are migrating a partial postoffice and deleting migrated mailboxes, deleting the mailbox removes it from directory synchronization. If you are migrating a partial postoffice and retaining the migrated mailboxes, you must mark the mailbox as not included in directory synchronization using the Local command on the Modify menu in the MS Mail (PC) Administrator program.
Schedule+
The Microsoft Exchange Client includes a new version of Schedule+. During coexistence there can be times when people in your organization will be using both the new and the old version. Most of both version’s features are compatible, but if you upgrade Microsoft Mail users to the Microsoft Exchange Client with the MS Mail information service, these users must use Schedule+ version 7.0. The extra features of this version should be a factor when considering using the MS Mail information service with your existing postoffices.

Sender on postoffice with version 1.0	
Sender on postoffice with version 7.0	Sender on Microsoft Exchange Server with version 7.0	
				
Other person on postoffice with version 1.0	There is existing functionality.	Attachments sent with meeting request are unavailable to other person.
You can’t give other person access privileges to schedule file.
You can't designate other person as a delegate.
You can access other person’s calendar if given permission.
You can see free/busy with permission.	Attachments sent with meeting request are unavailable to other person.
You can’t give other person access privileges to schedule.
You can’t designate other person as a delegate.
You can’t access other person’s calendar.

You can see free/busy with permission if Schedist and Free/Busy gateway configured.	
Other person on postoffice with version 7.0	You can give other person access privileges to schedule file.
You can’t designate other person as a delegate.
You can’t access other person’s calendar.
You can’t see free/busy information.	Existing functionality plus some new features:
- You can send attachments with meeting requests
- You can have multiple delegates, as long as they are on the same version, and are on the same postoffice
- Time zone support
- New views, contacts	Attachments sent with meeting request are available to other person.
You can’t give other person access privileges to schedule.
You can’t designate other person as a delegate.
You can’t access other person’s calendar.
You can see free/busy with permission if Schedist and Free/Busy gateway configured.	
Recipient or other on Microsoft Exchange server with version 7.0	You can’t give other person access privileges to schedule.
You can’t designate other person as delegate.
You can’t access other person’s calendar.
You can see free/busy with permission if Schedist and Free/Busy gateway configured.	Attachments sent with meeting request are available to other person.
You can’t give other person access privileges to schedule.
You can’t designate other person as a delegate.
You can’t access other person’s calendar.
You can see free/busy with permission if Schedist and Free/Busy gateway configured.	There is complete functionality.	

Schedule+ meeting requests and confirmations are translated between the two versions, with the exception of attachments, which version 1.0 does not support. 
Migration Tools
The Migration Wizard includes the extractor for Microsoft Mail for PC Networks. The steps to the process are:
	(Optional) Use the Migration Wizard to create a user list.
	(Optional) Modify the user list as needed.
	Use the Migration Wizard to create mailboxes and migrate messages and attachments.

It is difficult to predict how long it will take to migrate any postoffice, even if you know how many messages are involved. During testing, migrate five average users to get a rough time estimate. For best performance, run the Migration Wizard on the directory server, and migrate mailboxes to that server.

Note
Every postoffice has two special accounts that aren’t migrated like the others. In the default administrator account, ADMIN, the directory name changes to match the postoffice name so that multiple administrator accounts aren’t migrated into one mailbox. The other special account, Schedule+ administrator, ADMINSCH, is not migrated.

Before migrating mailboxes, you must prepare the server and the postoffice, both of which should not be used by anyone during migration. A complete copy of the postoffice can be made to the Microsoft Exchange Server hard drive if you are moving only a few users and don’t want to interfere with the normal operations of the postoffice. This can also decrease migration time by having all the data local instead of reading it across the network.
Before moving users:
	Compare disk space to postoffice volume.
The server should have at least twice as much space as the postoffice volume. If free disk space is less than twice the postoffice volume, check the available space with the Performance Monitor during the process. Stop migration if there is less than 5 MB of disk space available.
	Back up the Microsoft Exchange Server information store and directory.
	Modify the PABMSG.TXT, if necessary.
The Migration Wizard has three ways to migrate MS Mail (PC) mailboxes and data:
	One-Step - Information is extracted from the postoffice and immediately imported into the Microsoft Exchange Server.
	Two-Step - On the first step, the Migration Wizard creates a user list file. The file can be edited, then used in the second step. This is typically used to make changes to the common name of the mailboxes, or configure the associated Windows NT account.
	Batch - The Migration Wizard is started with command-line options. For more information, see Appendix C.
Which method you use depends on how you plan to use the Migration Wizard. This decision is totally independent of other decisions, including single or multi-phased migration, and partial or entire postoffice migration.
One-Step Migration
If you don’t need to make changes to the common name of the mailboxes, you can use the following procedure.

	To migrate in one step from a Microsoft Mail (PC) postoffice
	1. 	In Program Manager, choose Microsoft Exchange, and then choose Microsoft Exchange Migration Wizard.
		
	2.	Select Migrate from MS Mail for PC Networks, and choose Next.
	3.	Read the informational screen and choose Next.
		
	4.	In the Path to MS Mail Postoffice box, type the path to the postoffice, or choose Browse to specify the path.
	5.	In the Account Name box, type the mailbox name of an administrator on the postoffice.
	6.	In the Password box, type the password for this mailbox, and choose Next.
		
	7.	Select One step migration, and choose Next.
		
	8.	Select one or more options.
Option	Description	
		
Information to create mailboxes	Creates mailboxes for the selected users in the user list file.	
Personal E-mail Messages	Copies all messages and folders from the selected user’s mailbox and server-based MMF. You can select all or set a range.	
Shared Folders	Copies all shared folders to the public folder server of this server.	
Personal Address Books	Copies PAB entries in MMFs and puts them into the selected user’s inbox in a special message.	
Schedule Information	Copies calendar files from the CAL directory on the postoffice to a special message in the selected user’s inbox.	

	9.	Choose Next.
		
	10.	Under Select Which Accounts You Would Like To Migrate, select the mailboxes you want to migrate, or choose Select All to select all mailboxes.
	11.	Choose Next.
		
	12.	Under Enter A Server Name, type the name of the destination Microsoft Exchange Server computer, and choose Next.
		
	13.	Select one option based on your needs, and choose Next.
Option	Description	
		
No access	Creates public folders that only the administrator can access.	
Author access	Creates public folders in which everyone can read existing messages and create new ones. The administrator is assigned Administrator permissions.	
Publishing Editor access	Creates public folders and adds subfolder creation permissions in addition to author access.	

Note
The administrator account that is being used to run the Migration Wizard is granted Administrator permissions for all public folders. Additional permissions can be assigned after the Migration Wizard has imported the folders.

	14.	Select the directory container for the new mailboxes. 

Note
You cannot move a mailbox from one directory container to another after the mailbox has been created.

	15.	If you are using a mailbox template to reduce the work of setting up new mailboxes, choose Browse and select the template mailbox from the address list. For more information on mailbox templates, see the Microsoft Exchange Server Administrator’s Guide.
	16.	Choose Next.
		
	17.	Under For Users That Don’t Have Windows NT Accounts, select one of the following options.
Option	Description	
		
Create accounts and generate random passwords	Accounts are created with names that match the common name and random passwords. The passwords are written to the ACCOUNT.PASSWORD file in the working directory of the Migration Wizard. For users to log on to Windows NT, you need to distribute these passwords. 	
Create accounts and use 
alias as password	Accounts are created with names and passwords that match the common name.	
Don’t create Windows NT accounts	If a Windows NT account that matches the common name of a mailbox does not exist, create the mailbox without an associated Windows NT account. No one will be able to access this mailbox until a Windows NT account is associated with it.	

Note
The Migration Wizard associates the Windows NT account, if one exists, in the specified domain that has the same name as the common-name of a mailbox, no matter which option is selected.

	18.	Under Choose a Windows NT Domain for new accounts, select the domain where the user’s Windows NT accounts are located or are to be created.
	19.	Choose Next to begin the migration process.

Two-Step Migration
You should use this procedure if you need to make changes to the common name of the mailboxes, configure the associated Windows NT account, or import directory data as part of creating mailboxes.
Creating the User List
The user list is created from existing Microsoft Mail mailboxes. Before creating mailboxes, the user list can be modified to meet your naming convention, site or Windows NT security account needs.
	To create the user list from a Microsoft Mail (PC) postoffice
	1.	In Program Manager, choose Microsoft Exchange, and then choose Microsoft Exchange Migration Wizard.
		
	2.	Select Migrate from Microsoft Mail for PC Networks, and choose Next.
	3.	Read the informational screen, and choose Next.
		
	4.	Under Path to MS Mail Postoffice, type the path to the postoffice, or choose Browse to specify the path.
	5.	In the Account Name box, type the mailbox name of an administrator on the postoffice.
	6.	In the Password box, type the password for this mailbox, and choose Next.
		
	7.	Select Two step migration, and choose Next.
		
	8.	Select Extract a User List file and type the path and file name of the new user list, or choose Browse to specify the path and file name.
	9.	Choose Next.
		
	10.	Under Select Which Accounts You Would Like To Migrate, select the mailboxes you want to migrate, or choose Select All to select all mailboxes.
	11.	Choose Next to create the user list file.
Modifying the User List
You can make changes as needed in the user list file. If you need to change the common name of a mailbox, do it before the mailbox is created. Other fields can be modified now in the text file or later. To change them now, use the following procedure. To change them later, use the Administrator program to change them one at a time, or use the Directory Import command to change them in a batch mode.
	To modify the user list file
	1.	Make a backup copy of the user list file. You will need it later.
	2.	Using a text editor, open the user list file.
	3.	Delete the first two lines that have postoffice information, and save the file as text.
	4.	Open the modified user list file with a database program. 
This is a comma-separated text file. The first row contains field names.
	
The following fields are in the user list. The first two can’t be changed, and the first five need to be kept in the same order:
Field	Contents	
		
SFS_UserName	The mailbox name or alias of this mailbox in the postoffice. Do not change this field.	
SFS_FullName	The full or display name of this mailbox in the postoffice. Do not change this field.	
MigrateUser	This field should be Y if the mailbox is to be migrated and N if the mailbox should not be migrated.	
Obj-Class	This field should be mailbox. Other valid values are remote 
for custom recipients and dl for distribution list.	
Mode	This field describes what should be done with this object — create, modify, and delete are valid options. The default is create.	
Common-Name	The directory name of the mailbox. This can’t be changed later without deleting the mailbox and re-creating it. Change it now to match your naming convention. This defaults to the mailbox name, with extended characters removed.	
Display-Name	The name as displayed in the Address Book.	
Given-Name	The first name of a mailbox user.	
Surname	The last name of a mailbox user.	
Home-Server	The home server of the mailbox. You can move a mailbox within the site later without difficulty, but you should decide where each group of mailboxes is to be created.	
Comment	This is the comment that appears in the Address Book. It can be used to distinguish between two people with the same or similar names or for notes about contacts for Schedule+ resources.	
Assoc-NT-Account	Each mailbox needs an associated Windows NT account which has user access. On a Schedule+ resource account, this can be a Windows NT group or account that is responsible for managing the resource or the administrator who is going to log on to the account once to set up forwarding rules and Schedule+ permissions.	

You can add additional directory import fields after Assoc-NT-Account.
	5.	After it is modified, export the file in comma-separated value (CSV) format.
	6.	Open the modified file and the backup file with a text editor. Copy the two lines from the backup file to the top of the modified file. Save the file as text.

Migrating Mailboxes
After creating the user list and modifying it, you can migrate mailboxes from the postoffice to your site. This does not delete the mailboxes or remove mail. It copies the information to the Microsoft Exchange Server computers where the new mailboxes are created. Before you start migrating mailboxes, map a drive letter or connect to a server where the postoffice resides. You will need read/write access to the share or volume and have the name and password of the administrator.
	To migrate mailboxes from a postoffice to Microsoft Exchange Server with a user list
	1.	In Program Manager, choose Microsoft Exchange, and then choose Microsoft Exchange Migration Wizard.
		
	2.	Select Migrate from Microsoft Mail for PC Networks, and choose Next.
	3.	Read the informational screen, and choose Next.
		
	4.	Under Path to MS Mail Postoffice, type the path to the postoffice, or choose Browse to specify the path.
	5.	In the Account Name box, type the mailbox name of an administrator on the postoffice.
	6.	In the Password box, type the password for this mailbox and choose Next.
		
	7.	Select Two-step migration and choose Next.
		
	8.	Select Use a User List File to do a migration, and type the path and file name of the modified user list. Or choose Browse to select the path and file name.
	9.	Choose Next.
		
	10.	Select the import options.
Option	Description	
		
Information to create mailboxes	Creates mailboxes for the selected users in the user list file.	
Personal E-mail Messages	Copies messages and folders from the selected user’s mailbox and server based MMF. You can select all messages or set a range .	
Shared Folders	Copies all shared folders to the public folder server of this server.	
Personal Address Books	Copies PAB entries in the MMFs and puts them into the selected user’s inbox in a special message.	
Schedule Information	Copies calendar files from the CAL directory on the postoffice to a special message in the selected user’s inbox.	

	11.	Choose Next.
		
	12.	Select one option based on your needs, and choose Next.
Option	Description	
		
No access	Creates public folders that only the administrator can access.	
Author access	Creates public folders in which everyone can read existing messages and create new ones. The administrator is assigned Administrator permissions.	
Publishing Editor access	Creates public folders and adds subfolder creation permissions in addition to author access.	

Note
The administrator account that is being used to run the Migration Wizard is granted Administrator permissions for all public folders. Additional permissions can be assigned after the Migration Wizard has imported the folders.

	13.	Under Enter A Server Name, type the name of the destination Microsoft Exchange Server computer, and choose Next.
		
	14.	Select the directory container for the new mailboxes. 

Note
You cannot move a mailbox from one directory container to another after the mailbox has been created.

	15.	If you are using a mailbox template to reduce the work of setting up new mailboxes, choose Browse, and select the template mailbox from the address list. For more information on mailbox templates, see the Microsoft Exchange Server Administrator’s Guide.
	16.	Choose Next.
		
	17.	Under For users that don’t have Windows NT accounts, select one of the following options.
Option	Description	
		
Create accounts and generate random passwords	Accounts are created with names that match the common name and random passwords. The passwords are written to the ACCOUNT.PASSWORD file in the working directory of the Migration Wizard. For users to log on to Windows NT, you need to distribute these passwords. 	
Create accounts and use 
alias as password	Accounts are created with names and passwords that match the common name.	
Don’t create Windows NT accounts	If a Windows NT account that matches the common name of a mailbox does not exist, create the mailbox without an associated Windows NT account. No one will be able to access this mailbox until a Windows NT account is associated with it.	

	18.	Under Choose a Windows NT Domain for new accounts, select the domain where the users’ Windows NT accounts are located or to be created.
	19.	Choose Next to begin the migration process.

Depending on your migration strategy, you can choose to delete the Microsoft Mail (PC) mailboxes or make the postoffice hidden. For information about how to back up the updated directory and information store, see the Microsoft Exchange Server Administrator’s Guide.

Terms
For administrators of Microsoft Mail (PC), the following list of familiar terms and how they relate to Microsoft Exchange Server terms should help you understand differences between the two products:
MS Mail for PC Networks term	MS Exchange Server equivalent term	Descriptions	
			
External, MMTA	MTA or
MS Mail Connector MTA	The MTA is a integral part of the server and moves mail by talking with MTAs at other servers.
The MS Mail Connector MTA can move mail between MS Mail PC postoffices. It also moves mail between MS Mail PC postoffices and the MS Mail Connector postoffice.	
Windows Remote client	Windows client	All MS Exchange clients are remote clients. They need to have network connectivity to send and read mail. 	
Postoffice	Server	Postoffices are a collection of files. The server is an active process.	
Directory synchronization	Directory replication	Replication occurs as needed within a site and between sites.	
Directory synchronization server	Directory bridgehead servers	Replication is a peer-to-peer process within a site. Changes are sent to all servers, not to a central server.
Between sites, directory bridgehead servers package up changes and forward them to other sites.	
Downstream postoffices	Address space and Connected Sites property page.	When you add a new gateway to a site, configuration is done for the site, not per server. In other sites, you need to change the address space so mail to the gateway is routed to the site the gateway is installed into. This is related to the connected sites property.	
Access component	Not applicable	See “Downstream postoffice” for more details.	
Import.exe	Directory import and export	Close match of features	
Postoffice address list	Site-server-recipients	Custom recipients do not need to be added to server recipient lists to be included in distribution lists.	
Postoffice groups	Distribution lists (DLs)	DLs are created once per organization, not per postoffice. DLs are expanded to include all members. Membership in a DL is not limited to mailboxes and custom recipients - it includes public folders and distribution lists.	
Modem scripts	Not applicable	Remote clients connect with RAS, Shiva or other remote access network software. Modem scripts are no longer needed for remote client access.	
Shared folders	Public folders	Public folders are visible throughout the site. With site affinity, they can be accessible from other sites.	
Group folders	Public folders	Public folders are visible throughout the site. Permissions can be assigned to any recipients.	
Custom message	Form	Forms are easier to create and use. They no longer require changes to INI files, and are installed in folders or sites.	
MSMAIL.INI	EXCHNG.INI or registry entries		
SHARED.INI	Enterprise forms registry	Adding a custom form to the enterprise forms registry makes it available to all Windows clients in the site.	
Custom command	EXCHNG.INI or registry entries		
Custom menus	EXCHNG.INI or registry entries		
FOLDCOMP.EXE	Automatic background task or offline.	The private and public information stores repack the data file to move unused space to the end of the file. Offline compaction reduces the size of the file.	
MOVEUSER.EXE	Administrator program	Within a site, updating of distribution lists, and permissions on public folders is automatic. Between sites, or into different recipient containers, see the procedure in the Administrator’s Guide .	
LMEXT.EXE 	Administrator program	The file is created in the directory import format.	
NOVEXT.EXE	Administrator program	The file is created in the directory import format.	
TEMPLATE.EXE	Directory Import and Export in the Administrator program	Modifies more than template information - can also change distribution list members, display name and other properties of a recipient.	
Gateway	Connector	Connectors are administered with the Administrator program, and run as Windows NT services on the server.	
Mail Message File (MMF)	Personal Folders (PST)	Personal folders are only required for offline use or when not using the Microsoft Exchange Server information service.	

BLANK PAGE
IMPORTANT: This text will appear on screen, but will not print on a PostScript printer.
This page should be the last one in this file; it was inserted by running the InsertBlankPage macro.
Do not type any additional text on this page!