Migrating from Novell GroupWise to Exchange 2003 Server

Running the Router for Novell GroupWise Service in Console Mode

The connection between Connector for Novell GroupWise and the Novell GroupWise API Gateway is a critical point in the connector architecture. The Router for Novell GroupWise handles the communication between Connector for Novell GroupWise and the Novell GroupWise API Gateway by transferring keyword-based text files between the connector store and the API gateway directory. If you discover that messages are not being transferred successfully, try starting the router process in console mode to obtain more detailed information about this process.

To start the Router for Novell GroupWise service in console mode, perform the following steps:

1.	Stop the Microsoft Exchange Router for Novell GroupWise service in the Services tool. In the Stop Other Services dialog box, click Yes to stop the Microsoft Exchange Connector for Novell GroupWise service as well.
2.	Start Windows Explorer, open the \Program Files\Exchsrvr\bin directory, and locate the Gwrouter.exe file.
3.	Double-click the Gwrouter.exe file to start the GroupWise Router program in console mode. Verify that the router process started successfully and is polling the API Gateway directory (Figure 5.6).   Figure 5.6   Polling the API Gateway directory with the Router for Novell GroupWise service in console mode
4.	To stop the GroupWise Router, press CTRL+BREAK to terminate the program.

Archiving Processed Messages

The Microsoft Exchange Router for Novell GroupWise service supports archiving of messages that pass through Connector for Novell GroupWise. This can be a useful feature if you want to capture damaged or bad messages. To enable the archiving feature, you must activate a parameter switch in the registry settings of Connector for Novell GroupWise using Registry Editor.

Caution :

If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

To activate the archive directory, perform the following steps:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LME-GWISE\Parameters

Troubleshooting X.400 Connectivity

X.400 connectors are objects with many configuration options. Typographical errors and basic configuration errors resulting from misunderstandings between system administrators are among the most typical causes of X.400-related transfer issues. Transfer problems can also be caused by overtaxing an X.400 communication partner (for example, when an X.400 1988 system does not scale back to the X.400 features of 1984 when communicating with an X.400 1984 system) or by outright protocol violations caused by an X.400 communication partner.

The following are typical causes of message transfer problems over X.400 connectors:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters

Testing Messaging Connectivity

The best way to test X.400 connectivity is to send an e-mail message with a large attachment to an X.400 user from Outlook. A large attachment is recommended because, for example, small test messages might not reveal mismatched RTS values. To address the message, create a one-off X.400 address for the e-mail message.

To create a one-off address in an e-mail message, perform the following steps:

1.	Open Outlook, start a new e-mail message, and then click To.
2.	In the Select Names dialog box, click Advanced, and then click New.
3.	In the New Entry dialog box, under Put this entry, select In this Message only, select X.400 Address from the list of entry types, and then click OK (Figure 5.7).   Figure 5.7   Specifying a one-off X.400 recipient
4.	In the New X.400 Address Properties dialog box, specify the recipient information. You must complete the Display Name, PRMD, ADMD, and Country/Region fields, plus one additional field, such as Surname, to form a correct X.400 address. If the X.400 address of your target user has additional fields, you must specify those, as well.
5.	Click To. Note : Alternatively, you can type a one-off X.400 address directly in the To line. The following is an example (you must type the entire string, including the brackets): [x400:c=us;a=exchange;p=contoso;s=lastname]

Remember to ensure that message routing works in both directions. Ask the X.400 user to reply to your message to verify that message transfer also works in the opposite direction.

Examining X.400 Message Flow

The Exchange message queues involved in transferring a message over an X.400 connector are the same as those for Connector for Lotus Notes or Connector for Novell GroupWise, except that the Exchange MTA places outgoing messages into an internal MTA message queue on the file system instead of an MTS-OUT folder in the Exchange store. Figure 5.8 shows how messages flow from Exchange Server 2003 to an X.400 remote MTA.

 

Figure 5.8   Message flow to an X.400 remote MTA

 

Check the Exchange 2003 to X.400 message flow in the following order:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \MSExchangeMTA\Parameters

The application event log and additional log files are also of interest if you must verify message transfer from an X.400 system to Exchange 2003. Figure 5.9 shows the individual stages of X.400 message transfer to Exchange 2003.

 

Figure 5.9   Message flow through an X.400 connector to Exchange 2003

 

Check the message flow from the X.400 system to Exchange 2003 in the following order:

Troubleshooting SMTP Connectivity

