Performing a Single Phase Migration

 

Single-phase migrations include several key steps:

• Selecting the right migration tools

• Testing migration procedures in a computer lab and then deploying Exchange 2003

• Creating recipient objects in Active Directory

• Deploying Outlook and providing user training

• Migrating user data

• Decommissioning the legacy system

The order of these steps depends on your specific situation. For example, you might want to deploy Outlook early if your legacy messaging system supports MAPI, as explained earlier. Deploying Outlook before migration allows users to download existing messages, appointments, and tasks to .pst files on their workstations and retain this data in the new Exchange 2003 organization. In this case, it is not necessary to migrate server-based data using the Exchange Migration Wizard or other tools. You must only replace the existing messaging system and reconfigure your users' Outlook profiles for Exchange 2003.

Remember that the success of a single-phase migration depends to a large degree on your preparations. You must test the individual migration steps in a computer lab and address any critical issues in your procedures before you work in the production environment. In addition, users must familiarize themselves with Outlook before migration. This can be accomplished through training and hands-on experience, either in the legacy messaging environment, if Outlook is supported, or in the new Exchange 2003 organization, if you cannot deploy Outlook beforehand. In the latter case, wait for an appropriate period of time after deploying Exchange 2003 and Outlook—usually a few weeks or a month—before migrating mailboxes to give your users a chance to use the new messaging client.

Use the flowchart shown in Figure 1 as a guide to determine an appropriate sequence of migration steps.

Figure 1   Generic single-phase migration approach

Migration Tools

The procedures for moving mailboxes and data to Exchange 2003 depend to a large extent on the features of the migration tools that you select. A recommended tool is the Exchange Migration Wizard, included in the Exchange 2003 product package. A variety of tools are also available from non-Microsoft vendors.

Primary migration tools are:

• **Exchange Migration Wizard   **This wizard automates the migration of mailboxes and server-based data to Exchange 2003. The Exchange Migration Wizard extracts and converts folders, messages, and address books, where applicable.

• Outlook 2003   Outlook can also be classified as a migration tool, because this client is able to import data from a wide range of sources, including Lotus cc:Mail archives, .pst files, databases, and so on. The Import/Export feature in Outlook might require additional software on the client computer.

• **Exchange application converters   **Application converters can facilitate the migration of workgroup applications. For example, simple discussion forms might be converted quickly to Outlook forms applications. Sophisticated applications, however, require complete reengineering.

• Importer for Lotus cc:Mail Archives   You can use this tool to import Lotus cc:Mail archive files to folders in an Exchange 2003 mailbox store or to one or more .pst files. To download the Importer for Lotus cc:Mail Archives, go to https://go.microsoft.com/fwlink/?LinkId=25933.

• Non-Microsoft tools   A variety of non-Microsoft tools exist to facilitate migrations to Exchange. Many of these tools rely on MAPI and communicate with Exchange 2003 through an Outlook client. Microsoft does not support these tools and does not warrant their usefulness in any migration scenario. You must verify their functionality and reliability in a test lab. Table 1 lists examples of non-Microsoft migration tools for Exchange 2003.

  Table 1   Examples of non-Microsoft migration tools for Exchange 2003

  Migration tool	Used to
  Automation-Specialists Exchange Directory Migration Manager	Migrate distribution lists and custom recipients to an Exchange 2003 organization
  AutoProf Profile Maker	Create or modify Outlook profiles remotely
  ComAxis Technology UniAccess	Migrate CompuServe WinCIM data
  CompuSven E-Mail Shuttle	Migrate data from Fischer Totally Automated Office (TAO) and H & W SYSM to Exchange
  Gens Software QmailMig to Microsoft Exchange	Migrate QmailMig data to Exchange
  Incognito Software Migration Director	Migrate Banyan VINES accounts and mailboxes to Exchange
  Lightspeed Systems Vines Migration Tools (VMT)	Migrate Banyan Systems BeyondMail and Intelligent Messaging III/IV users to Exchange
  OpenOne Direct-TO-1	Migrate digital e-mail servers to Exchange
  Simpler-Webb, Inc. CalMover	Migrate calendar data from Steltor CorporateTime, HP OpenTime, and Netscape Calendar Server to Exchange
  Simpler-Webb, Inc. MailMover Suite	Migrate users from HP OpenMail or Samsung Contact to Exchange
  TBS Software MIGRA/PS-Export for the Microsoft Exchange Migration Wizard	Migrate users from IBM OfficeVision/MVS to Exchange
  Transend Migrator	Migrate data from a variety of messaging systems, including Lotus cc:Mail, Novell GroupWise, IMAP4, Netscape, Eudora/Eudora Pro, Microsoft Outlook Express, and message handling system (MHS), to Exchange
  Wingra Technologies Novell GroupWise Migrator for Outlook	Migrate Novell GroupWise data to Outlook.

Exchange Migration Wizard

The Exchange Migration Wizard is a key migration tool. It is installed together with Exchange System Manager on your Exchange 2003 server. You can use the Exchange Migration Wizard to connect to the legacy mail system, extract the user data into temporary migration files, and then connect to the target Exchange 2003 server to place the data into the corresponding mailboxes. The wizard can even create the mailboxes automatically for you during this process. You can complete the entire process in one step, or in two steps if you want to modify the migration files.

The Exchange Migration Wizard relies on two steps:

• Source extraction   Source extractors connect to source mail systems and extract the data to save it in a set of migration files. The Exchange Migration Wizard can use a variety of source extractors for several messaging systems, including Microsoft Mail for PC Networks, Lotus cc:Mail, Novell GroupWise, and IMAP4 hosts, as well as Lightweight Directory Access Protocol (LDAP)-conforming directories. You choose the source extractor that you want on the Migration Wizard page that appears when you click Next in the Welcome page of the wizard.

  Note

  Some source extractors might require additional software to be fully functional, such as the Lotus cc:Mail Export.exe tool, or a Novell GroupWise client installed on the local computer.

• Migration file import   The Exchange Migration Wizard uses its internal migration file importer component to inject messages, calendar information, and collaboration data into the selected Exchange store and recipient information into Active Directory. Although there are many different types of source extractors, there is only one migration file importer.

  Note

  You must be an Exchange Full Administrator in the target administrative group and an account administrator in the target Active Directory domain or organizational unit to import mail data and directory information.

Migration Files

Migration files are .csv files and can be opened in a text editor or using Microsoft Excel. You can also use Excel to edit the migration files before you import them with the Exchange Migration Wizard. In this way, you can change mailbox aliases or generate first name and last name fields based on display names. You can also add additional information, such as telephone numbers, department names, and so on. Furthermore, you can delete all messages sent before a certain date.

The Exchange Migration Wizard migration file importer requires the following three types of files to accomplish a migration:

• A packing list file   This is used to identify the primary and secondary migration files. The Exchange Migration Wizard requires the packing list file to determine all primary and secondary files involved in the migration.

• Primary files   These include directory information as well as message headers and pointers to secondary files. There is one primary file, called directory.pri, containing the directory information for all users and their attributes (such as display name, alias, and e-mail addresses) There is also one primary file for each user that contains corresponding message header information (such as To, From, Cc, Subject, Date, and Time) and pointers to secondary files. Primary files for users are named in numbered sequence (for example, 00000001.pri, 00000002.pri, 00000003.pri, and so on).

• Secondary files   These contain raw data, such as message bodies, attachments, and so on.

  Note

  Do not edit secondary migration files. Changes to secondary files invalidate all offsets and pointers in the corresponding primary file. Editing primary migration files can also lead to incorrect data. Save a copy of the original migration files, and test your changes carefully before applying them in the production environment.

The Exchange Migration Wizard does not change or delete messages from the source mailboxes. The source mailboxes remain intact and continue to receive mail after you perform a migration. There is no option to delete old mailboxes automatically. You must reconfigure the message routing and decommission the legacy system.

Migrating Recipient Information

Before you can copy existing messages, appointments, tasks, contacts, and other user-related data to Exchange 2003, you must create mailboxes that correspond to those available in the legacy messaging system. It is also useful to mirror other recipient objects, such as distribution lists and foreign recipients that exist outside of the environment that is being migrated. Performing a complete migration of recipient information allows your users to continue using familiar e-mail addresses in their new messaging environment.

You can migrate directory information in one of the following ways:

• Automated migration   Using the Exchange Migration Wizard, you can automatically create mailbox-enabled user accounts in Active Directory when you migrate mailboxes. However, the Exchange Migration Wizard has limited capabilities for handling distribution lists or groups.

• Manual migration   You can use Active Directory Users and Computers to create mailbox-enabled user accounts and other recipient objects manually. This strategy works well if you are migrating a small number of users.

• Programmatic migration   You can use ADSI and CDOEXM to develop custom applications in Microsoft Visual Basic, Scripting Edition (VBScript). For example, you can create an ASP page to migrate and maintain recipient information. This approach is flexible and allows you to mirror mailboxes, distribution lists, and foreign recipients as in the legacy messaging system, but it requires programming skills.