The SMTP service is the internal transport engine of Exchange 2003 and is involved whenever messages are transferred. The SMTP service uses SMTP connectors to transfer messages to their destinations, similar to the way in which the Exchange MTA uses X.400 connectors. SMTP connectors are configuration objects that contain parameters that determine how the SMTP service establishes connections and transfers messages. However, SMTP connectors are not an absolute requirement for SMTP connectivity. Exchange 2003 virtual SMTP servers can also communicate directly with remote SMTP hosts.

The following are typical causes of message transfer problems over SMTP:

•	Host Unreachable   If the SMTP service cannot establish a connection to the remote SMTP host, verify that the address information for the remote host is correct and that the name of the remote host can be resolved to a valid IP address. If you know the IP address of the destination system, you can use Telnet.exe to try to establish a connection to TCP port 25. If you do not know the IP address of the destination system, start the NSlookup tool (NSlookup.exe) at a command prompt, and perform the following steps to query the destination domain's mail exchanger (MX) records: 1. In the NSlookup tool, ensure that a network connection exists to your DNS server, and then type the command set type=mx and press ENTER. 2. Type the domain name you are interested in (for example, microsoft.com) and then press ENTER. You should notice one or more MX records and the IP addresses for those hosts in the output screen (Figure 5.10).   Figure 5.10   Determining the IP Address of an MX record for a destination domain   3. Type exit and press ENTER to exit the NSlookup tool. If you are unable to connect to TCP port 25 on the destination system using Telnet.exe, see Knowledge Base article 169790, "How to Troubleshoot Basic TCP/IP Problems" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=169790).
•	Destination domain is unreachable   A message cannot reach its final destination because the SMTP service is unable to determine the MX record that is responsible for the domain. When the SMTP domain cannot be reached, the SMTP service informs the message originator in a non-delivery report (NDR) that the destination server for the recipient could not be found in DNS. This error can also appear if an incorrect address space of type SMTP has been assigned to one or more SMTP connectors. Use Exchange System Manager or the WinRoute tool to verify the message routing topology.
•	SMTP protocol errors   Protocol errors occur when the remote SMTP host responds to the local SMTP host's EHLO command with a 500-level error (for example, because the remote host does not support Extended SMTP) or when SMTP commands are out of sequence (for example, attempting MAIL FROM before EHLO). If a protocol error is detected, the sending system will QUIT the connection and report this with an NDR indicating that the remote SMTP server cannot handle the protocol. To see why a remote SMTP server rejects protocol requests, enable SMTP logging for the virtual server or use Network Monitor to trace the network communication. To activate SMTP logging, on the virtual server's General tab, select Enabling logging, and specify the logging format you prefer under Active log format.
•	SMTP address space is not configured for inbound message transfer   You must identify the SMTP address space of your Exchange organization as inbound to reach Exchange 2003 users from the Internet or another SMTP messaging system. For example, if your SMTP address is administrator@fourthcoffee.com, and fourthcoffee.com is not identified as an inbound address space, messages from the Internet addressed to administrator@fourthcoffee.com will not reach your mailbox. To verify that the Exchange organization is configured correctly, in Exchange System Manager, open Default Recipient Policy in the Recipient Policies container, and then switch to the E-Mail Addresses tab. Verify that the SMTP address generation rule contains the correct domain information. If the address information differs from your requirements (for example, if @contoso.com is specified for the Exchange organization, and you also need @fourthcoffee.com), create an additional SMTP address generation rule and ensure that the This Exchange Organization is responsible for all mail delivery to this address check box is selected. For more information about setting up SMTP domains for inbound message transfer, see Knowledge Base article 260973, "Setting Up SMTP Domains for Inbound and Relay E-Mail in Exchange 2000 Server and Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=260973).
•	Loop-back is detected   If you have multiple SMTP virtual servers configured on your Exchange server, ensure that they serve unique incoming ports and also that the outgoing SMTP port configuration is valid to avoid looping between local virtual servers. Ensure that if you have configured multiple virtual SMTP servers on your bridgehead server, none are set to All Unassigned in the IP address list on the General tab of the virtual server. If you are using SMTP connectors, you should also ensure that no SMTP connectors exist that have the address space of the local organization. If you must share the SMTP address space of the local organization with another messaging system, ensure that you forward all messages to specified smart hosts. Do not select Use DNS to route to each address space on this connector in your SMTP connector configuration. For detailed step-by-step procedures for configuring an SMTP connector, see Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System."

Testing Messaging Connectivity

To test messaging connectivity, send e-mail messages to an Exchange user from an Internet messaging system (for example, Microsoft Hotmail®). You can specify the SMTP address for an Exchange recipient in Active Directory Users and Computers when you display the properties of the user account and switch to the E-mail Addresses tab. Remember to reply to the test message, and ensure that you receive the reply in Hotmail to verify that message routing works in both directions.

You can also use Telnet.exe to quickly test inbound message transfer to an Exchange 2003 recipient, as outlined in Knowledge Base article 153119, "Telnet to Port 25 to Test SMTP Communication" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=153119).

Examining SMTP Message Flow

The SMTP service consists of the following internal components, which handle message transfer between SMTP hosts and Internet-based e-mail clients on one side and Exchange 2003 on the other side:

Figure 5.11 shows how messages pass through the components of the SMTP service.

 

Figure 5.11   Message flow through the SMTP transport engine of an Exchange 2003 server

 

Check the SMTP message flow in the following order:

Top of page

Troubleshooting Directory Synchronization

Exchange System Manager is a helpful tool for troubleshooting directory synchronization problems. You can use this tool to trigger manual synchronization cycles and full reloads, which is a recommended first action if you discover that address information in Active Directory or the non-Exchange messaging system is incomplete or missing. Triggering a synchronization cycle is also a good idea after you apply a configuration change to determine whether you successfully solved the problem.

Directory synchronization issues can be classified as follows:

Communication with Active Directory

Both Connector for Lotus Notes and Connector for Novell GroupWise rely on the same directory synchronization architecture to communicate with Active Directory. As shown in Figure 5.12, the LSDXA process is responsible for handling the actual directory synchronization processes. Lsdxa.exe resides in the \Program Files\Exchsrvr\Bin directory and is started automatically when you start the Microsoft Exchange Connector for Lotus Notes or Microsoft Exchange Connector for Novell GroupWise service in the Services tool.

Tip :

You can use Task Manager to verify that Lsdxa.exe is running on your bridgehead server. When the connector service is started, Lsdxa.exe is listed on the Processes tab.

 

Figure 5.12   The Exchange 2003 directory synchronization architecture

 

The LSDXA process is responsible for parsing the Exchconn.ini file and loading the appropriate subprocesses into memory to communicate with Active Directory and the non-Exchange directory. To communicate with Active Directory, Lsdxa.exe starts the Microsoft Exchange Server DX Agent (DXAMEX), which is implemented in a dynamic-link library (DLL) called Dxamex.dll.

DXAMEX communicates with Active Directory through Active Directory Service Interfaces (ADSI). DXAMEX extracts the recipient information from the export containers that you specified in the connector configuration and places the data, in the form of a temporary file in message interchange format (MIF), into the \Program Files\Exchsrvr\Conndata\Temp directory. The file name depends on the system with which you are synchronizing recipient information (Table 5.4). In the other direction, the DXAMEX process seeks an MIF file named Dxamex.txt, which it processes to place recipient information into the import container that you specified in the connector configuration.

Note :

If you want to examine the communication between the DXAMEX process and Active Directory, click the Diagnostics Logging tab for your bridgehead server, and then select the MSExchangeADDXA service. From the list of categories, select LDAP Operations and then set the logging level to Maximum. Remember to set the logging level back to the default setting of None after you complete a directory synchronization cycle. Otherwise, you might quickly fill the application event log with a very large number of entries.

Communication with the Lotus Domino Directory

To communicate with Lotus Domino, the LSDXA process starts the Lotus Notes DX Agent (DXANOTES), which is implemented in a dynamic-link library (DLL) named Dxanotes.dll. This file resides in the \Program Files\Exchsrvr\Bin directory. The DXANOTES process parses the Dxanotes.txt file, processes the addresses, and places them in the target directory on the Lotus Domino server. To communicate with Lotus Domino, DXANOTES uses the Lotus Notes client API.

DXANOTES also performs the directory synchronization from Lotus Notes to Active Directory. The process uses the Lotus Notes client API to read the Lotus Domino directory and writes the recipient information into the Dxamex.txt file in the \Program Files\Exchsrvr\Conndata\Temp directory.

Note :

If you want to examine the processing performed by DXANOTES, click the Diagnostics Logging tab for your bridgehead server, and then select the LME-NOTES service. From the list of categories, select Notes Directory Synchronization and then set the logging level to Maximum. Remember to set the logging level back to the default setting of None after you complete a directory synchronization cycle.