• Semi-automated migration   If you can export all recipient information from the legacy messaging system into a text file, you can use this information to create an LDIF file to import the recipients to Active Directory using Ldifde.exe, or create a .csv file and import the information using Csvde.exe.

Creating Mailbox-Enabled Accounts with the Exchange Migration Wizard

The Exchange Migration Wizard can create mailboxes automatically. You can specify the organizational unit for new mailbox-enabled user accounts. You can also specify how passwords are generated. The Exchange Migration Wizard can use the account name as the password or generate random password strings for all users, which are then written to an ACCOUNT.PASSWORD file in the temporary migration directory.

Preserving Legacy E-Mail Addresses

If you want to change or add recipient information, you can perform a two-step migration in the Exchange Migration Wizard and edit the Directory.pri user list file before you apply the changes in Exchange 2003. If possible, however, avoid changing the Secondary-Proxy-Addresses field of your users. The Exchange Migration Wizard retains each user's original e-mail address in this field when it creates the user accounts in Active Directory, so that Exchange can route replies to old messages to the user's new Exchange 2003 mailbox. For example, assume a migrated user (now an Exchange user) replies to an old message of yours or specifies your old e-mail address in a new message. When the user clicks the Check Names button on the toolbar (or sends the message without performing this step, at which time Outlook checks the name automatically), Exchange can find a recipient object in Active Directory that refers to your mailbox, because this recipient object has a matching secondary proxy address. The e-mail message is then delivered to your Exchange 2003 mailbox. There is more information about secondary proxy addresses later in this topic.

Address Matching

Recipient information might already exist in Active Directory before you run the Exchange Migration Wizard because, for example, your Novell GroupWise, or IMAP4 users already have user accounts in a Windows domain that belongs to your Active Directory forest. Running the Exchange Migration Wizard in this situation should not lead to duplicate user information. The Exchange Migration Wizard searches Active Directory for matching recipient objects in an attempt to minimize account duplication.

If you migrate from a non-Exchange mail system, the Exchange Migration Wizard uses the following information to determine matches:

• The Exchange Migration Wizard matches the e-mail address of the account to be migrated to the e-mail address of the target user object in Active Directory. Because e-mail addresses in a messaging system are unique, any matching accounts are considered definite matches.

  If you attempt to break a definite match during a migration, the Exchange Migration Wizard warns you that the selected object cannot be unmatched because the association is based on a matching proxy address. When you migrate from a non-Exchange system and want to avoid definite matches with existing user accounts, you must edit the user's e-mail address in the messaging system from which you are migrating or the e-mail address of the Active Directory user object so that the addresses no longer match before you start the migration process using the Exchange Migration Wizard.

• The Exchange Migration Wizard matches the Full Name and Logon ID attributes of the account to be migrated to the Full Name and Logon ID attributes of the target user object. Because the Full Name and Logon ID attributes might not be unique in an Active Directory forest with multiple domains, any matching accounts are considered probable matches.

  You have two options for modifying probable matches, which appear in the Existing Windows Account column on the Windows Account Creation and Association page in Exchange System Manager:

  • Use Find Existing Account to match the mailbox from the messaging system from which you are migrating to an existing Windows user account.

  • Use Create New Account to ignore a match and create a new user object. You can edit Full Name and Logon ID for a new Windows account. Double-click the account to open Mail Account Properties, and then edit the account information.

Migrating User Accounts into a Resource Forest

When you examine the account creation options in the Exchange Migration Wizard (click Options on the Container for New Windows Accounts wizard page), you find that the Exchange Migration Wizard is able to associate migrated accounts with accounts in an external domain. You also have the option to create associated accounts in an external domain if you specify an Administrator account with appropriate account administrator rights. This functionality is useful if you plan to migrate non-Exchange users into an Exchange 2003 organization that is deployed into a resource forest.