Communication with the Novell GroupWise Directory

Directory synchronization with Novell GroupWise follows a similar pattern. However, instead of DXANOTES, the LSDXA process starts the Novell GroupWise DX Agent (DXAGWISE), which is implemented in a DLL named Dxagwise.dll. This file resides in the \Program Files\Exchsrvr\Bin directory.

DXAGWISE communicates with Novell GroupWise by means of the Novell GroupWise API Gateway and admin messages. DXAGWISE reads the Dxagwise.txt file, processes the recipient information, and places an admin message into the API Gateway directory (subdirectory API_IN) to perform the update operation (add, modify, or delete recipient objects) in the Novell GroupWise directory. The admin message is placed in the \Program Files\Exchsrvr\Conndata\Gwrouter\Togwise directory, and the Router for Novell GroupWise service transfers this message to the API Gateway's API_IN directory. The following is an example of an admin message to update recipient objects in the Novell GroupWise directory:

WPC-API= 1.2; 
Msg-Type= Admin; 
DS-External-Post-Office= 
    Operation= Add; 
    Domain= EXCHANGE; 
    Post-Office= FIRST ADMINISTRATIVE GROUP; 
    Time-Zone= gmt; 
    ; 
DS-User= 
    Operation= Modify; 
    Visibility= System; 
    Domain= Exchange; 
    Post-Office= First Administrative Group; 
    Object= Administrator; 
    Last-Name= \; 
    First-Name= Administrator; 
    Description= Administrator; 
    Account-ID= \; 
    Title= \; 
    Department= \; 
    Phone= \; 
    Fax= \; 
    Network-ID= \; 
    User-Def-5= Microsoft Exchange Connector for Novell GroupWise; 
    ; 
-END-

In the opposite direction, DXAGWISE places a request (this time for a list of GroupWise users) in the form of an admin message in the \Program Files\Exchsrvr\Conndata\Gwrouter\Togwise directory. The Router for Novell GroupWise service transfers this message into the API_IN directory on the NetWare server. The API gateway, the GroupWise MTA, and the Novell GroupWise Post Office Agent handle the request, and return results in the form of an e-mail message. The API gateway places the results into the API_OUT directory in the form of an .api file. The Router for Novell GroupWise service retrieves this file and places it into the \Program Files\Exchsrvr\Conndata\Gwrouter\Dirsync directory. DXAGWISE receives the recipient information from there and writes updates or the complete list (Full Load) to Dxamex.txt.

The following is an example of an admin message to request directory information from the Novell GroupWise directory:

WPC-API= 1.2;
Msg-Type= Admin;
-GET-DIRECTORY-
-END-

Note :

To examine the content of Novell GroupWise admin messages, enable message archiving as explained earlier in the section "Troubleshooting Novell GroupWise Connectivity." You can then find the request files in the \Program Files\Exchsrvr\Conndata\Gwrouter\Archive\Dirsync and \Program Files\Exchsrvr\Conndata\Gwrouter\Archive\ToGwise directories. In addition, if you want to examine the processing performed by DXAGWISE, display the Diagnostics Logging tab for your bridgehead server, and then select the LME-GWISE service. From the list of categories, select GroupWise Directory Synchronization and then set the logging level to Maximum. Remember to set the logging level back to the default setting of None after you complete a directory synchronization cycle.

Top of page

Troubleshooting Calendar Connectivity

The synchronization of free/busy information between Exchange 2003 and Lotus Notes or Novell GroupWise relies on hidden free/busy system folders in the Exchange store. Exchange 2003 maintains a separate free/busy folder for each administrative group in an organization. As Exchange users create appointments in their calendars, their Outlook clients update the users' free/busy information in the free/busy folder, so that other Exchange users who are scheduling meetings with a user can check that user's availability. When you add recipient objects for Lotus Notes or Novell GroupWise users to Active Directory by way of directory synchronization, their free/busy information can also be stored in the free/busy system folder.

Note :

It is a good idea to increase the level of event logging for Calendar Connector in Exchange System Manager if you are interested in examining the individual processes involved in free/busy updates. Select MSExchangeCalCon from the Services list on the Diagnostics Logging tab, and then select Request from Partner, Request to Partner, Response from Partner, Response to Partner, Connection, General, and Housekeeping from the Categories list. Set the logging level to Maximum to obtain the most detailed information. Remember to reapply the default setting of None after you finish testing the connector.