Organizations deploy Exchange 2003 in a resource forest if internal resources are distributed over a variety of Microsoft Windows NT® domains or separate Active Directory forests. In this situation, you deploy a separate forest for the Exchange 2003 organization with deactivated mailbox-enabled user accounts. You must establish trust relationships between the resource forest and the account domains. You can then assign an external account from an account domain the Associated external account permission for a deactivated mailbox-enabled user account in the resource forest. To do so, go to the properties of a mailbox-enabled user account in Active Directory Users and Computers, switch to the Exchange Advanced tab, and click Mailbox Rights. This mailbox right enables specified users to log on to the mailbox using their own accounts. The Exchange Migration Wizard can establish the external account association automatically. For more information about the deployment of Exchange Server 2003 in a resource forest, see Planning an Exchange Server 2003 Messaging System (https://go.microsoft.com/fwlink/?LinkId=21766).

Creating Recipient Objects Manually

If Exchange System Manager does not support your legacy messaging system, or if you opted to use a different migration method, you might need to create mailboxes and other recipient objects in Exchange 2003 manually. In Exchange 2003, mailboxes are created by mailbox-enabling user accounts in Active Directory. Legacy distribution lists correspond to mail-enabled user groups, and address references to recipients outside of the legacy messaging system correspond to mail-enabled user accounts or contacts in Active Directory. You can use Active Directory Users and Computers to mailbox-enable user accounts or mail-enable user accounts, groups, and contacts. Table 2 matches typical recipient objects in a non-Microsoft messaging system to corresponding recipient objects in Active Directory.

Table 2   Recipient objects in non-Microsoft messaging systems and in Exchange 2003

Non-Microsoft messaging system	Exchange 2003 messaging system	Comments
Mailbox	Mailbox-enabled user account	If your users already have accounts in Active Directory (for example, because they are working with Microsoft Windows XP workstations in a Windows domain environment), mailbox-enable the existing accounts. For users who do not exist in the Active Directory forest, create new mailbox-enabled accounts.
External recipient	Mail-enabled user account	Use mail-enabled user accounts if the users are in your Active Directory forest but remain on a non-Exchange messaging system that is not being migrated.
External recipient	Mail-enabled contact	Use mail-enabled contact objects for users who are not in your Active Directory forest and are on a non-Microsoft messaging system that is not being migrated.
Distribution list	Mail-enabled universal distribution or security group	If possible, create mail-enabled security groups and configure the group membership according to the distribution lists in the legacy system. Mail-enabled groups can contain any type of recipient object, including mailbox-enabled users, mail-enabled users, mail-enabled groups, mail-enabled contacts, and mail-enabled public folders.
Distribution list	Mail-enabled public folder	Under some circumstances, you might want to configure mail-enabled public folders for legacy distribution lists. For example, you can migrate distribution lists to public folders and configure public folder rules to forward incoming messages to all recipients that were originally members of the distribution lists. This approach has several disadvantages, however, including: All messages must first reach the server where the public folder resides. This might cause inefficient message routing. Public folder rules do not scale well to a large number of mailboxes. All users require write access to the "distribution list" public folder. For migrated users, you must manually update the public folder rules to forward the messages to the Exchange mailboxes. The Exchange Migration Wizard cannot accomplish this task for you. Note To implement a message archive for a distribution list, you can mail-enable a public folder, and then add the public folder as a member to the distribution group, but you should not use a public folder to replace a distribution group.

Configuring Recipient Policies

Exchange 2003 maintains server-based address lists, such as the global address list, automatically when you mailbox- or mail-enable directory objects in Active Directory. This is the job of the Recipient Update Service. This service assigns default e-mail addresses to all mailbox- or mail-enabled recipient objects, such as user accounts, groups, and contacts. A recipient policy determines the format of generated e-mail addresses.

Use Exchange System Manager to adjust the settings in the default recipient policy, as follows:

1. In the console tree, expand the Recipients container and then select Recipient Policies. In the details pane, the Default Policy object is listed. If you want to preserve existing recipient information, you must adjust this recipient policy or create a new policy with a higher priority that applies to all relevant objects and assigns default e-mail addresses that correspond to those in the legacy messaging system.

2. Double-click the Default Policy object to display its properties, and then click the E-Mail Addresses tab. You can now change the various address generation rules, such as those for SMTP addresses. You can use placeholders in your e-mail address generation rules. For example, if you want to change from the default address format of <User Logon Name>@<Domain Name> to an address format of <First Name>.<Last Name>@<Domain Name> (for example, Ted.Bremer@contoso.com), you must use placeholders for the first and last names, because this is variable information. In this example, you select the entry for SMTP addresses on the E-Mail Addresses tab, click Edit, and, under Address, add %g.%s to the beginning of the address definition (for example, %g.%s@contoso.com). In addition, you can specify how many characters to use (for example, %g%1s@contoso.com results in TedB@contoso.com). Table 3 lists the possible placeholders in address generation rules.

   Table 3   Placeholders in address generation rules

   Placeholder	Description
   %d	Display name
   %g	First name
   %i	Initials
   %m	Alias
   %s	Last name

   Note

   For information about additional placeholders that can be used, see Microsoft Knowledge Base Article 285136, "XADM: How to Customize the SMTP E-mail Address Generators Through Recipient Policies" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=285136).

Configuring Primary and Secondary Addresses

Some organizations want to change their SMTP addresses during migration, especially if they are involved in a company merger. However, if you assign new e-mail addresses to your users, replies to old messages become non-deliverable. To preserve the old address information, adjust your recipient policies to assign secondary SMTP addresses to your users, in addition to new primary SMTP addresses. You must specify an address generation rule that generates secondary addresses that match the legacy system. Exchange 2003 then uses the primary SMTP address for all outgoing e-mail and also delivers all incoming e-mail addressed to any of the assigned secondary addresses. Recipients in an Exchange 2003 organization can have one primary SMTP address and as many as 32 secondary SMTP addresses, which is sufficient for most users.

Creating Recipient Objects Programmatically

You can use ADSI and CDOEXM to create mailbox- and mail-enabled recipient objects in Active Directory. Important objects are CDO.Person and ADSI.User. The following VBScript code example uses CDO.Person to create a user account in Active Directory and mailbox-enable it.

An example for working with Active Directory information using ADSI.User follows in the section "Updating Recipient Information Through VBScript."

Set oPerson = CreateObject("CDO.Person")
oPerson.LastName = "Bremer"
oPerson.DataSource.SaveTo "LDAP://server01.contoso.com/" _
                        & "CN=Ted,CN=Users,DC=Contoso,DC=com"

Set oMailbox = oPerson.GetInterface("IMailboxStore") 
oMailbox.CreateMailbox _
     "CN=Mailbox Store (EX-SRV1),cn=First Storage Group," _
   & "cn=InformationStore,cn=EX-SRV1,cn=Servers," _
   & "cn=First Administrative Group," _
   & "cn=Administrative Groups,cn=Exchange," _
   & "cn=Microsoft Exchange,cn=Services,cn=Configuration," _
   & "dc=Contoso,dc=com"

oPerson.DataSource.Save
set oMailbox = nothing
set oPerson = Nothing

Notice the use of the IMailboxStore interface, which you can retrieve from CDOEX and ADSI objects through the GetInterface method. IMailboxStore is a CDOEXM interface that facilitates the creation of mailboxes for user accounts. This code example does not specify any e-mail addresses. The Exchange Recipient Update Service assigns the information based on recipient policies, as explained earlier. For more information about ADSI, CDOEX, and CDOEXM, see the Exchange Software Development Kit (SDK) (https://go.microsoft.com/fwlink/?LinkId=25925).

Creating Recipient Objects Semi-Automatically Using LDIFDE or CSVDE

If you are not a programmer, you can use Ldifde.exe or Csvde.exe to create the required recipient objects. Ldifde.exe works with LDIF files, a file-format standard for batch operations against LDAP-conforming directories. To view the general parameters of Ldifde.exe, open the command prompt, type ldifde, and press ENTER. The output on the screen explains available options and gives sample command lines. For detailed information about Ldifde.exe, see Microsoft Knowledge Base article 237677, "Using LDIFDE to Import and Export Directory Objects to Active Directory" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=237677).

Many large companies that operate heterogeneous messaging environments prefer to perform directory synchronization manually. This allows them to keep the synchronization of directories, which contain hundreds of thousands of recipient objects, under control. Address book files are usually distributed in .csv format. This file format is convenient because it allows you to process address information in Excel before you import the information. You use the Csvde.exe tool to process this file type. The command syntax is the same as for the LDIFDE tool. Both tools have many features in common.

The following example uses Ldifde.exe to create a mailbox-enabled user account named Ted with SMTP and X.400 proxy addresses. You can import this file with the following command: ldifde -i -f <Import File> -s <Domain Controller> (for example, ldifde -i -f Import.ldf -s server01).

dn: CN=Ted,CN=Users,DC=contoso,DC=com
changetype: add
displayName: Ted
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=contoso,DC=com
objectClass: user
proxyAddresses: X400:c=us;a= ;p=Exchange;o=Exchange;s=Ted;
proxyAddresses: smtp:OldTed@Contoso.com
proxyAddresses: SMTP:Ted@Contoso.com
name: Ted
sAMAccountName: Ted
userAccountControl: 512
userPrincipalName: Ted@Contoso.com
msExchHomeServerName: 
 /o=Exchange/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=EX-SRV1