Troubleshooting Free/Busy Lookups to and from Exchange 2003

Calendar Connector updates the free/busy information for non-Exchange users when an Exchange user requests the information. First, Calendar Connector intercepts the request and checks for existing free/busy records in the system folder. If the record has been updated within the time frame you specify under Maximum age in minutes of foreign free/busy data in Exchange that can be used without querying the foreign calendar in the Calendar Connector configuration, Calendar Connector returns this data to the Outlook client immediately. Otherwise, Calendar Connector uses the NOTESCAL or GWISECAL component to send a request for free/busy data to the non-Exchange system (Figure 5.13).

If the non-Exchange system responds within the period of time specified under Maximum number of seconds to wait for response from foreign calendars in the Calendar Connector configuration, the data is written to the target user's free/busy record in the Exchange free/busy folder. Exchange 2003 then returns this information to the Outlook client. However, if the non-Exchange system does not respond within the allowed time frame (or if Calendar Connector is not running), Exchange 2003 returns the existing data from the free/busy record to the client without performing an update operation first.

Sometimes responses from the non-Exchange system come in late. For example, the non-Exchange system might not respond quickly enough due to a performance problem. When responses come in late, Exchange 2003 returns the existing data to the Outlook client, and when the new data is finally received, Calendar Connector updates the free/busy public record for the user. The updated information is not returned to the Outlook client.

Note :

include the most recent updates or that more up-to-date information could be obtained with a subsequent query.

 

Figure 5.13   Performing free/busy lookups for Lotus Notes or Novell GroupWise users

 

The following are typical Calendar Connector issues related to Exchange 2003:

Troubleshooting Free/Busy Lookups to and from Lotus Notes

NOTESCAL, an internal component within Calendar Connector, is responsible for free/busy communication with Lotus Notes (Figure 5.13). NOTESCAL is implemented in a DLL called Notescal.dll, which resides in the \Program Files\Exchsrvr\Bin directory. NOTESCAL communicates with Lotus Domino through the Lotus Notes client API to transfer requests for Lotus Notes free/busy information to the Lotus Notes Schedule Manager task. Schedule Manager is a task running on the Lotus Domino server that manages a Notes database called busytime.nsf. The busytime.nsf database holds free/busy information for all of the users on the server and for resources, such as conference rooms, identified in the server's public address book.

The following processes are involved when performing free/busy lookups from Exchange 2003:

The following processes are involved when performing free/busy lookups from Lotus Notes:

Note :

Because Lotus Notes identifies all Exchange users as belonging to a foreign domain, all requests for Exchange free/busy information are received from the Lotus Notes Calendar Connector task.

Calendar Connector Issues

The following are typical Calendar Connector issues related to Lotus Notes/Domino:

Enabling Detailed Logging on Lotus Domino

It is difficult to locate problems that are encountered when Lotus Notes users try to access free/busy information for Exchange users, because most of the processes are handled by tasks that are running on the Lotus Domino server. It might be a good idea to enable debug logging for the Lotus Domino server to collect helpful troubleshooting information.

To enable debug logging for calendar processes on the Lotus Domino server, perform the following steps:

debug_sched_all=1 

After restarting the Lotus Domino server, all Lotus Notes Calendar Connector and Exchange Calendar Connector activities are reported to the server console. In addition, you can save the information in an output file. To do this, you must the set the DEBUG_OUTFILE variable in the server's Notes.ini file. For example, you can type the following line to write all console messages to a file named output.txt in the root directory: DEBUG_OUTFILE=C:\output.txt. You must restart the Lotus Domino server for the changes to take effect. After the server reinitializes, all messages, as well as debugging information, are written into this file. This can involve a high volume of data. Debugging affects the performance of your Lotus Domino server. You should specify the debugging parameters only in a troubleshooting situation.

Troubleshooting Free/Busy Lookups to and from Novell GroupWise

Novell GroupWise servers can route calendar queries anywhere within the Novell GroupWise network, so you can have one Calendar Connector handling all free/busy requests between Exchange 2003 and Novell GroupWise. As shown in Figure 5.13, the GWISECAL component handles this communication. GWISECAL is implemented in a DLL named Gwisecal.dll, which resides in the \Program Files\Exchsrvr\Bin directory. GWISECAL relies on Connector for Novell GroupWise, which means that if message transfer and directory synchronization work properly, free/busy requests will most likely be transferred correctly as well.