mailNickname: Ted

Updating Recipient Information in Active Directory

After you create recipient objects in Active Directory using the Exchange Migration Wizard, Active Directory Users and Computers, or any of the other described methods, you might want to verify and update primary or secondary e-mail addresses. This is especially true if you must preserve existing address information that does not follow a specific pattern. If your users have arbitrary e-mail addresses, you cannot preserve this information by using recipient policies. You must adjust the e-mail addresses manually in Active Directory Users and Computers after the Recipient Update Service has assigned the default addresses. This can be confusing, especially if you are migrating a large number of users. To simplify this task, use Ldifde.exe, Csvde.exe, or ADSI and CDOEXM to perform batch operations against Active Directory.

Updating Recipient Information Using LDIFDE

The process of updating recipient information in Active Directory using Ldifde.exe is almost the same as the process for creating mailbox-enabled user accounts that is described earlier. You only need to specify the type of change and the directory object that you want to modify. To modify the e-mail addresses of user accounts, groups, and contacts, export the directory information from a domain controller first. From the resulting export file, you can then determine the distinguished name of each individual recipient object that you want to update. The distinguished name uniquely identifies directory objects.

Use the command ldifde -f c:\Export.ldf -s <Domain Controller> (for example, ldifde -f export.ldf -s server01) to export all available directory information in the domain. You can restrict output to a specific organizational unit or even to a specific user account, if you use the –d parameter and specify the distinguished name of the search base for data export. Use the following command to export all objects in the Users container: ldifde -f Export.ldf -s <Domain Controller> -d "CN=Users,DC=<Domain>,DC=<com>" (for example, ldifde -f Export.ldf -s server01 -d "CN=Users,DC=Contoso,DC=com").

After exporting the directory information and determining the distinguished names of the recipient objects that interest you, it is relatively easy to create an import file for an e-mail address update. The lines containing distinguished names start with dn:. The following example shows an import file that assigns two SMTP addresses and one X.400 address to a mailbox-enabled account named Ted. You can import this file the same way that you create accounts (for example, ldifde -i -f Import.ldf -s server01).

dn: CN=Ted,CN=Users,DC=contoso,DC=com
changetype: modify
replace: proxyAddresses
proxyAddresses: SMTP:Ted@contoso.com
proxyAddresses: X400:c=US;a= ;p=FirstOrg;o=Exchange;s=Ted;
proxyAddresses: smtp:postmaster@contoso.com
-

Remember the hyphen between update records and on the last line of your import file.

Updating Recipient Information Using .csv Files

Csvde.exe is not as powerful a tool as Ldifde.exe, because Csvde.exe is unable to modify or delete existing directory objects. Therefore, if you plan to update recipient information based on a .csv file, you must extract the relevant .csv entries and write them into an .ldf file. You can then use Ldifde.exe as described earlier.

The following Excel macro demonstrates how to generate an .ldf file from a .csv file that contains the proxyAddresses attribute. In this code, it is assumed that the distinguished name is in the first column of the file and loops through all remaining header cells to determine the proxyAddresses column. The result is an entry for each recipient object from the .csv file to modify the proxyAddresses attribute. This approach can be applied with minimal modification to other directory attributes, as well.

Sub LDFfromCSV(Optional sAttribute As String = "proxyAddresses")
    ' Create the LDF file.
    sDefName = Application.DefaultFilePath & "\Import.ldf"
    sFile = Application.GetSaveAsFilename(InitialFilename:=sDefName, _
                                          Title:="Save LDF file")
    If sFile = "" Then
        Exit Sub
    Else
        Set fso = CreateObject("Scripting.FileSystemObject")
        Set f = fso.CreateTextFile(sFile, True)
    End If
  
    ' Determine the number of entries in the .csv file.
    nRows = ActiveSheet.UsedRange.Rows.Count
    nColumns = ActiveSheet.UsedRange.Columns.Count
    For i = 2 To nRows
        ' Specify the distinguished name of each recipient 
        ' for whom you want to modify a value.
        sVal = ActiveSheet.Cells(1, 1).Value & ": " _
             & ActiveSheet.Cells(i, 1).Value _
             & vbCrLf & "changetype: modify" & vbCrLf
        For j = 2 To nColumns
            sHdrValue = ActiveSheet.Cells(1, j).Value
            If sHdrValue = sAttribute Then
                ' You are now in the appropriate column.
                sVal = sVal & "replace: " & sHdrValue & vbCrLf _
                     & sHdrValue & ": " & ActiveSheet.Cells(i, j).Value _
                     & vbCrLf & "-" & vbCrLf
            End If
        Next
        sEntry = VBA.Replace(sVal, "\,", "\,", 1, -1, vbTextCompare)
        f.writeline sEntry
    Next
    f.Close
    Set f = Nothing
    Set fso = Nothing
End Sub

To demonstrate the conversion of a .csv file into an .ldf file, export the objects from the Users container using Csvde.exe. For example, type the following command: csvde -f export.csv -s <Domain Controller> -d "CN=Users,DC=<Domain>,DC=<com>". Among other information, the resulting file contains the proxyAddresses attribute for all mailbox-enabled user accounts. You can then change the proxyAddresses information for selected users and run the macro to generate the .ldf file.

Updating Recipient Information Through VBScript

If you want to update recipient information in a more straightforward way than with Ldifde.exe and Excel macros, you can use ADSI and VBScript in a custom administration tool. The following code example demonstrates how to set e-mail addresses for a user account programmatically using the ADSI.User object. You can use this code in an ASP page, for example. Remember to include your own code for checking permissions and error handling. The code example is a good starting point for an Active Directory application.

Const ADS_PROPERTY_CLEAR = 1
Const ADS_PROPERTY_UPDATE = 2
Const ADS_PROPERTY_APPEND = 3
Const ADS_PROPERTY_DELETE = 4

Set oUser = GetObject("LDAP://CN=testuser,CN=Users,DC=contoso,DC=com")
   
oUser.PutEx ADS_PROPERTY_UPDATE, "proxyAddresses", _
            Array("SMTP:olduseraddr@contoso.com", _
                  "SMTP:updateduser@contoso.com", _
                  "X400:c=us;a= ;p=Exchange;o=Exchange;s=updateduser;")
oUser.SetInfo

Migrating User Data and Calendar Information

Users usually insist that important messages, appointments, tasks, and contact information be preserved during migration. To accomplish this, you must develop strategies for moving existing data to Exchange 2003. Data might reside on the server in mailboxes, discussion boards, and other repositories, or on the client computers in personal message stores.

Migrating Server-based Data

If your users store the majority of their data on the server, you must develop a strategy for migrating data on their behalf. This requires addressing the following questions:

• Are special resource accounts included in the migration to Exchange 2003?   Special accounts might be used to represent a particular resource or piece of equipment, such as a meeting room, online conference, and so on. The account's calendar is used to book that resource or equipment, similar to the way a meeting is scheduled. Using the Exchange Migration Wizard, you can move special accounts and their data to Exchange 2003. However, the configuration is not retained. The wizard cannot distinguish user mailboxes from resource mailboxes, for example. Therefore, you must adjust the configuration manually. You must grant the user responsible for the resource Full Mailbox Access rights to the corresponding mailbox-enabled resource account in Active Directory Users and Computers, and you must connect to the resource mailbox in Outlook to reconfigure it as a resource account. On the Tools menu in Outlook, click Options. On the General tab, click Calendar Options, and then click Resource Scheduling. You must repeat these steps for all migrated resource accounts.

• Do you have sufficient disk space on the server to perform the migration to its full extent?   The Exchange Migration Wizard requires temporary disk space for its migration files. Also, Exchange 2003 stores migrated messages in two locations: databases and corresponding transaction log files. You should reserve at least three times as much disk space for the migration than is required for the actual amount of data that you plan to move. Disk space requirements are greater than for the legacy system, because the migration tools are not capable of handling single-instance storage. Single-instance storage is a feature that saves disk space and accelerates message delivery. A single message instance addressed to five recipients is stored only once with five pointers to the object for each individual recipient. However, migration tools, like users, see the object as an individual message item. The item is extracted five times, once for each individual mailbox. As a result, the item is copied five times to the Exchange store.

• Do you have the required access permissions to migrate all data on behalf of your users?   The account that you use to access the source messaging system (that is, the migration account) must have sufficient access rights to extract data from all mailboxes. This might require more than just administrator rights on a post office. For example, in Novell GroupWise, you must grant the migration account Novell GroupWise proxy rights for all mailboxes.

• Do your users store encrypted messages in their server-based mailboxes?   Decryption is required to convert messages into Exchange formats, but only the correct user can perform decryption. Instruct your users to download all encrypted messages to their clients, and point out that after migration, message encryption can be performed in Outlook using standard X.509 version 3-based encryption technology.