The following processes are involved when performing free/busy lookups from Exchange 2003:

WPC-API= 1.2;
MSG-TYPE= Search;
Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51;
From= 
    WPD= CONTOSO_DOM; 
    WPPO= Exchange Gateway; 
    WPU= Microsoft System Attendant; 
    CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant; ; 
To= 
    WPD= CONTOSO_DOM; 
    WPPO= CONTOSO_PO; 
    WPU= FrankM; 
    CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM; ; 
Begin-Time= 2/12/2003 21:28;
End-Time= 31/1/2004 21:28;
-END-

WPC-API= 1.2; 
Header-Char= T50; 
Msg-Type= SEARCH; 
Orig-Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51; 
To= 
    CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant; 
    ;
Busy-For= 
        CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM; 
Busy-Report=  
    Start-Time= 11/12/03 17:00; 
    End-Time= 12/12/03 8:00; , 
    Start-Time= 12/12/03 17:00; 
    End-Time= 15/12/03 8:00; , 
    Start-Time= 15/12/03 17:00; 
    End-Time= 16/12/03 8:00; , 
    Start-Time= 16/12/03 17:00; 
    End-Time= 17/12/03 8:00; , 
    Start-Time= 17/12/03 17:00; 
    End-Time= 18/12/03 8:00; , 
    Start-Time= 18/12/03 17:00; 
    End-Time= 19/12/03 8:00; , 
    ;
Send-Options= None; 
-END-

The following processes are involved when performing free/busy lookups from Novell GroupWise:

Note :

GroupWise users must have a visibility setting of System or higher to receive calendar information from Exchange.

Calendar Connector Issues

The following are issues that you might encounter when synchronizing free/busy information between Exchange 2003 and Novell GroupWise:

WPC-API= 1.2;
MSG-TYPE= Search;
Msg-ID= FB-PROBE:2003.12.3.6.8:2003.12.3.6.8:2003.12.3.6.8.17;
From= 
    WPD= CONTOSO_DOM; 
    WPPO= Exchange Gateway; 
    WPU= FB-PROBE; 
    CDBA= CONTOSO_DOM.Exchange Gateway.FB-PROBE; ; 
To= 
    WPD= CONTOSO_DOM; 
    WPPO= Exchange Gateway; 
    WPU= FB-PROBE; 
    CDBA= CONTOSO_DOM.Exchange Gateway.FB-PROBE; ; 
Begin-Time= 3/12/2003 6:8;
End-Time= 3/12/2003 6:8;
-END-

WPC-API= 1.2; 
Header-Char= T50; 
Msg-Type= SEARCH; 
From-Text= CONTOSO_DOM.Exchange Gateway.FB-PROBE; 
From= 
    WPD= CONTOSO_DOM; 
    WPPO= Exchange Gateway; 
    WPU= FB-PROBE; ; 
To= 
    WPD= CONTOSO_DOM; 
    WPPO= Exchange Gateway; 
    WPU= FB-PROBE; 
    WPPONUM= 1; 
    WPUNUM= 1; 
    CDBA= 0001:0001; ; 
All-To= 
    WPD= CONTOSO_DOM; 
    WPPO= Exchange Gateway; 
    WPU= FB-PROBE; 
    WPPONUM= 1; 
    WPUNUM= 1; ; 
Msg-Id= 3FCD7DD9.2A0A.000B.000; 
To-Text= CONTOSO_DOM.Exchange Gateway(FB-PROBE); 
Date-Sent= 2/12/03 22:08; 
Send-Options= None; 
Status-Request= None; 
Begin-Time= 3/12/03 6:08; 
End-Time= 3/12/03 6:08; 
-END-

Top of page

Troubleshooting the Exchange Migration Wizard

The Exchange Migration Wizard is the primary tool for migrating users and data from non-Exchange messaging systems to Exchange 2003. As explained in Chapter 1, the migration process consists of two key phases:

Troubleshooting the Data Extraction Process

The following are typical problems that prevent a successful extraction of data from the source system using the Exchange Migration Wizard:

Troubleshooting the Data Import Process

The following are typical problems that can prevent the successful import of data into an Exchange 2003 organization using the Exchange Migration Wizard:

! CodePage
1252
! HeaderLine
Filename,Filetype
Directory.PRI,Primary
00000001.PRI,Primary
00000001.SEC,Secondary
00000002.PRI,Primary
00000002.SEC,Secondary