• Does the Exchange Migration Wizard support the existing messaging system?   The Exchange Migration Wizard is the primary Exchange 2003 migration tool and should be used, if possible. If your system is not supported, however, consider moving all data from the server to the users' workstations or use a non-Microsoft migration tool.

• Is it possible to consolidate messaging resources before migration?   The fewer the post offices or mail hosts that you must manage, the easier the migration. However, consolidating legacy messaging systems in their existing environments might be as complex as migrating each system individually. Consolidating messaging resources during the migration might be a more suitable approach. For example, you can migrate multiple post offices to the same Exchange 2003 server.

• Should all items or only the most recent items be migrated?   You can set a date range in the Exchange Migration Wizard that specifies the age of messages that you want to retain. Many companies use this opportunity to eliminate legacy e-mail, which saves disk space on the server and reduces migration time. Nevertheless, it is advisable to establish a policy regarding data that will not be migrated and to inform users so that they can print legacy messages, private address lists, and other information, such as message processing rules, or store the data in personal message archives.

• Will you migrate data over the computer network?   If it is not possible to copy entire post offices or other message repositories to the local Exchange server before migration, verify that the net-available bandwidth in your computer network can handle the workload. Ensure that source and target systems are in the same LAN. Avoid data migration over WAN connections, if possible, and perform maintenance and consistency checks before the migration.

Migrating Client-based User Data

If your users maintain their e-mail messages, contacts, and calendar information locally, instead of on the server, you have the following four migration choices:

• Allow users to move their local data back to the server before migration   Moving data back to the server might not be advantageous. It increases network traffic, consumes disk space on the server, and generally makes the work of the messaging administrator more difficult. Some messaging systems, such as POP3 hosts, do not support this option.

• Have users work with Outlook in the legacy messaging environment   Working with Outlook in the legacy environment allows users to download all data into personal folder stores if local disk drives have sufficient storage capacity. This reduces the amount of data that you must move using the Exchange Migration Wizard, and it avoids permission-related issues or issues with encrypted messages. The users can continue to use these repositories in the Exchange 2003 organization.

• Require that users migrate client-based data themselves   Asking users to perform the data migration themselves is an ideal choice from an administrator's perspective, but it might overwhelm the user. This can lead to frustration, increased help desk calls, and decreased productivity.

• Perform the migration manually on each user's computer   Having administrators or help desk personnel perform the client-based data transfer together with the users is a practicable solution for many companies.

Migrating Workgroup and Workflow Applications

Workgroup and workflow applications complicate a migration scenario. In fact, the presence of workgroup and workflow solutions and their data might prevent a single-phase migration. This might force you into a phase of short- or long-term coexistence and interoperability between Exchange 2003 and the legacy messaging system, until critical business applications are reengineered and deployed in the Exchange 2003 organization. The more sophisticated the workgroup solutions, the more complicated the migration and the higher the costs.

When you determine your migration strategy for workgroup and workflow applications, address the following questions:

• Are you planning to migrate collaboration applications to Exchange 2003 or other platforms?   You have two general options for migrating workgroup and workflow applications: you can port these solutions to Exchange 2003 or to a different platform. It might be a good idea to migrate your workgroup solutions to a system other than Exchange 2003 to eliminate the interoperability requirement in your migration plan. Some applications can be ported to a database management system (DBMS), such as Microsoft SQL Server™, in combination with a Web server, such as Internet Information Services (IIS) and the Microsoft .NET platform. The technologies in the Office system, such as Microsoft Windows SharePoint® Services, can also be used to develop and implement collaboration applications for task, contact, and calendar sharing. Additionally, Microsoft Office SharePoint Portal Server 2003 can be the basis for document management solutions. To learn more about SharePoint products and technologies, go to the SharePoint Web site (https://www.microsoft.com/sharepoint).

• Do critical workgroup applications exist that require extensive programming to port them to the new environment?   If this is the case, identify options to migrate the applications or develop a coexistence strategy based on a multiphase migration.

  Note

  If you cannot migrate essential workgroup and workflow applications in a timely manner, you cannot perform a single-phase migration.

• Do you need to port public discussion forums to Exchange 2003?   If so, identify one person to become the owner of all public folders that you create for discussion forums in Exchange 2003. You must also identify user default and specific permissions to the public folders, because permissions settings are not migrated. You must manually correct the security settings afterward using Exchange System Manager. If existing discussion forums rely on custom forms for data input and display, use Outlook Forms Designer to implement a corresponding Outlook form and associate this form with the corresponding public folder.