Exchange 2003 Interoperability And Migration Guide

Exchange Server 2003 Interoperability and Migration Guide Last Reviewed: Product Version: Reviewed By: Latest Content: Author:

May 2004 Exchange Server 2003 Exchange Product Development www.microsoft.com/exchange/library Kay Unkroth

Exchange Server 2003 Interoperability and Migration Guide

Kay Unkroth

Published: May 2004 Applies To: Exchange Server 2003

Copyright Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.  2004 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, ActiveX, Hotmail, Microsoft Press, Outlook, SharePoint, Visual Basic, Windows, Windows NT and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Acknowledgments Project Editor: Lindsay Pyfer Contributing Writers: Randy Treit Contributing Editors: Cathy Anderson, Amy Groncznack, Camilla Paynter Technical Reviewers: Kahren Allakhverdyan, James Boldman, Max Ciccotosto, Paul Ford, Dirk Hamstra, Brandon Hoff, Alan Malmberg, Julie Norberg, Josh Rice, Ed Thornburg, Ashley Webb, Gwen Zierdt Graphic Design: Kristie Smith Production: Joe Orzech, Sean Pohtilla

Table of Contents

Exchange Server 2003 Interoperability and Migration Guide....................1 Exchange Server 2003 Interoperability and Migration Guide....................2 Table of Contents........................................................................i Introduction...............................................................................6 What Will You Learn from This Guide?.................................... ...................6 Who Should Read This Guide?............................................................ .......7 Terminology ................................................................................ ..............7 What Technologies Does This Guide Cover?..................................... .........7 How Is This Guide Structured?.............................................................. .....8

Chapter 1.................................................................................................10 Understanding Interoperability and Migration........................10 Assessing and Documenting the Existing Messaging Environment........11 Documenting the Messaging Infrastructure............................................... .........11 Preparing Infrastructure Diagrams.............................................................. ........12 Assessing the Messaging Infrastructure................................ .............................13 Developing an Interoperability and Migration Strategy...........................17 Single-Phase Migration.............................................................. .........................18 Multiphase Migration.............................................................. ............................19 Long-Term Coexistence................................................................ .......................20 Performing a Single-Phase Migration.................................................. .....20 Migration Tools.......................................................................................... ..........22 Migrating Recipient Information...................................................................... ....25 Migrating User Data and Calendar Information..................................................36 Migrating Workgroup and Workflow Applications...............................................37 Performing a Multiphase Migration................................................... .......38 Preserving Message Paths................................................................................. ..41 Synchronizing Directory Information................................................................... 46 Synchronizing Calendaring Information..................................................... .........48 Getting Started with Interoperability and Migration................................49

Chapter 2.................................................................................................50 Migrating from Lotus Notes/Domino Messaging Infrastructures50 Understanding Interoperability Between Exchange and Lotus Domino...51 Message Conversion and Transfer.............................................. ........................51 Directory Synchronization............................................................................ .......56 Calendar Synchronization..................................................................... ..............58

ii Exchange Server 2003 Interoperability and Migration Guide

Implementing Exchange to Lotus Notes/Domino Connectivity................61 Implementing Multiple Connector Instances.................................................. .....67 Specifying Routable Lotus Domino Domains......................................................67 Configuring Directory Synchronization ...................................... .............68 Implementing Calendar Connectivity.................................. ....................70 Migrating from Lotus Domino to Exchange Server 2003 ........................74 Message Conversion Issues........................................................... .....................77

Chapter 3.................................................................................................79 Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures.........................................................................79 Understanding Interoperability Between Exchange and Novell GroupWise80 Message Conversion and Transfer ............................................ .........................81 Directory Synchronization............................................................................ .......87 Calendar Synchronization..................................................................... ..............89 Implementing Exchange to Novell GroupWise Connectivity....................92 Implementing Multiple Connector Instances.................................................. .....97 Specifying Routable Novell GroupWise Domains................................................98 Configuring Directory Synchronization ...................................... .............99 Implementing Calendar Connectivity................................. ...................101 Migrating from Novell GroupWise to Exchange Server 2003 ................105 Message Conversion Issues.......................................................... ....................107 Migrating Local Archives..................................................................... ..............108 Migrating Personal Address Books.................................................... ................109 Migrating Personal Dictionaries ............................................. ..........................109 Migrating Client Rules and Proxy Access......................................................... ..110 Migrating Shared Folders .................................................................. ...............110 Migrating External Entities .......................................................................... .....110

Chapter 4...............................................................................................111 Interoperating with and Migrating from Other Non-Exchange Messaging Systems.................................................................................111 Understanding Interoperability Between Exchange 2003 and Non-Exchange Messaging Systems................................................................... ............112 Message Transfer and Conversion............................................. .......................114 Directory Synchronization........................................................................... ......123 Calendar Integration........................................................................... ..............129 Implementing Messaging Connectivity.................................................132 Implementing SMTP Connectivity.............................................. .......................134 Implementing X.400 Connectivity.................................................................. ...137 Implementing Multiple Connector Instances................................................. ....138 Implementing Directory Synchronization .............................................139 Implementing Calendar Interoperability.......................................... ......148 Migrating from a Non-Exchange Messaging System to Exchange Server 2003 .. . .150 Preparing for a User Migration....................................................... ...................151 Performing an Internet Mail Migration to Exchange 2003.................................152

Table of Contents iii

Chapter 5...............................................................................................156 Troubleshooting Interoperability and Migration Issues.........156 Understanding Troubleshooting in Interoperability and Migration Projects156 Troubleshooting Tools......................................................... ..............................157 Where to Get Help.................................................................. ..........................161 Troubleshooting Messaging Connectivity..............................................161 Troubleshooting Message Routing Problems............................................ .........162 Troubleshooting Lotus Notes Connectivity........................................ ................163 Troubleshooting Novell GroupWise Connectivity..............................................170 Troubleshooting X.400 Connectivity..................................... ............................179 Troubleshooting SMTP Connectivity................................................... ...............185 Troubleshooting Directory Synchronization...........................................191 Communication with Active Directory...................................................... .........192 Communication with the Lotus Domino Directory.......................................... ...196 Communication with the Novell GroupWise Directory......................................196 Troubleshooting Calendar Connectivity..................................... ............198 Troubleshooting Free/Busy Lookups to and from Exchange 2003.....................198 Troubleshooting Free/Busy Lookups to and from Lotus Notes...........................200 Troubleshooting Free/Busy Lookups to and from Novell GroupWise.................202 Troubleshooting the Exchange Migration Wizard................................. ..207 Troubleshooting the Data Extraction Process............................................... .....207 Troubleshooting the Data Import Process.........................................................208

Appendixes ...........................................................................................210 Appendix A.............................................................................................211 Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality........................................................211 Preparing the Lotus Domino Environment................................ .............211 Prerequisites................................................................................ .....................212 Installing and Configuring Connector for Lotus Notes...........................219 Prerequisites................................................................................ .....................219 Configuring Directory Synchronization ................................... .........................226 Installing and Configuring Calendar Connector in a Lotus Domino Environment ........................................................................................................................ ..231 Migrating from Lotus Domino to Exchange 2003.................................... ..........239

Appendix B.............................................................................................253 Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality........................................................253 Preparing the Novell GroupWise Environment...................................... .253 Prerequisites................................................................................ .....................253 Installing and Configuring Connector for Novell GroupWise..................265 Prerequisites................................................................................ .....................265 Configuring Directory Synchronization ..................................... ............270 Prerequisites................................................................................ .....................270

iv Exchange Server 2003 Interoperability and Migration Guide

Installing and Configuring Calendar Connector in a Novell GroupWise Environment ......................................................................................... .....................275 Prerequisites................................................................................ .....................275 Migrating from Novell GroupWise to Exchange Server 2003.................280 Prerequisites................................................................................ .....................280

Appendix C.............................................................................................291 Configuration Procedures for Migrating from a Non-Exchange Messaging System................................................................291 Configuring an SMTP Connector in Exchange 2003............................... 291 Prerequisites................................................................................ .....................291 Configuring X.400 Connectivity in Exchange 2003...............................300 Prerequisites................................................................................ .....................301 Performing Semi-Automated Directory Synchronization ......................309 Prerequisites................................................................................ .....................309 Migrating from an Internet Messaging System to Exchange Server 2003317 Prerequisites................................................................................ .....................317

Appendix D............................................................................................326 Batch File and Command Line Migrations.............................326 Command Line Reference....................................... ..............................326 Control File Parameters.......................................... ...............................327 Sample Control Files................................................................. .............336

Appendix E.............................................................................................341 Terminology...........................................................................341 Appendix F.............................................................................................344 Resources..............................................................................344 Resources Cited in This Guide............................................. ..................344 Exchange Server 2003................................................................................. .....344 Additional Resources........................................................... ..................346 Exchange Server 2003................................................................................. .....346 Windows Server 2003....................................................................... ................347 Exchange 2000 Server................................................................................. .....347

Appendix G............................................................................................348 Accessibility for People with Disabilities................................348 Accessibility in Microsoft Windows........................................................348 Accessibility Files to Download................................................. ........................348 Adjusting Microsoft Products for People with Accessibility Needs..........349 Free Step-by-Step Tutorials............................................................ ...................349 Assistive Technology Products for Windows.............................................. ........349 Microsoft Documentation in Alternative Formats................................. ..350 Microsoft Services for People Who Are Deaf or Hard-of-Hearing...........350 Customer Service........................................................................................... ...351 Technical Assistance...................................................................... ...................351

Table of Contents v

Exchange 2003.................................................................................... ..351 Outlook Web Access......................................................................................... .351 Getting More Accessibility Information....................................... ...........352

Introduction

This guide was created to help messaging administrators and consultants to connect and migrate nonExchange messaging systems to Microsoft® Exchange Server 2003. It describes the process by which you design an efficient Exchange 2003 interoperability and migration strategy. It includes prerequisites and actual procedures for connecting Exchange 2003 to common non-Exchange messaging platforms, including, but not limited to, Lotus Notes (and Lotus Domino) and Novell GroupWise. Connector components including Exchange Connector for Lotus Notes, Exchange Connector for Novell GroupWise, Exchange Calendar Connector, and general connectors based on SMTP and X.400 are described. The Exchange Migration Wizard, the fundamental tool for migrating user data, is discussed at length. There is also a troubleshooting chapter to consult if you encounter issues with interoperability and migration. This guide is designed to be both a quick reference and a hands-on resource for a variety of interoperability and migration scenarios, so that you can read the sections that interest you and skip the others. For example, if you are interested in a migration from Novell GroupWise to Exchange 2003, you can skip the chapter about migrating from Lotus Notes/Domino. However, if you are a system consultant who specializes in migrating all non-Microsoft messaging platforms to Exchange 2003, you might find it worthwhile to read this guide from start to finish.

What Will You Learn from This Guide? You will find detailed answers to the following questions in this guide: •

What is the fastest route to a consolidated Exchange 2003 organization?

•

Which migration strategy is most suitable for my company?

•

What prerequisites are necessary for a successful migration to Exchange 2003?

•

What are the individual stages for connecting my existing messaging system to my new Exchange 2003 organization?

•

How do I synchronize recipient information between the Active Directory® directory service and other directory services?

•

How can my Lotus Notes/Domino or Novell GroupWise users share calendaring information with Exchange 2003 users?

•

How can I use the Exchange Migration Wizard to migrate private and public user data and directory information?

•

What are the best approaches to troubleshooting problems with connectivity, directory synchronization, or the Exchange Migration Wizard?

Introduction 7

Who Should Read This Guide? This guide is for messaging administrators and consultants who plan to migrate an existing messaging environment to Exchange 2003. Migration often includes an element of interoperability with foreign messaging systems. Therefore, system integrators who are preparing to connect Exchange 2003 to nonExchange messaging systems but are not planning to migrate to Exchange 2003 will also find valuable information in this guide. The following professionals will obtain the maximum benefits from this guide: •

Application service providers (ASPs) who want to migrate their messaging system to Exchange 2003.

•

IT architects who design and deploy Exchange 2003 in environments where a non-Exchange messaging system is already in place.

•

IT consultants who assist customers in migrating from non-Exchange messaging systems to Exchange 2003.

•

Messaging and system administrators who are responsible for implementing and managing messaging technology.

Terminology Before reading this guide, familiarize yourself with the terms contained in Appendix E, "Terminology." For additional information about terminology, see the Exchange Server 2003 Glossary (http://go.microsoft.com/fwlink/?LinkId=24625).

What Technologies Does This Guide Cover? It is assumed that readers of this guide are familiar with the key concepts and features of Exchange 2003 and Microsoft Office Outlook® 2003. Readers must also be comfortable with planning and designing an Exchange 2003 organization, as outlined in Planning an Exchange Server 2003 Messaging System (http://go.microsoft.com/fwlink/?LinkId=21766). This guide covers the following Exchange 2003 components: •

Exchange Connector for Lotus Notes, for connecting an Exchange 2003 organization to an existing Lotus Domino/Notes environment and synchronizing directories.

•

Exchange Connector for Novell GroupWise, for connecting an Exchange 2003 organization to an existing Novell GroupWise environment and synchronizing directories.

•

Exchange Calendar Connector, to allow Exchange users access to calendar information of Lotus Notes or Novell GroupWise users, and to allow Lotus Notes or Novell GroupWise users access to calendar information of Exchange users.

•

The Exchange 2003 SMTP service and SMTP connector, for connecting an Exchange 2003 organization to an existing Internet-based messaging host.

•

The Exchange Migration Wizard, for migrating user and directory data from Microsoft Mail for PC Networks, Lotus cc:Mail, Lotus Notes, Novell GroupWise, Internet messaging systems, and Internet directories.

8 Exchange Server 2003 Interoperability and Migration Guide

•

Command-line Active Directory tools, for implementing semi-automated directory synchronization, which is useful in various directory synchronization scenarios covered in this guide.

How Is This Guide Structured? This guide is organized in accordance with the processes that you typically follow when replacing a nonExchange messaging system with Exchange 2003. General strategies for migrating messaging systems are covered in Chapter 1. You then can choose a migration chapter that matches your area of interest. If you are involved in a migration from Lotus Notes/Domino, read Chapter 2. If you are migrating from Novell GroupWise, read Chapter 3. Migrations from other non-Exchange messaging system are covered in Chapter 4. As mentioned, you can safely skip chapters because they are independent of each other. Chapter 1 "Understanding Interoperability and Migration" This chapter describes, at a conceptual level, how to accomplish a migration. In a typical migration scenario, you connect Exchange 2003 to an existing messaging system, synchronize the directories and possibly connect calendars, and then migrate the user base. However, under certain conditions, it is possible to migrate an organization all at once, without the element of interoperability. These conditions are described in Chapter 1. Chapter 2 "Migrating from Lotus Notes/Domino Messaging Infrastructures" This chapter serves as a configuration guide for system integrators who must connect Exchange 2003 to a Lotus Notes/Domino environment. It describes how to use Connector for Lotus Notes to implement messaging connectivity and directory synchronization, and how to use Calendar Connector to implement calendar connectivity. Chapter 2 concludes with an explanation of how to use the Exchange Migration Wizard to migrate Lotus Notes users into an Exchange 2003 organization. Chapter 3 "Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures" This chapter is structured like Chapter 2, but is targeted at system integrators who must connect Exchange 2003 to a Novell GroupWise environment. It describes how to install and configure the Novell GroupWise API Gateway and Connector for Novell GroupWise, and how to synchronize directories and implement calendar connectivity. Chapter 3 concludes with an explanation of how to use the Exchange Migration Wizard to migrate Novell GroupWise users to Exchange 2003. Chapter 4 "Interoperating with and Migrating from Other Non-Exchange Messaging Systems" This chapter provides interoperability and migration strategies for non-Exchange messaging systems for which a direct connector component is not available. It describes how to connect Exchange 2003 to any messaging system using a Simple Mail Transfer Protocol (SMTP) connector or an X.400 connector. Neither of these connectors supports directory synchronization, however this chapter shows you how to implement a manual or semi-automated process for synchronizing directories. Chapter 4 concludes with an explanation of how to use the Exchange Migration Wizard to migrate users from various messaging systems to Exchange 2003. Chapter 5 "Troubleshooting Interoperability and Migration Issues" This chapter includes troubleshooting information to help you resolve issues that you might encounter with connectivity or migration. Chapter 5 also discusses troubleshooting strategies related to the Exchange Migration Wizard. Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality" This appendix contains step-by-step procedures to help administrators migrate from Lotus Notes/Domino to Exchange 2003.

Introduction 9

Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality" This appendix contains step-by-step procedures to help administrators migrate from Novell GroupWise to Exchange 2003. Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System" This appendix contains step-by-step procedures to help administrators migrate from non-Exchange messaging systems other than Lotus Notes/Domino and Novell GroupWise to Exchange 2003. Appendix D, "Batch File and Command Line Migrations" The command line references and the batch files provided in this appendix can be used to increase the performance of your migration. To use these references and batch files, you must run the Exchange Migration Wizard from a command prompt. Appendix E, "Terminology" Appendix E contains a list terminology related to interoperability and migration that is used in this guide. Appendix F, "Resources" This appendix contains links to resources that will help you to maximize your understanding of interoperability with and migration to Exchange 2003. Appendix G, "Accessibility for People with Disabilities" This appendix contains information about features, products, and services that make Microsoft Windows® 2000, Windows Server™ 2003, and Exchange 2003 more accessible for people with disabilities.

C H A P T E R

1

Understanding Interoperability and Migration

A messaging migration is a type of deployment in which existing user mailboxes, public folders, and content are moved to another e-mail system. In the context of this guide, migration refers to the process of moving from a non-Exchange messaging system to Microsoft® Exchange Server 2003. This can involve replacing hardware, restructuring the underlying network topology, optimizing the Microsoft Active Directory® directory service, replacing messaging clients on workstations, and more. Many of the planning, design, and deployment steps involved in a migration are the same steps that you take when deploying Exchange 2003 in an environment where there is no pre-existing messaging platform. For example, you must design server hardware, define an administrative and routing group topology for the organization, identify options for resource consolidation, and possibly deploy Microsoft Office Outlook®. In addition to the planning, design, and deployment steps, when you migrate to Exchange 2003, you must ensure that users can continue to communicate with each other during and after the migration. This often requires deployment of connector components between the legacy system and the new Exchange 2003 organization, followed by directory synchronization, so that non-migrated and migrated users have complete address lists that contain all users in the company, no matter which system they actually reside on. Interoperability between the systems might not be necessary, however, if you can move all of your users to Exchange 2003 at once. Migrating from a non-Exchange messaging system to Exchange 2003 typically entails: 1.

Planning and designing the future Exchange 2003 organization. Note For more information about planning, design, and deployment, see Planning an Exchange Server 2003 Messaging System (http://go.microsoft.com/fwlink/?LinkId=21766) and the Exchange Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=21768).

2.

Assessing the existing messaging system to identify connectivity and migration opportunities and documenting its infrastructure.

3.

Developing an interoperability and migration strategy based on your assessment.

4.

Deploying the new Exchange 2003 organization, in whole or in part.

5.

Connecting Exchange 2003 to the legacy messaging infrastructure in a seamless way (that is, connecting the systems and synchronizing their directories).

6.

Deploying Outlook or Microsoft Office Outlook Web Access.

7.

Moving users and porting collaborative applications.

8.

Decommissioning the legacy system.

This chapter focuses on migration-specific concepts. It presents guidelines for documenting and assessing the messaging infrastructure, followed by a discussion of migration strategies. This chapter then describes migration of user data in a single-phase scenario, as well as interoperability issues that you need to plan for in

Chapter 1: Understanding Interoperability and Migration 11

a multiphase migration. The chapter briefly covers Outlook and Outlook Web Access deployment options. Also discussed are typical migration challenges, such as migration of existing workgroup applications, and how to address these challenges.

Assessing and Documenting the Existing Messaging Environment An essential step in preparing an interoperability and migration project is to assess and document the existing messaging environment. You must know where the legacy post offices or servers are located and how many there are. It is important to identify potential gateway or bridgehead servers, which your connectors should use for message transfer and directory synchronization. If your migration affects a substantial number of users who communicate heavily with one another through e-mail, you must designate multiple messaging hosts to use as gateways to build parallel transfer paths and avoid bottlenecks.

Documenting the Messaging Infrastructure You should include the following information in infrastructure documentation: •

Information about the servers that host mailboxes This includes server names and locations, the installed messaging systems, the number of mailboxes, the names of administrators, and any special configuration settings (such as post office passwords and database versions). You might also want to list the administrative tools that are used to manage the systems and their versions.

•

Information about the servers that host collaborative applications and public forums, such as discussion boards This includes server names, locations, and purposes, and the number of users who access the discussion forums and workgroup applications. It is also a good idea to include the names of the administrators and developers who are responsible for those public forums and workgroup applications.

•

The structure of the messaging backbone This includes the wide area network (WAN) and local area network (LAN) topology, central transfer routes and their communication protocols, the names and locations of bridgehead servers, connections to other messaging systems and the Internet, and so on. You might also want to list the names of the administrators who are in charge of the messaging backbone, because you will work with them during your migration to connect Exchange 2003 to the existing messaging infrastructure.

•

The existing directory synchronization topology The directory synchronization topology is a logical arrangement of server resources that is not obvious in the messaging environment. For this reason, it is important to document the directory synchronization topology carefully to obtain a clear understanding of synchronization options that are available. Your documentation should include answers to the following questions: •

Which systems participate in directory synchronization?

•

How many addresses are included in the global address list?

•

How frequently must you perform directory synchronization?

•

Are there dedicated directory synchronization servers, and which servers are they?

12 Exchange Server 2003 Interoperability and Migration Guide

•

Who is responsible for the directory synchronization configuration and maintenance in each location?

•

Are there specific conventions for the global address list structure or custom attributes for directory objects?

•

Do policies and procedures exist to deal with incomplete address lists?

•

Detailed information about backup and restore procedures This includes details about the backup schedule and backup validation policies for the individual messaging resources. You should also include information about the storage location of backup media and product CDs. You will use this information to restore production systems in a computer lab to perform test migrations using real-world data.

•

Information about the client environment This includes the types of messaging clients that are currently in use and their versions, the methods that they use to access mailboxes and public folders (remote or local), and the messaging habits of your users. Document where your users store their messaging data, because migration procedures differ if users store messages on client computers instead of in server-based mailboxes. It is important to document current storage requirements and the number of messages that are generated by the users in each location on a typical business day. Your documentation should provide answers to the following questions: •

Are there unusual or complex workgroup and workflow applications installed on servers or workstations that depend on the existing messaging infrastructure?

•

What are the configuration standards for messaging clients, including hardware, client software, and other messaging or groupware applications?

•

What are the current storage requirements and number of messages generated by the users in each location?

•

What are the hardware standards and operating systems on the workstations in each location?

•

What security technologies, if any, are used to encrypt messages?

•

Who is responsible for end-user support and the configuration of workstations?

Preparing Infrastructure Diagrams It is a good idea to include network diagrams and a graphical representation of your messaging infrastructure in your documentation. Depending on the size of your company, a large diagram showing all of the components might be sufficient, or you can prepare several smaller diagrams that focus on more specific characteristics, such as the global backbone and the arrangement of post offices or messaging hosts in each geographical location. Figure 1.1 shows a sample diagram of a messaging environment (here Microsoft Mail for PC Networks) with two locations and one connection to the Internet. In this example, messages between locations are routed through a central message transfer agent (MTA). Within each location, another MTA performs message delivery. All messages to and from the Internet are routed through SEAPO2, which has a Simple Mail Transfer Protocol (SMTP) gateway that connects the entire messaging environment to the Internet.

Chapter 1: Understanding Interoperability and Migration 13

Figure 1.1 Sample messaging infrastructure Figure 1.2 shows a sample directory synchronization topology that corresponds to the messaging infrastructure illustrated in Figure 1.1. The example is a Microsoft Mail for PC Networks directory synchronization configuration in which NYPO1 acts as a central directory synchronization server. Your configuration will differ if you are using Lotus Notes/Domino, Novell GroupWise, or any other messaging system, but the principle remains the same: a graphical representation provides system consultants and implementers with a quick overview of your topology.

Figure 1.2 Sample directory synchronization topology

Assessing the Messaging Infrastructure A main objective when you assess a messaging infrastructure is to identify connectivity, directory synchronization, and client migration opportunities. For example, in the messaging environment shown in Figure 1.1, SEAPO2 and NYPO1 are good choices for post offices that connect to Exchange 2003 directly, because they are the hub post offices in Seattle and New York. If this company chooses to deploy one Exchange 2003 server in each location, it is a good idea to install a separate connector to SEAPO2 and to NYPO1, respectively. In a subsequent step, the new Exchange 2003 organization can be integrated into the existing directory synchronization topology so that all users can see each other in the global address list. Directory synchronization also ensures that all address lists are updated when groups of users are moved to Exchange 2003 in their locations. Eventually, when all users are in the Exchange 2003 organization, you can

14 Exchange Server 2003 Interoperability and Migration Guide

retire the legacy messaging infrastructure. There is more information about migration strategies and procedures later in this chapter. Your messaging assessment should provide answers to the following important questions: •

Are there any known problems in the current infrastructure that might adversely affect the migration project? There are three potential problems that can occur with your migration: overtaxing of existing connections, transmission problems due to inadequate software components, and inefficient or incorrect message routing. For example, bottlenecks or malfunctioning connectors are indicated when messages accumulate in message queues somewhere on a bridgehead. Non-delivery reports (NDRs) are signs of incorrect message routing. Message loops, another common problem, are created if messages are routed multiple times through the same bridgehead. Exchange 2003 adds trace information to all transferred messages to detect message loops and drop looping messages with a non-delivery report (NDR). However, if multiple messaging systems are included in the message path, the trace information might be lost during message conversion between the systems. In such a case, it is possible for messages to loop indefinitely. The effect can be similar to that of an e-mail flood caused by a worm virus. Therefore, you should review your existing messaging topology carefully to ensure that the implementation of Exchange 2003 does not lead to message loops.

•

Are you planning to consolidate messaging resources when you deploy Exchange Server 2003? Exchange 2003 can support a very large number of mailboxes on a single server, and deployment of fewer but more powerful servers can help to simplify the messaging infrastructure. Identifying which systems you plan to consolidate helps you to determine the number of Exchange servers that you must deploy.

•

Which connectors do you intend to use to connect Exchange Server 2003 to an existing messaging system? Connectors for Lotus Notes and Novell GroupWise are included in the Exchange Server 2003 product package. With the help of Microsoft Exchange 2000 Server or Microsoft Exchange Server 5.5, it is even possible to connect to Microsoft Mail for PC Networks, Lotus cc:Mail, Professional Office System (PROFS) and Systems Network Architecture Distribution Services (SNADS) with a direct connector. If you do not want to deploy Exchange 2000 or Exchange 5.5, or if you are running another messaging system, use X.400 or SMTP to build the e-mail bridge, or check with your vendor to determine if there is an appropriate third-party connector available. Table 1.1 lists the most common messaging systems and corresponding possible connector choices. Table 1.1

•

Messaging systems and preferred gateway connectors

Messaging system

Preferred gateway connector

Lotus Notes/Domino

Microsoft Exchange Connector for Lotus Notes.

Novell GroupWise

Microsoft Exchange Connector for Novell GroupWise.

Microsoft Mail for PC Networks

Microsoft Mail Connector in Exchange 2000 Server.

Lotus cc:Mail

Exchange Connector for Lotus cc:Mail in Exchange 2000 Server.

PROFS and SNADS

Connectors in Exchange Server 5.5.

Other messaging systems

Check with your vendor for available third-party gateways, or use an X.400 or SMTP connector.

Is it necessary to install additional components in the production environment to provide connectivity? This is an important question, because Connector for Lotus Notes and Connector for Novell GroupWise require third-party components, as listed in Table 1.2. Alternatively, if you plan to use

Chapter 1: Understanding Interoperability and Migration 15

an X.400 or SMTP connector, it might be necessary to install a corresponding X.400 or SMTP gateway in the legacy messaging environment. Table 1.2

Additional components required for Exchange messaging connectors

Messaging connector

Additional components and versions

Connector for Lotus Notes

A Lotus Notes release 3 or 4 server or a server running Lotus Domino release 4.5 or later, and a Lotus Notes client release 4 or later

Connector for Novell GroupWise

A Novell GroupWise API Gateway version 4.1 with Novell GroupWise Patch 2 for API

Calendar Connector

A Lotus Notes client release 4 or later, when connecting to Lotus Domino A Novell GroupWise API Gateway version 4.1 with Patch 2, when connecting to Novell GroupWise

•

Is it possible to implement an appropriate gateway connector that supports directory synchronization? All Exchange connectors to non-Exchange messaging systems support automatic directory synchronization. For example, you can use Connector for Lotus Notes to synchronize Active Directory (which is the directory of Exchange 2003) and Domino directories. The same principle applies to Connector for Novell GroupWise. If you are using Exchange 2000 on a bridgehead server, you can also use Exchange Connector for Microsoft Mail for PC Networks and Connector for Lotus cc:Mail to perform automatic directory synchronization with Microsoft Mail for PC Networks or Lotus cc:Mail.

•

If automatic directory synchronization is not supported, is it possible to develop a semi-automated directory synchronization process? Semi-automated directory synchronization is required if you must use an X.400 or SMTP connector or a non-Microsoft gateway product that does not support automatic directory synchronization. Exchange 2003 directory synchronization is performed against Active Directory, which means that you can use low-level Active Directory tools, such as Ldifde.exe and Csvde.exe, to perform semi-automated directory synchronization or bulk export and import operations. Ldifde.exe works with LDAP Data Interchange Format (LDIF) files. Csvde.exe uses comma-separated value (.csv) files. Another alternative is Active Directory Service Interfaces (ADSI) and Collaboration Data Objects for Exchange Management (CDOEXM), which a business solutions developer can use to create a custom directory synchronization tool.

•

What are the average and maximum mailbox sizes in the existing messaging system? Look at the current size of your users' mailboxes. This information is very important when designing the storage capacity of your Exchange servers. At a minimum, the new environment should allow all users to store the same amount of data, or more, in their mailboxes. It is not a good idea to enforce more restrictive mailbox quotas on the new system, because this might prevent users from experiencing the new Exchange 2003 organization as a positive change.

•

What are your users' messaging habits? Your users' messaging habits influence your migration options. For example, if your users download all of their messages from the server to their clients, you cannot migrate their data centrally using migration tools. Users who store their messages locally usually must perform the data migration themselves. Users who encrypt their messages can also affect your migration. Migrating encrypted messages from one system to another requires that each message be decrypted in the source system before migration, because the messages must be converted from native format into Exchange format. Only the correct user can perform the decryption, so you cannot migrate encrypted messages on behalf of your users. Also, if it is not feasible to store sensitive information in non-encrypted form in Exchange 2003, you should not migrate encrypted items.

•

Are the current workstations capable of running the chosen messaging client or clients for Exchange 2003? Usually, the chosen messaging client is Outlook. Outlook requires, at a minimum, a

16 Exchange Server 2003 Interoperability and Migration Guide

233 megahertz (MHz) or faster Intel Pentium processor or equivalent (Pentium III or higher recommended), and between 160 and 190 megabytes (MB) of disk space on a computer running Microsoft Windows® XP. If your workstations cannot support Outlook, because, for example, they run a UNIX operating system, you must find an alternative client solution, such as an Internet client like Outlook Web Access, or use a Windows Terminal Services client, which is a viable option if you want to bring full Outlook functionality to every desktop in your environment. UNIX operating systems often include client software for Windows Terminal Services. •

Is it possible to deploy Outlook in the legacy messaging environment? Messaging migrations are relatively straightforward if your users already work with Outlook. Non-Microsoft vendors, such as IBM Lotus and Novell, provide MAPI transport drivers that support Outlook to some extent (Table 1.3). There might be additional costs for such MAPI drivers. Users on UNIX-based Post Office Protocol version 3 (POP3) or Internet Message Access Protocol Version 4rev1 (IMAP4) hosts have the option to use Outlook through POP3 or IMAP4 MAPI transport services, which are included in Outlook. Table 1.3 drivers

Non-Exchange messaging systems supported through MAPI transport

Messaging connector

Additional components and versions

Lotus Notes

Use Microsoft Outlook 2002 Connector for IBM Lotus Domino to help your users become familiar with Outlook while they continue to work in the Domino environment. Through this connector, your users can use Outlook to access e-mail messages, calendar, address book, and To Do (task) items on Lotus Domino release 5. Alternatively, you can use Lotus iNotes Access 6 for Microsoft Outlook if this connector is already deployed. The Outlook Connector is available for download from http://go.microsoft.com/fwlink/?LinkId=25930.

•

Novell GroupWise

Use Novell GroupWise 5.5 Plug-in for Outlook, but remember that if you want to run the GroupWise client and Outlook on the same computer, they must use different MAPI profiles. Both clients rely on MAPI, but cannot share the same profile.

POP3- or IMAP4-based messaging systems

Use the POP3 or IMAP4 MAPI transport driver. Outlook works with a personal folder (.pst) file to download all messages from the host, and users can use Outlook to manage their personal information on their workstations.

Proprietary messaging systems

Check with your vendor to see if an appropriate MAPI transport driver is available for your messaging system. For example, you can use the Microsoft Mail transport driver, available in the Outlook product package, to work with a mailbox in a Microsoft Mail post office.

Do users require training on Outlook before migration, or is it possible to continue using existing messaging clients and handle end-user training and client deployment after migrating to Exchange 2003? Users who are familiar with Outlook, such as those who already use Outlook for Internet messaging, will find a migration to Exchange 2003 very straightforward. However, novice users might face a steep learning curve, because Outlook offers a comprehensive set of messaging features. You can alleviate this situation by providing appropriate user training. You also have the option to support

Chapter 1: Understanding Interoperability and Migration 17

non-Outlook messaging clients in your Exchange 2003 organization. This is especially true for Internet clients such as Eudora Pro, because Exchange 2003 supports POP3 and IMAP4. Remember, however, that Internet clients are usually not as powerful as Outlook, and this might become a productivity issue for your users. •

Is the user help desk prepared for increased workload related to Exchange 2003 and Outlook? The interoperability and migration phase puts pressure on help desk personnel, because the support call volume increases when users start using their new messaging clients. It is recommended that you dedicate a help desk specialist specifically to Outlook-related questions and that you train this person thoroughly. To maintain productivity in larger organizations, the Outlook task force may consist of a number of experts. You might want to increase the headcount in the help desk department temporarily. It is reasonable to assume that the call level will return to normal within six months after migration is complete.

•

How do you plan to keep management, IT administrators, user help desk personnel, and users updated about migration progress? It is important to keep the people in your organization fully informed about the migration progress. Your users must know when they are scheduled for Outlook training, for example, and IT administrators, user help desk personnel, and management need current information about project progress. It is recommended that you create a detailed communication plan. Many organizations implement a dedicated intranet site to facilitate communication about the migration.

•

What are the options for migrating existing workgroup and workflow applications to Exchange Server 2003? Migrating workgroup applications can be difficult. Workflow solutions often rely on features that are not directly supported in Exchange 2003, such as LotusScript or external data sources. You will probably want to engage a business solutions developer who is skilled at manual application reengineering and workgroup programming using Microsoft Visual Basic® and Exchange application programming interfaces (APIs), such as Windows Management Instrumentation (WMI), Collaboration Data Objects for Exchange 2000 Server (CDOEX), or Microsoft ActiveX® Data Objects (ADO). You should evaluate your existing workgroup and workflow solutions to decide whether you want to migrate them or not. Document the applications that you want to migrate in detail to ensure that your developer is porting them to Exchange 2003 accurately. If you must migrate Lotus Notes applications, consider using Microsoft Exchange Application Analyzer for Lotus Notes and CASAHL Technology, Inc.'s ecKnowledge solution for connecting Lotus Notes and Domino applications and migrating application data. Also, read the technical article Migration and Coexistence of Lotus Notes Applications Using Microsoft Application Services for Lotus Notes (http://go.microsoft.com/fwlink/?LinkId=7467).

Developing an Interoperability and Migration Strategy You can migrate a messaging environment to Exchange 2003 in a single phase or in multiple phases. A third option is long-term coexistence, although this is not a true migration strategy. Note Organizations might choose long-term coexistence for a number of reasons. One such reason might be that it is impossible or too costly to migrate existing workgroup and workflow applications over a short period of time.

Your assessment of the existing messaging infrastructure should give you a clear understanding of your migration options. You can use the flowchart shown in Figure 1.3 as a guide when choosing an appropriate migration strategy for your company.

18 Exchange Server 2003 Interoperability and Migration Guide

Figure 1.3 Developing a migration strategy

Single-Phase Migration Single-phase migration is straightforward. The day before the migration, all users are on a non-Exchange messaging system. The next day, they are all on Exchange 2003, and the legacy system is decommissioned. Existing user data might or might not be migrated. Some organizations reduce migration costs by not transferring existing messages. When this occurs, users must save memos and other important information on their local computers. Most organizations, however, prefer to migrate existing data to avoid lost productivity. The most significant advantages of a single-phase migration to Exchange 2003 are: •

All users are migrated at once, which yields quick results.

•

If you deploy Outlook on all desktops before migration and advise your users to store all messages on their client computers, it is not necessary to move server-based user data to Exchange 2003. After migration, it is necessary only to reconfigure Outlook profiles to connect to Exchange 2003, rather than connecting to the legacy messaging system.

•

There is no need for messaging connectivity between the legacy messaging system and Exchange 2003. You are not required to install or configure an Exchange 2003 connector.

•

Preserving existing e-mail addresses is straightforward, because the new Exchange 2003 messaging system replaces the legacy messaging system.

•

You can establish a new messaging infrastructure that perfectly mirrors the existing recipient information.

The most significant disadvantages of a single-phase migration to Exchange 2003 are: •

The migration of large numbers of users or large amounts of data results in unacceptable downtime.

Chapter 1: Understanding Interoperability and Migration 19

•

You must establish the entire Exchange organization before you migrate users. It is difficult to stage server and client deployments.

•

You cannot control the pace of the migration. You cannot migrate divisions or departments individually, for example.

•

You have limited flexibility. For example, it is not possible to leave a particular group of users on the legacy system for any reason.

Multiphase Migration For a small company with one or two messaging servers, single-phase migration is an advantageous option for migrating to Exchange 2003. However, for larger companies with a more complicated messaging infrastructure, single-phase migration is rarely possible, because these companies typically cannot react quickly enough to issues that can arise in a single-phase migration. Your company might have multiple messaging servers, which might be located in different places. You might have several different messaging clients that connect to messaging systems from multiple locations. It might not be feasible for all of the mailboxes to be migrated to Exchange 2003 and for all of the clients to be reconfigured in one giant step. In these situations, the migration process takes an extended period of time and includes multiple phases. One of the most important issues that you must address in multiphase migrations is interoperability between the messaging systems, because users on the legacy system must be able to exchange messages with users who have already migrated to Exchange 2003. Because users tend to exchange e-mail messages primarily with other users in the same workgroup or department, it is recommended that you migrate users according to workgroup or department. This can help to reduce the number of messages that a messaging connector must transfer from one messaging system to the other. The most significant advantages of a multiphase migration to Exchange 2003 are: •

You can complete the migration in incremental and manageable steps. In a large company, you can migrate departments, business units, or teams at one time. It is recommended that you migrate users who require delegate access to each other's calendars and mailboxes in the same cycle.

•

You can continue to support complex workgroup applications on the legacy system until new versions are available for Exchange 2003. However, it is important to evaluate and test your legacy application's ability to support users with mailboxes in the Exchange 2003 organization.

•

You can migrate heterogeneous messaging environments to Exchange 2003 without consolidating the resources in the old environment before migration.

•

You can minimize risks. If one particular operation in the multiphase migration is not successful, a limited number of people are affected, and you can back out of the operation fairly quickly. If migration of a group of users fails for any reason, users can continue to work with their old mailboxes until you fix the problem.

•

You can minimize the system downtime for messaging users. If you choose to perform the migration during non-business hours, you might be able to nearly eliminate downtime for users.

•

You can synchronize the reconfiguration of the messaging client and end-user training with the migration of mailboxes.

•

You have control over the pace of the migration. You do not need to establish the entire Exchange organization before you migrate users. You can stage server and client deployments according to your migration phases.

The most significant disadvantages of a multiphase migration to Exchange 2003 are: •

Compared to single-phase migrations, multiphase migrations are more time consuming and therefore more expensive.

20 Exchange Server 2003 Interoperability and Migration Guide

•

The computer network experiences an increased amount of data traffic, which results from the need to communicate with users on the legacy messaging system, as well as from directory synchronization and calendar interoperability.

•

The legacy messaging system and the Exchange 2003 organization must interoperate as seamlessly as possible. You must deploy a messaging connector and configure directory synchronization between the systems.

•

You cannot establish a new messaging infrastructure that perfectly mirrors the existing recipient information. Preserving existing e-mail addresses is difficult, because message transfer processes use address information to distinguish the legacy system from the Exchange organization. Therefore, the Exchange organization cannot reuse the address information that already exists in the legacy environment.

•

You must maintain both the legacy messaging system and Exchange 2003 for a period of time.

Long-Term Coexistence Long-term coexistence is essentially a multiphase migration without an end point. After you migrate users to Exchange 2003, you do not decommission the legacy messaging system. Some companies might want to choose this strategy to preserve investments in existing technologies, such as complex business applications that rely on the legacy messaging system. With long-term coexistence, users must work with multiple clients, for example, Outlook to participate in the Exchange 2003 organization and another client (such as Lotus Notes or a Web-based interface) to work with the legacy business application (such as a Lotus Notes solution). Coexistence is costly, support-intensive, and requires administrator knowledge of multiple messaging systems. For this reason, many companies consider standardizing their communication infrastructure on a single messaging system to be a key element in their messaging strategy. Long-term coexistence and interoperability are also required in distributed environments with autonomous sites that use diverse messaging systems that are connected with each other over a corporate messaging backbone or central message switch. If this describes your situation, consult your infrastructure documentation, and collaborate with administrators in charge of the messaging backbone to determine appropriate technologies to connect the new Exchange 2003 organization to the existing infrastructure. Most backbones support X.400 or SMTP, and message switches might even support native Exchange communication protocols.

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

Chapter 1: Understanding Interoperability and Migration 21

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. Important In a single-phase migration, adhere to step-by-step instructions that you have verified in a computer lab.

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

22 Exchange Server 2003 Interoperability and Migration Guide

Figure 1.4 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, Lotus Organizer calendars, .pst files, databases, and so on. The Import/Export feature in Outlook might require additional software on the client computer, such as the program files of Lotus Organizer.

Chapter 1: Understanding Interoperability and Migration 23

•

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. Microsoft provides some Exchange application converters and analyzers for Lotus Notes, but these tools do not eliminate the need for an experienced business solutions developer. Microsoft offers the following application converters: •

Exchange Application Analyzer for Lotus Notes This tool is used to analyze the complexity of Lotus Notes applications. You can use the Application Analyzer to determine the various application components that must be ported to Exchange.

•

Exchange Application Converter for Lotus Notes This tool is used to automate the conversion of Lotus Notes applications to Outlook applications and to migrate existing application data from Lotus Notes to Exchange public folders. The Application Converter retains rich text formatting in migrated data, as well as document attachments, OLE objects, document links, and discussion thread hierarchies.

•

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 http://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.4 lists examples of non-Microsoft migration tools for Exchange 2003. Table 1.4

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

CASAHL Technology, Inc. ecKnowledge

Integrate Exchange and Lotus Notes applications with each other

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

IBM Lotus Enterprise Connector

Map data and schema between Lotus Notes databases and Microsoft SQL Server™ databases and perform data replication

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

24 Exchange Server 2003 Interoperability and Migration Guide

Migration tool

Used to

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, Lotus Notes, Novell GroupWise, IMAP4, Netscape, Eudora/Eudora Pro, Microsoft Outlook Express, and message handling system (MHS), to Exchange

Trilog FlowBuilder XML Edition

Map data and schema using XML between Lotus Notes and SQL Server, and provide flow control between forms and views, and process of business logic

Wingra Technologies Novell GroupWise Migrator and Wingra Technologies Notes Migrator for Outlook

Migrate Novell GroupWise data or Lotus Notes 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. Note As a tool dedicated to extracting and importing data, the Exchange Migration Wizard is not designed to analyze security settings. Consequently, the wizard does not preserve delegate permissions to other mailboxes, Inbox rules, or other special configuration settings that are applied to individual mailboxes. Your users must apply their specific Inbox rules, views, access permissions, and so on to their new mailboxes in the Exchange 2003 organization.

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, Lotus Notes/Domino, 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, a Lotus Notes client, or a Novell GroupWise client installed on the local computer.

Chapter 1: Understanding Interoperability and Migration 25

•

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:

26 Exchange Server 2003 Interoperability and Migration Guide

•

Automated migration Using the Exchange Migration Wizard, you can automatically create mailboxenabled 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 chapter. Note If non-Exchange users send messages to the old addresses of migrated users, NDRs might be generated if you have deleted the old mailboxes from the legacy messaging system after migration. Some messaging systems support auto-forwarding rules. In this case, it might be advantageous to hide migrated mailboxes instead of deleting them and to configure an autoforwarding rule to forward all messages that are sent to the old addresses to the new Exchange mailboxes.

Address Matching Recipient information might already exist in Active Directory before you run the Exchange Migration Wizard because, for example, your Lotus Notes, 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.

Chapter 1: Understanding Interoperability and Migration 27

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 (http://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

28 Exchange Server 2003 Interoperability and Migration Guide

can use Active Directory Users and Computers to mailbox-enable user accounts or mail-enable user accounts, groups, and contacts. Table 1.5 matches typical recipient objects in a non-Microsoft messaging system to corresponding recipient objects in Active Directory. Table 1.5 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), mailboxenable 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 mailenabled public folders.

Chapter 1: Understanding Interoperability and Migration 29

Non-Microsoft messaging system

Exchange 2003 messaging system

Comments

Distribution list

Mail-enabled public Under some circumstances, you might want to configure mailfolder 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>@ to an address format of .@ (for example, [email protected]), 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.%[email protected]). In addition, you can specify how many

30 Exchange Server 2003 Interoperability and Migration Guide

characters to use (for example, %g%[email protected] results in [email protected]). Table 1.6 lists the possible placeholders in address generation rules.

Chapter 1: Understanding Interoperability and Migration 31

Table 1.6

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" (http://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. Note The following code example was written and tested on a domain controller named Server01 with an Exchange server named EX-SRV1 in the domain contoso.com. If you want to test this code on another computer, you must change the LDAP path. The same applies to all other code examples in this chapter.

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," _

32 Exchange Server 2003 Interoperability and Migration Guide

& "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) (http://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" (http://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 -s (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:[email protected] proxyAddresses: SMTP:[email protected] name: Ted sAMAccountName: Ted

Chapter 1: Understanding Interoperability and Migration 33

userAccountControl: 512 userPrincipalName: [email protected] msExchHomeServerName: /o=Exchange/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=EX-SRV1 mailNickname: Ted

Important When you create user accounts with Ldifde.exe and Csvde.exe, ensure that the information specified in your import file applies to your specific environment. Neither Ldifde.exe nor Csvde.exe performs validity checks. For example, it is possible to import msExchHomeServerName information that is not valid, in which case the mailbox is placed on a nonexistent server, and the user cannot participate in the Exchange organization. If this happens, correct the information by modifying the affected attributes through Ldifde.exe, in a manner similar to the procedures outlined in the previous sections.

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 (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 -d "CN=Users,DC=,DC=" (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

34 Exchange Server 2003 Interoperability and Migration Guide

proxyAddresses: SMTP:[email protected] proxyAddresses: X400:c=US;a= ;p=FirstOrg;o=Exchange;s=Ted; proxyAddresses: smtp:[email protected] -

Remember the hyphen between update records and on the last line of your import file. Important Back up your domain controllers and global catalog servers, test your import files in a computer lab, and verify the results carefully before you use Ldifde.exe in your production environment. Using Ldifde.exe with incorrect import settings can corrupt Active Directory and force you to restore Active Directory from backup.

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.

Chapter 1: Understanding Interoperability and Migration 35

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 -d "CN=Users,DC=,DC=". 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:[email protected]", _ "SMTP:[email protected]", _ "X400:c=us;a= ;p=Exchange;o=Exchange;s=updateduser;") oUser.SetInfo

Important As with Ldifde.exe and Csvde.exe, you must thoroughly test your solutions in a computer lab before deploying them in the production environment. Incorrect use of ADSI can corrupt Active Directory and force you to restore Active Directory from a backup. Ensure that you have a functioning backup of your domain controllers and global catalog servers.

36 Exchange Server 2003 Interoperability and Migration Guide

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.

Chapter 1: Understanding Interoperability and Migration 37

•

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.

38 Exchange Server 2003 Interoperability and Migration Guide

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 (http://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.

Performing a Multiphase Migration In a multiphase migration, you use many of the same migration procedures as you do in a single-phase migration. The difference is that you perform these procedures many times. Consequently, many of the strategic questions that you must answer when planning a single-phase migration are also relevant in a multiphase scenario. However, there are several additional issues resulting from the requirement for interoperability that you must address before you migrate users. To ensure a successful migration in multiple phases, you must: 1.

Preserve message paths to maintain uninterrupted message transfer During the migration, users must be able to exchange e-mail with all recipients in the company and with Internet recipients. You must ensure that the messages are transferred to the correct destinations, no matter where the mailboxes of your users reside.

2.

Synchronize directory information to maintain consistent and current address book information When they send e-mail messages, users must be able to choose a recipient from an address list and know that the message will be delivered to the appropriate user. As a result of this requirement, you must maintain accurate user and distribution list information in both messaging directories while you migrate the mailboxes to Exchange 2003.

Chapter 1: Understanding Interoperability and Migration 39

3.

Synchronize calendar information to provide all users with current free/busy information Many companies use the calendaring component in the legacy messaging system as the primary means for scheduling meetings. You must retain this functionality during the migration to Exchange 2003. You must ensure that users can see when other users are available for meetings, and that meeting requests are transferred between the systems.

40 Exchange Server 2003 Interoperability and Migration Guide

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

Figure 1.5 Generic multiphase migration approach

Chapter 1: Understanding Interoperability and Migration 41

Preserving Message Paths Before you migrate any user mailboxes to the Exchange 2003 organization, you must implement a message transfer topology that ensures that messages from internal and external users are delivered correctly. After you have implemented the topology, create test mailboxes or migrate a few test accounts to Exchange 2003 to confirm that message routing works as expected. When you connect Exchange 2003 to an existing messaging infrastructure and preserve message paths, you must find answers to the following questions: 1.

2.

How will you maintain message transfer? You have two options for configuring message routing between the messaging systems: a.

Use one of the Exchange 2003 connectors to route messages, such as Connector for Lotus Notes or Connector for Novell GroupWise. This is recommended for supported legacy messaging systems because these connectors enable message transfer and directory synchronization. By transferring messages through a dedicated connector, you can retain most message properties during the conversion of the message formats from one system to the other. Most types of messages can be sent across the connector. Messages that cannot be mapped to a similar message type in the other system are generally converted to ordinary e-mail messages.

b.

If a direct connector component is not available, consider using an SMTP or X.400 connector to route messages between the two messaging systems. For example, if the existing messaging system already has an SMTP connection to the Internet, you can implement an SMTP connector on an Exchange server and route all messages across this connection. The most significant limitation of the SMTP connector is that it can only transfer messages, but cannot perform directory synchronization. This means that you must implement a semi-automated synchronization mechanism or update directories manually. Implementing an X.400 connector in an environment where both messaging systems support X.400 provides the same benefits and the same limitations as implementing an SMTP connector.

How will you support communication with external users? The second task in maintaining message routing is to ensure that there is no disruption in the delivery of Internet e-mail. As you migrate the existing messaging system to Exchange 2003, you will also migrate the Internet e-mail functionality. You must change the routing to deliver messages from external sources to the mailboxes on Exchange 2003. You have several options to address external communication in a migration scenario: a.

Change the domain name system (DNS) domain name in the SMTP addresses of migrated users Some companies might use the migration as an opportunity to change their DNS domain name. This means that the users in the Exchange 2003 organization will have a different SMTP address than they had in the legacy messaging system. To handle Internet message routing in this environment, configure an SMTP connector on one or more Exchange servers in the organization to send and receive Internet e-mail. The SMTP connector will be responsible for all e-mail delivery for the new SMTP addresses while the current messaging system continues to be responsible for the legacy SMTP addresses (Figure 1.6).

42 Exchange Server 2003 Interoperability and Migration Guide

Figure 1.6 b.

Change the DNS domain name in the SMTP addresses of migrated users and use Address Rewrite for non-migrated users Companies that plan to change their SMTP domain name might want to do so for all users at once, whether they still exist in the legacy environment or are already in the Exchange 2003 organization. You can do this by routing all SMTP messages through Exchange 2003 with Address Rewrite enabled (Figure 1.7). Address Rewrite is a feature that replaces SMTP addresses in messages that are received through SMTP from a legacy system and are destined to the Internet with the respective contacts' primary SMTP address. To use Address Rewrite successfully, you must have a mail-enabled contact in Active Directory for each user in the legacy system, and you must specify for these contact objects the primary SMTP address that you want to use as the reply address in outgoing messages. For more information, consult the Readme file that accompanies the Address Rewrite (Exarcfg.exe) tool. You can download this tool from http://go.microsoft.com/fwlink/?LinkId=25932.

Figure 1.7 c.

Message routing with different domain names

Message routing with Address Rewrite

Preserve the existing external SMTP e-mail addresses and perform SMTP routing for unresolved recipients Changing the DNS domain name during migration might be an option in a business merger, but in most cases companies prefer to use the same SMTP addresses before and after the migration to Exchange 2003, so that communication with customers and business partners can continue as usual. One way to accomplish this is to configure Exchange 2003 to receive all inbound Internet e-mail and then use Exchange 2003 to route messages with unresolved recipients to

Chapter 1: Understanding Interoperability and Migration 43

the legacy messaging system (Figure 1.8). In this configuration, you must ensure that the other messaging system can resolve the recipient or that it generates an NDR for non-existent recipients.

Figure 1.8 Message routing based on unresolved recipients through Exchange 2003 Important Do not configure the legacy messaging system to send messages with unresolved recipients to Exchange 2003. If you do this, messages sent to recipients that cannot be resolved in either system are looped back and forth between the servers. For example, you should not deliver inbound SMTP messages to a legacy system like the one shown in Figure 1.8 and then route unresolved recipients to Exchange 2003 while Exchange 2003 is using the same routing mechanism to deliver SMTP messages to the legacy system. This is why Figure 1.8 shows only outbound messages from the legacy system. Inbound messages arrive first at the Exchange 2003 server.

d.

Preserve the existing external SMTP e-mail addresses and use a central smart host to route incoming messages to the legacy messaging system and Exchange 2003 It is not recommended that you forward messages with unresolved recipients, because it is likely that message loops will be created. It is more straightforward to use a central smart host with a global alias list to preserve external SMTP addresses. If a message is received, the smart host reads the alias list and replaces the recipient information with corresponding internal addresses before the message is routed further (Figure 1.9). This address mapping can be performed for incoming and outgoing messages.

44 Exchange Server 2003 Interoperability and Migration Guide

Figure 1.9 mapping e.

Message routing through a central smart host performing address

Preserve the existing external SMTP e-mail addresses and use the legacy messaging system to route incoming messages to the Exchange 2003 organization If the existing messaging system is connected directly to the Internet for inbound and outbound Internet e-mail, and you deployed a direct connector to Exchange 2003, you can use this connector to route SMTP messages between the two messaging systems (Figure 1.10). To do this, you must first configure directory synchronization so that a native recipient object is created in the non-Exchange directory for each migrated Exchange 2003 user. These recipient objects in the non-Exchange directory might have associated SMTP addresses. If the legacy system receives an inbound message, it converts it into native internal formats, which entails replacing the SMTP address of the recipient with an address that is native to the legacy system. If this address now points to a recipient in the Exchange 2003 organization, the message is routed further across the connector to Exchange 2003. The process is similar for outbound messages. The legacy messaging system receives the message from the Exchange connector, converts the message into Internet format, replaces the native non-Exchange address with a corresponding SMTP address, and then sends the message to its destination on the Internet.

Chapter 1: Understanding Interoperability and Migration 45

Figure 1.10 f.

Preserve the existing external SMTP e-mail addresses and use Exchange 2003 to route incoming messages to the legacy messaging system A disadvantage of having the legacy messaging system perform the message conversion and routing is that all Internet communication depends on the system from which you are migrating. It is preferable to use Exchange 2003 for all inbound and outbound SMTP messages (Figure 1.11). Directory synchronization remains a requirement, however, so a recipient object is created in Active Directory for each user in the legacy messaging system. For example, you can configure Connector for Lotus Notes to create a mail-enabled contact in Active Directory for each Lotus Notes user. The contact object is not only configured with an SMTP address, but also with a Lotus Notes address. When Exchange receives a message with an SMTP address that is associated with a Lotus Notes user, Exchange routes the message to the Lotus Notes address across the messaging connector.

Figure 1.11 3.

Internet message routing through the legacy messaging system

Internet message routing through Exchange 2003

How will you avoid performance bottlenecks? To achieve an optimal message transfer rate, you might need to implement multiple bridgehead servers. Multiple bridgehead servers are necessary because it is not usually possible to configure multiple Exchange connectors of the same type on a single Exchange 2003 server. Furthermore, Connector for Lotus Notes and Connector for Novell GroupWise are

46 Exchange Server 2003 Interoperability and Migration Guide

able to connect to only one system in the non-Exchange messaging environment. Messages to recipients on post offices or Lotus Domino servers that are connected indirectly to Exchange 2003 must be routed to their destinations in the legacy messaging environment. Note If you plan to implement multiple bridgehead servers and messaging connectors to the same non-Exchange environment, outline the routing topology carefully to avoid transfer problems, such as message loops.

Synchronizing Directory Information The second critical task in maintaining interoperability between a legacy messaging system and Exchange 2003 is to provide accurate directory information in both messaging systems during the migration. When users send e-mail to other recipients in the company, they must be able to select the user name from an address list, and the message must be delivered to the appropriate mailbox.

Automated Directory Synchronization Through Exchange Connectors One way to synchronize directory information is to use one of the Exchange 2003 connectors. Both Connector for Lotus Notes and Connector for Novell GroupWise support the synchronization of directory information. When you use these connectors, you can configure a number of settings, including: •

Attributes to be synchronized If you do not want all of the attributes for each user to be synchronized to the other messaging system, you can exclude attributes from the directory synchronization.

•

Directory entries to be synchronized For example, you might choose to synchronize the directory information for all mailbox-enabled user accounts, but not to synchronize contacts or mail-enabled groups.

•

Organizational units in Active Directory Based on the organizational units that you select, you can specify which recipient objects are synchronized with the legacy messaging system. You can also specify a target organizational unit for all recipient objects that point to legacy mailboxes.

•

Types of recipient objects to be created You can create disabled Windows user accounts, enabled Windows user accounts, or contacts in Active Directory.

•

Whether to replicate groups or distribution lists When you configure the connector to replicate distribution lists from the non-Exchange messaging system, a mail-enabled contact item is created in Active Directory for that distribution list. When the Exchange users send e-mail to that contact, the message is sent to the e-mail address that is specified on the contact, and the message is delivered to the other messaging system, where the list is expanded, and the e-mail is distributed to all of the recipients in the list.

Another option for maintaining directory information in Active Directory is to use the tools and technologies discussed earlier in this chapter to implement a semi-automated directory synchronization process. Check with your vendor for information about programming interfaces for automating the update of directory information in the legacy system.

Handling Directory-Related Issues Regardless of the technology that you use to synchronize directory information, there are some common issues that you might encounter as you maintain the directory information, including the following:

Chapter 1: Understanding Interoperability and Migration 47

•

Distribution list memberships might need to be updated manually If you choose to synchronize distribution lists, users can send e-mail to the distribution lists in either messaging system. However, the distribution list membership is not included when you synchronize directories. Distribution lists appear as mail-enabled contacts in Active Directory. As you migrate mailboxes to Exchange 2003, members of distribution lists are deleted from the legacy messaging system because they now reside in the new Exchange 2003 organization. These users typically lose their distribution list membership in the legacy messaging system at the moment that you delete the legacy mailboxes, which means that if users send messages to the distribution list, the messages are not delivered to all intended recipients. One way to handle this is to implement a manual or automated means for updating the distribution lists in the legacy system to ensure that the membership list is accurate. When all users are migrated to Exchange 2003, you can re-create the distribution lists in the form of mail-enabled distribution groups in Active Directory. A better way is to migrate distribution lists to mail-enabled distribution groups in Active Directory before you migrate any mailboxes to Exchange 2003. Mail-enabled distribution groups in Active Directory can contain both Exchange 2003 mailboxes and mail-enabled contacts for recipients who are still in the legacy messaging system. If you create these mail-enabled contacts through directory synchronization, the Exchange Migration Wizard replaces these contacts with mailbox-enabled user accounts during migration. If you specify the organizational unit of the contacts as the target container for the new user accounts, the Migration Wizard updates group memberships automatically.

•

Distribution lists increase connector workload Distribution lists are synchronized as contact objects, which means that directory synchronization does not include distribution list membership information. A message sent to a distribution list or mail-enabled distribution group must first be delivered to the system where the membership information is available. This system then expands the list and delivers the message to each individual recipient. This leads to situations in which messages cross the gateway connector multiple times. The only way to avoid this is to exclude distribution lists from directory synchronization. You then must implement a process for mirroring distribution lists from the legacy system through mail-enabled distribution groups in Active Directory, and you must update distribution list membership manually or semi-automatically after each migration phase. In this way, membership information is available in both the legacy messaging system and the Exchange 2003 organization and can be expanded immediately without the extra message transfer.

•

Clients use local address information If a client is configured to use the personal address book (PAB) or Outlook address book rather than a server-based address list when resolving e-mail addresses, messages might not be delivered if the local address information is outdated. For example, a user might store the address for a legacy mailbox in a PAB. When you migrate that mailbox to Exchange 2003, the server-based address list is updated through directory synchronization. However, this does not include any local address repositories, and if the client is configured to resolve e-mail addresses using a PAB or Outlook address book, any message that the user sends to the mailbox will still be routed to the old email address. You can correct this problem by reconfiguring the client to resolve e-mail addresses using the server-based address list. Otherwise, the user must update the PAB information.

•

Users reply to messages with the old e-mail address A common problem during a migration is that users experience errors when they reply to old e-mail messages. This can happen when a user sends a message from the non-Exchange e-mail account, and then the mailbox is migrated to the Exchange 2003 server. When users reply to the message, the reply is addressed to the old e-mail address. As a result, the message is not delivered to the correct mailbox. The only way to handle this problem is to educate users to re-enter the name of the recipient or to select it again from a server-based address list when they reply to e-mail messages. When the user re-specifies the recipient, correct address information is used, and messages reach the correct mailbox.

•

Recipient information is duplicated in Active Directory When you implement multiple connectors for message transfer, you must configure directory synchronization carefully to avoid synchronizing the same recipients multiple times. Only one connector should perform the directory synchronization.

48 Exchange Server 2003 Interoperability and Migration Guide

Synchronizing Calendaring Information The third task that most companies want to accomplish when they migrate to Exchange 2003 is to provide users in the legacy messaging system and in Exchange 2003 with access to each other's calendar data, specifically free/busy status information, to facilitate the scheduling of meetings. Exchange 2003 includes Microsoft Exchange 2003 Calendar Connector for this purpose. Calendar Connector is a component that uses Connector for Lotus Notes or Connector for GroupWise. Although the specific components vary between Lotus Notes and Novell GroupWise, the process that is used to share calendar information is similar for both messaging systems. The following is a description of the process that occurs when an Exchange 2003 user queries the free/busy information for a user on either Lotus Notes or Novell GroupWise: 1.

When an Exchange user queries another user's free/busy information, Calendar Connector intercepts the request.

2.

Exchange 2003 stores free/busy information in a system folder (a hidden public folder) named SCHEDULE+ FREE BUSY. Calendar Connector checks this public folder's replica on the server on which Calendar Connector is installed. If the free/busy information was updated for the requested user within a pre-configured period of time, Calendar Connector returns the information to the user who is requesting it. Otherwise, Calendar Connector requests updated free/busy information from the server that is running Lotus Notes or Novell GroupWise. The request uses programmable interfaces specific to the non-Exchange messaging system. (If Calendar Connector does not receive a response in time, it returns the information currently stored in the SCHEDULE+ FREE BUSY public folder.)

3.

Through the programmable interfaces, Calendar Connector activates the scheduling component on the non-Exchange messaging system to locate the calendar information for local users. The scheduling component returns the free/busy information to the appropriate programmable interface.

4.

Calendar Connector receives the free/busy information and translates it into Exchange format. Calendar Connector then adds the free/busy information to the SCHEDULE+ FREE BUSY public folder and sends the updated information to the Exchange 2003 user who requested it.

The following is a description of the process that occurs when a user on the non-Exchange messaging system queries the calendar information for an Exchange 2003 user: 1.

When a user queries an Exchange user's free/busy information, the request is sent to the calendaring component.

2.

The calendaring component detects that the requested information is located on a remote server or post office, and forwards the request to that system.

3.

Because the remote server or post office is actually an Exchange 2003 server, Calendar Connector intercepts the request for calendar information.

4.

Calendar Connector processes the request, checks the SCHEDULE+ FREE BUSY public folder for the requested free/busy information, and returns the response to the non-Exchange messaging system.

5.

The information is translated into the appropriate format and provided to the user who requested the information.

Chapter 1: Understanding Interoperability and Migration 49

Getting Started with Interoperability and Migration This chapter covered general strategies, as well as typical tasks that you must accomplish when you are migrating users and data to a new Exchange 2003 organization in a single phase or multiple phases. In the following chapters, you can read about the actual steps that are required to connect Exchange 2003 to a nonExchange messaging system, perform directory synchronization, synchronize calendar information, and move mailboxes using the Exchange Migration Wizard. It is recommended that you follow the explanations provided in the following chapters in a computer lab (ideally, restore a backup with real data). This will help you to familiarize yourself with what needs to be done in a minimum amount of time. After you perform a test migration successfully, you might want to revisit this chapter to adjust your project plans, then test again before approaching your production environment. Whether you are migrating from Lotus Notes, Novell GroupWise, or another messaging system, careful project planning and thorough testing are key factors that can help you to complete your migration project successfully.

C H A P T E R

2

Migrating from Lotus Notes/Domino Messaging Infrastructures

This chapter describes how to deploy Microsoft® Exchange Server 2003 in a Lotus Domino and Lotus Notes release 5 or later messaging environment and how to migrate from Lotus Domino to an Exchange 2003 messaging environment using some of the tools that are included with Exchange 2003. Lotus Domino release 4.6 is also supported, although the specific steps might be different if you are using release 4.6. The instructions included in this chapter are based on the assumption that you are using Lotus Domino release 5.0.10, which is the recommended version for Exchange 2003 components. Note With the release of Microsoft Exchange Server 2003 Service Pack 1 (SP1), Microsoft Connector for Lotus Notes, Microsoft Exchange Calendar Connector, and the Exchange Migration Wizard support Lotus Domino release 6 or later.

Before you begin to deploy Exchange 2003 in a Lotus Notes environment, you must have a thorough understanding of basic Lotus Domino concepts. Lotus Domino is the messaging server to which the messaging client, Lotus Notes, connects, just as Exchange 2003 is the messaging server to which the messaging client, Microsoft Outlook®, connects. In the context of this chapter, the phrases "Lotus Domino user" and "Lotus Notes user" refer to a user who is using the Lotus Notes messaging client to connect to the Lotus Domino messaging server. You also must have a thorough understanding of Exchange 2003 and of Windows Server 2003 deployment and administration concepts. If you are unfamiliar with concepts such as Lotus Domino domains, Lotus Domino certifier IDs, named networks, the Active Directory® directory service, and Exchange connectors, you must familiarize yourself with these concepts before you deploy Exchange 2003. For more information, see Appendix F, "Resources." This chapter is divided into several main sections, which correspond to the order of steps in a multiphase migration from Lotus Notes to Exchange 2003, as follows: 1.

Familiarizing yourself with interoperability issues between Exchange 2003 and Lotus Domino

2.

Implementing Exchange 2003 to Lotus Notes/Domino connectivity

3.

Configuring directory synchronization between Exchange 2003 and Lotus Domino

4.

Implementing calendar connectivity

5.

Migrating from Lotus Domino to Exchange 2003

If you plan to migrate from Lotus Domino to Exchange 2003 in a single step, you can go directly to the section "Migrating from Lotus Domino to Exchange Server 2003." Note This chapter discusses Connector for Lotus Notes, Calendar Connector, and Exchange Migration Wizard configuration tasks at a conceptual level. For detailed step-by-step instructions that outline

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 51

how to configure Lotus Domino and Exchange 2003 for messaging interoperability and migration, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality."

Understanding Interoperability Between Exchange and Lotus Domino When you deploy Exchange 2003 in your existing Lotus Domino environment, users of both messaging systems can interact with each other as if they are members of the same messaging system. Interoperability consists of the following three elements: •

Message transfer between Lotus Domino and Exchange 2003 It is recommended that you use Connector for Lotus Notes to transfer messages bidirectionally between Lotus Domino and Exchange 2003. This connector is designed to facilitate interoperability between Exchange 2003 and Lotus Domino.

•

Directory synchronization between Lotus Domino and Active Directory Connector for Lotus Notes can synchronize the Lotus Domino directory and Active Directory so that both Lotus Domino and Exchange 2003 users have access to complete address lists.

•

Calendar synchronization between Lotus Domino and Exchange 2003 Calendar Connector performs calendar synchronization. Calendar synchronization enables Exchange 2003 and Lotus Domino users to access each other's free/busy information. Calendar Connector interacts with Connector for Lotus Notes to keep free/busy information between both messaging systems current.

Information about using Connector for Lotus Notes and Calendar Connector to facilitate interoperability appears later in this chapter.

Message Conversion and Transfer To transfer messages sent between Exchange 2003 and Lotus Domino, Connector for Lotus Notes must convert messages into a format that the receiving system understands. The conversion from one format to another might cause some changes in message characteristics. For example, certain features of a Lotus Domino message, such as the expiration date, are lost when the message is converted to the Exchange format. Exchange 2003 and Lotus Domino support several types of messages, including meeting requests, tasks, task requests, and e-mail. Connector for Lotus Notes supports the transmission and mapping of different message types between Exchange 2003 and Lotus Domino. Messages that cannot be mapped to a corresponding message type in the target domain are converted to e-mail messages. Figure 2.1 shows the process for sending messages from Exchange 2003 to Lotus Domino.

52 Exchange Server 2003 Interoperability and Migration Guide

Figure 2.1 Sending messages from Exchange 2003 to Lotus Domino The process for message transfer between Exchange 2003 and Lotus Domino can be divided into three steps: 1.

Exchange 2003 determines that the recipient is a Lotus Domino user (based on the target address of the user) and sends the message to the message transfer agent (MTA).

2.

The MTA delivers the message to the MTS-OUT directory, from which the LSMEXOUT process retrieves it, converts the address from an X.400-based address to a Lotus Domino address, and then delivers it to the READYOUT directory.

3.

The LSMEXNTS process converts the message to Lotus Domino format and delivers it for routing to the MAIL.BOX file on the Lotus Domino server.

Figure 2.2 shows the process for sending messages from Lotus Domino to Exchange 2003.

Figure 2.2 Sending messages from Lotus Domino to Exchange 2003

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 53

The process for message transfer between Lotus Domino and Exchange 2003 can also be divided into three steps: 1.

Lotus Domino receives a message targeted to an Exchange 2003 user from the Lotus Notes user and places it into the mail router's mail.box database. The mail router identifies the message targeted to Exchange 2003 and then deposits it into the exchange.box file.

2.

Connector for Lotus Notes picks up the message from the exchange.box database, converts the message to Exchange 2003 format using the LSNTSMEX process, and then delivers it to the READYIN folder on the Exchange 2003 server.

3.

The LSMEXIN process takes the message, converts the address from a Lotus Domino address to an X.400 address, and deposits it into the MTS-IN folder. The store process then processes the message from the MTS-IN folder and places it in the SMTP service's MTS-OUT folder, from which it is then routed.

Message Type Conversion Connector for Lotus Notes converts messages from Exchange 2003 message types to corresponding message types in Lotus Domino. For example, meeting requests in Exchange 2003 are viewed as appointments by a Lotus Domino user. Accompanying functionality, such as message delivery notification, also appears. Connector for Lotus Notes also converts message types from Lotus Domino to corresponding message types in Exchange 2003, including e-mail messages and appointments. Connector for Lotus Notes does not process scheduling (free/busy) information when creating meeting requests or appointments. Instead, Calendar Connector synchronizes scheduling data. This process is discussed in "Calendar Synchronization" later in this chapter. Table 2.1 shows how different message types are converted between Exchange 2003 and Lotus Domino. Table 2.1 Message conversion between Lotus Domino and Exchange 2003 Exchange 2003 feature

Lotus Domino feature

Lotus Domino to Exchange 2003

Exchange 2003 to Lotus Domino

E-mail messages

Messages

Yes

Yes

E-mail delivered receipt

E-mail delivered receipt

Yes

Yes

E-mail read receipt

E-mail read receipt

Yes

Yes

Non-delivery report

Non-delivery report

Yes

Yes

Importance

Importance

Yes

Yes

Voting buttons

No feature

No

No

Embedded OLE object

Embedded OLE object

Yes

Yes

Embedded file attachment

Embedded file attachment

Yes

Yes

Message expiry date

Message expiry date

No

No

No feature

Reply By

No

No

Web URL

Web URL

Yes

Yes

No feature

URL hotspot

No

No

Meeting requests

Appointments

Yes

Yes

54 Exchange Server 2003 Interoperability and Migration Guide

Exchange 2003 feature

Lotus Domino feature

Lotus Domino to Exchange 2003

Exchange 2003 to Lotus Domino

Meeting accepted

Meeting accepted

Yes

Yes

Meeting declined

Meeting declined

Yes

Yes

Meeting tentatively accepted

Meeting accepted

Appears as accepted

Appears as accepted

Meeting request read

Meeting request read

Yes

Yes

Meeting request delivery

Meeting request delivery

Yes

Yes

Meeting updates

Meeting updates

Appear as new meeting requests containing the word "Updated" in the subject line

Appear as new meeting requests containing the word "Updated" in the subject line

Meeting cancellation

Meeting cancellation

Yes

Yes

Task requests

Tasks

Task requests appear as e-mail messages or tasks

Appear as e-mail messages

All day meeting requests

No feature

No

Appear as meetings with midnight as the start and end time

No feature

Phone messages

Appear as e-mail messages

No

Other messages

Other messages

Default to e-mail messages

Default to e-mail messages

Note Connector for Lotus Notes does not support signed or encrypted messages.

E-Mail Message Type Conversion E-mail messages that originate in either Exchange or Lotus Domino are converted to the format of the target messaging system. Connector for Lotus Notes also tracks message delivery by using delivery confirmation reports, read receipts, and non-delivery reports (NDRs). Connector for Lotus Notes handles meeting requests and phone messages as follows: •

Meeting requests and appointments Connector for Lotus Notes synchronizes Exchange meeting requests and Lotus Domino appointments. Updated meeting requests are identified as Updated in their subject lines. Because of a limitation of the Lotus Domino API, meeting requests that Exchange 2003 users send to Lotus Domino users are not automatically updated in Lotus Domino. The user must manually update them.

•

All day meeting requests All day meeting requests generated in Exchange 2003 appear with a start and end time of midnight.

•

Phone messages Lotus Notes phone messages appear as e-mail messages in Exchange 2003.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 55

E-Mail Message Property Mapping Objects embedded in messages that are sent by the Exchange 2003 client (Outlook) to the Lotus Domino client (Lotus Notes) are converted to attachments. Embedded objects always appear as attachments to the primary message, regardless of where they appear in the original thread. Table 2.2 shows which Lotus Notes e-mail message features convert correctly to Microsoft Outlook and which do not. Table 2.2 E-mail message conversion between Lotus Notes and Microsoft Outlook Lotus Notes

Microsoft Outlook

Size

Converts correctly.

Color

Converts correctly.

Bold

Converts correctly.

Underline

Converts correctly.

Italic

Converts correctly.

Strikethrough

Converts correctly.

Tables

Convert correctly if Microsoft Word is used as the primary e-mail editor in Outlook, but formatting is lost. Do not convert correctly if Outlook is the e-mail editor.

Embedded OLE objects, including graphics

Convert correctly and can be edited.

Double strikethrough

Ignored.

Superscript

Ignored.

Subscript

Ignored.

Shadow

Ignored.

Outline

Converts to italic.

Emboss

Ignored.

Engrave

Ignored.

Small caps

Ignored.

All caps

Ignored.

Drop caps

Ignored.

Hidden

Ignored; text is visible.

Underline other than single

Ignored.

Bitmaps not embedded as OLE objects

Not migrated; formatting is lost.

Bullets

Ignored.

56 Exchange Server 2003 Interoperability and Migration Guide

Directory Synchronization Lotus Domino and Exchange 2003 use different directory services to store information such as users, groups, resources, and so on. Exchange 2003 uses Active Directory, and Lotus Domino uses its own directory service. To function as a single environment, Exchange 2003 data is replicated to the Lotus Domino directory, and Lotus Domino data is replicated to Active Directory. After the directories are synchronized, each directory service contains a complete copy of the directory data (users, groups, and so on) for the combined messaging organization. Directory synchronization consists of two sequential processes: •

Synchronizing recipients from Active Directory to Lotus Domino

•

Synchronizing recipients from Lotus Domino to Active Directory

Using Connector for Lotus Notes, you can enable automatic, scheduled directory synchronization between Exchange 2003 and Lotus Domino. You can also begin directory synchronization on demand. The process is bidirectional during scheduled directory synchronization. Figure 2.3 depicts the directory connection between Exchange 2003 and Lotus Domino. User attributes are updated in both directories. Note that Exchange 2003 relies on Active Directory to maintain all directory information.

Figure 2.3 Directory synchronization between Lotus Domino and Exchange 2003

Synchronizing Directory Entries Between Active Directory and Lotus Domino When synchronizing directory entries from Exchange 2003 to Lotus Domino, Connector for Lotus Notes polls Active Directory and creates an export message that contains the transactions necessary to update existing contacts or create new contacts in the Lotus Domino directory. In the opposite direction, Connector for Lotus Notes extracts recipient information from the Lotus Domino directory according to filter rules specified in the connector configuration and creates mail-enabled recipient objects in the target organizational unit in Active Directory.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 57

You can use Connector for Lotus Notes to filter addresses that you synchronize from Exchange 2003 to Lotus Domino. You can use the address filters to: •

Define containers that hold subsets of Exchange 2003 users and select only these containers to synchronize to Lotus Domino For example, you might synchronize your existing Lotus Domino users to a specific container in Active Directory. You then choose not to synchronize the Active Directory container that holds the Lotus Domino users, because they already exist in the Lotus Domino directory.

•

Choose whether to synchronize contacts to Lotus Domino If your Exchange 2003 organization is connected to multiple non-Exchange messaging systems (or if you created mail-enabled contacts for recipients on the Internet), you can propagate this information to Lotus Notes. Users on Lotus Notes can then conveniently communicate with all users in your complex messaging environment. However, you must examine your directory synchronization carefully to avoid duplicating address information, which might happen if the other non-Exchange messaging system (such as Lotus cc:Mail) is already synchronizing its directory with the Lotus Domino directory.

•

Choose whether to synchronize groups (distribution lists) to Lotus Domino Connector for Lotus Notes supports propagation of the names of groups (distribution lists) to Exchange 2003 and Lotus Domino. However, the tool does not synchronize group membership. The target system (either Exchange 2003 or Lotus Domino) automatically expands the group for message delivery to the members of the distribution list. Groups can contain members from both systems, but the members appear as contacts in the other mail system (Lotus Domino or Exchange). For example, in an Active Directory group, members who are Lotus Domino users appear as contacts. You can handle distribution list/group issues in various ways, as discussed in Chapter 1 in the section "Performing a Multiphase Migration."

•

Define filter rules to synchronize only a subset of recipients from the Lotus Domino Directory Connector for Lotus Notes supports filter rules, which you can define in the exchconn.ini file. You can find this file in the \Program Files\Exchsrvr\Bin directory. In the [LME-NOTESDXANOTES] section for the Lotus Notes Directory Exchange Agent parameters, you can specify filter rules in the format FILTER_X = X,EQ,[formatted string], for example: filter_person = CompanyName, EQ, Contoso.

Mapping Attributes The directory synchronization component of Connector for Lotus Notes synchronizes a subset of the many attributes that are supported by the Active Directory and Lotus Domino directories. The default schema for each directory is defined in schema definition files. These files contain mapping rules that define how attributes in one schema correspond to attributes in another schema. Some attributes correspond in simple attribute-to-attribute pairs. For example, when the Lotus Domino directory is synchronized with Active Directory, the Exchange 2003 attribute company is assigned the value of the Lotus Domino directory attribute company. You can edit the following schema definition files and mapping rule files in Notepad to determine how attributes in one directory are mapped to the other directory: •

AMAP.TBL In the \Program Files\Exchrvr\Conndata\Dxamex subdirectory, it defines the Exchange mailbox attributes to be synchronized.

•

AMAP.TBL In the \Program Files\Exchrvr\Conndata\Dxanotes subdirectory, it defines the Lotus Notes attributes to be synchronized.

•

MAPMEX.TBL In the \Program Files\Exchrvr\Conndata\Dxanotes subdirectory, it determines the attribute mapping from Exchange 2003 to Lotus Notes.

•

MAPNOTES.TBL In the \Program Files\Exchrvr\Conndata\Dxamex subdirectory, it determines the attribute mapping from Lotus Notes to Exchange 2003.

58 Exchange Server 2003 Interoperability and Migration Guide

For detailed information about customizing the directory synchronization between Lotus Domino and Exchange Server 2003, see Microsoft Knowledge Base article 180517, "XFOR: Customizing Directory Synchronization Between Exchange and Notes" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=180517).

Synchronizing Resources Lotus Domino has a class of directory objects called Resource, which is used for conference rooms, equipment, and other shared resources. In Active Directory, Lotus Domino resources are synchronized as contacts if they are listed in the PEOPLE view in the Lotus Domino Administrator program.

Calendar Synchronization Calendar Connector provides Exchange 2003 and Lotus Domino users with almost real-time access to free/busy status information. Calendar Connector uses Connector for Lotus Notes, which must be installed on either the same server as Calendar Connector or on a different Exchange 2003 server within the same administrative group. Note Lotus Domino can query free/busy information only for users who are contained in the names.nsf file. This is a hard-coded limitation of the product. Free/busy information for address books other than names.nsf is not available.

Calendar Synchronization from Lotus Domino to Exchange 2003 This section explains how Calendar Connector enables Exchange 2003 users to view the free/busy information for Lotus Domino users. Free/busy information from Lotus Domino is synchronized to Exchange 2003 using Calendar Connector. Free/busy information is stored in a SCHEDULE+ FREE BUSY public folder in an Exchange 2003 administrative group. The following is an explanation of what happens when an Exchange 2003 user queries the calendar information for a Lotus Domino user: 1.

The Exchange user queries a Lotus Domino user's free/busy information, and then Calendar Connector intercepts the request.

2.

Calendar Connector checks for current free/busy information for the Lotus Domino user in the SCHEDULE+ FREE BUSY public folder replica on the server on which Calendar Connector is installed. If the information has been updated within a preconfigured number of minutes, Calendar Connector returns the information to the user who is requesting it. If the information in the public folder is not updated within the time allotted, Calendar Connector requests updated free/busy information using API calls to the Lotus Domino server. The Lotus Domino API is installed with the Lotus Notes client on the Exchange server.

3.

The API calls are routed to Schedule Manager for Lotus Domino.

4.

Schedule Manager locates the calendar information for local users in the busytime.nsf database. For users on downstream servers running Lotus Domino, Schedule Manager passes the request to the Lotus Notes Calendar Connector task, which then locates the user's calendar information. Note The Lotus Notes Calendar Connector task is the Lotus Domino component that handles

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 59

scheduling. Do not confuse this with the Calendar Connector component. The Lotus Notes Calendar Connector task runs on the Lotus Domino server.

5.

Schedule Manager returns the free/busy information to the Lotus Domino API. On the Exchange server, Calendar Connector receives the Lotus Domino user's free/busy information and translates it to the Exchange format. Calendar Connector then adds the free/busy information to the SCHEDULE+ FREE BUSY public folder and sends the updated information to the Exchange 2003 user who requested it. Tip Lotus Domino users should permit other users to access the free/busy schedule information in their calendar profiles. If Lotus Domino users do not permit access, Exchange users do not receive a warning that the Lotus Domino users' schedule information might not be current. Instructions for how Lotus Domino users can permit access to their free/busy information are provided later in this chapter.

Figure 2.4 shows the internal process of free/busy information synchronization between Lotus Domino and Exchange 2003. In this figure, an Exchange 2003 user is querying for the free/busy information of a Lotus Domino user.

Figure 2.4 Free/busy information synchronization from Exchange 2003 to Lotus Domino You can set the following options on Calendar Connector: •

The number of days of free/busy information to request from the other system's calendars

•

The maximum number of minutes that the Lotus Domino system's free/busy information is stored in Exchange 2003 before querying the Lotus Domino server for updated free/busy information

•

The maximum number of seconds that Calendar Connector waits for responses from Lotus Domino

If Calendar Connector does not receive a response in the time that you specify, it returns the information currently stored in the SCHEDULE+ FREE BUSY public folder on the Exchange server to the Exchange client.

60 Exchange Server 2003 Interoperability and Migration Guide

Calendar Synchronization from Exchange 2003 to Lotus Domino Here the query is reversed, and free/busy information from Exchange 2003 is synchronized to Lotus Domino using Calendar Connector. The following is an explanation of what happens when a Lotus Domino user queries the calendar information for an Exchange 2003 user: 1.

When a Lotus Domino user queries an Exchange user's free/busy information, the request is sent to the Lotus Domino Calendar Connector task.

2.

The Lotus Domino Calendar Connector task sends the request to the Lotus Domino add-in task, called Exchange Calendar Connector add-in (Excalcon.exe). Because all Exchange users belong to a foreign domain, all requests for Exchange free/busy information are routed to Excalcon.exe.

3.

Excalcon.exe delivers the request from Lotus Domino to Exchange through Calendar Connector.

4.

Calendar Connector processes the request and queries the Exchange SCHEDULE+ FREE BUSY public folder for the requested information.

5.

The Calendar Connector response is delivered to Excalcon.exe on the Lotus Domino server. Excalcon.exe translates the data into Lotus Domino format and delivers the free/busy information to Schedule Manager.

6.

Schedule Manager sends the Exchange user's free/busy information to the Lotus Domino user who requested it. Note Lotus Notes users must be added to Active Directory as mail-enabled recipients (through directory synchronization) so that Exchange 2003 has the correct address information.

Querying Groups You can query free/busy information for a group created in Exchange 2003 that contains Lotus Domino users. However, you cannot query free/busy information for groups that are stored on Lotus Domino. In other words, an Exchange 2003 user cannot query a Lotus Domino group for free/busy information, regardless of the server on which the group members reside.

Supported Calendar Synchronization Implementations Exchange supports the following implementation scenarios: •

A single Calendar Connector with a single connection to a Lotus Domino domain

•

A single Calendar Connector, in a single routing group, with separate connections to each Lotus Domino domain

•

Multiple administrative groups, each with their own Calendar Connector, connected to the same Lotus Domino domain

•

A single Calendar Connector that queries users on an upstream domain

Exchange does not support the following implementation scenarios: •

Multiple Calendar Connectors within a single administrative group connected to any Lotus Domino domain

•

Free/busy switching or querying from one co-existence partner to another using Exchange as a backbone

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 61

•

Lotus Domino as a backbone between two Exchange systems

Implementing Exchange to Lotus Notes/Domino Connectivity In theory, you need only a single Exchange 2003 server to use Connector for Lotus Notes. However, it is not recommended that you run Connector for Lotus Notes on an Exchange server that hosts mailboxes, because the added processing requirements for message conversion and transfer can adversely affect system performance during peak hours. Therefore, you should have at least one Exchange 2003 server that includes your Exchange mailboxes and a separate Exchange 2003 server that includes Connector for Lotus Notes. To simplify the discussion about how to configure Exchange 2003 to interoperate with a Lotus Domino environment, the information in this section is based on the assumption that you have a single Lotus Domino server. However, the information provided here can be applied to larger or more complex Lotus Domino deployments. In larger deployments, the Lotus Domino server that you configure here acts as the bridgehead for other Lotus Domino servers and other Lotus Domino domains. Figure 2.5 shows the minimum Windows and Exchange 2003 configuration that you should consider for configuring and testing interoperability with Lotus Domino.

Figure 2.5 Basic Windows and Exchange environment Note The following is a discussion of the steps involved in configuring the Connector for Lotus Notes. For complete procedures with detailed, step-by-step instructions for configuring Lotus Domino and Connector for Lotus Notes, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality."

You must complete the following steps to configure Connector for Lotus Notes: 1.

Ensure that prerequisites are met Before you install Connector for Lotus Notes on a new Exchange 2003 server, you must ensure that the Exchange server has network connectivity to the Lotus Domino server and can resolve the name of the Lotus Domino server. All access to Lotus Domino from Exchange 2003 is accomplished through standard Lotus Domino APIs. The advantage is that Exchange interacts with Lotus Domino using Lotus-supported technology. To use Lotus Domino APIs, the Lotus Notes client software (release 4.6 or later) must be installed on the Exchange 2003 server and Connector for Lotus Notes.

62 Exchange Server 2003 Interoperability and Migration Guide

Note When you are deciding which version of the client to install, consider the information in Microsoft Knowledge Base article 316035, "XFOR: Lotus Notes Client Versions That Are Tested with the Exchange Notes Connector" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316035).

In addition, ensure that the Lotus Domino server meets the following prerequisites: •

It is running Lotus Domino release 4.6 or later.

•

It is not configured as the inbound Simple Mail Transfer Protocol (SMTP) mail gateway to the Internet. Important If a Lotus Domino server is configured as the inbound SMTP mail gateway for your organization, the addresses for SMTP messages sent to Exchange users from the Internet will be corrupted. This is because all messages sent to Exchange through Connector for Lotus Notes are appended with the Lotus Domino domain name. To avoid this problem, configure Exchange, not Lotus Domino, as the inbound SMTP mail gateway for messages inbound from the Internet. For more information about this issue, see Microsoft Knowledge Base article 255160, "XFOR: SMTP Messages from Lotus Notes SMTPMTA to Exchange 2000 Append @NotesDomain to the Sender's Address" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=255160).

2.

Prepare the Lotus Domino environment Before configuring Connector for Lotus Notes, the following tasks must be performed on the Lotus Domino server: a.

Use Lotus Domino Administrator to register a new person To transfer messages and synchronize directories between Lotus Domino and Exchange 2003, Connector for Lotus Notes must have its own Lotus Domino user ID. If you decide not to specify a password for this user ID, you cannot store the ID information in the Lotus Domino directory. Instead, create an ID file, and use this file later to configure Lotus Notes on the Exchange server that runs Connector for Lotus Notes. Remember the location of the user ID file, because you must copy it later to the Exchange 2003 server and Connector for Lotus Notes. Note If your security policies require you to create a password for the connector user ID, create an ID file and specify the password in the connector configuration.

b.

Create the Lotus Domino databases for routing mail to Exchange Lotus Domino requires two mailbox databases to route messages to Exchange 2003: a connector mailbox and a mailbox for badmail. Badmail refers to e-mail messages that cannot be delivered to your Exchange organization. The connector mailbox stores mail being routed from Lotus Domino to Exchange. Later, you create the foreign domain document to register the Exchange organization as an external foreign domain in the Lotus Domino Directory and configure Connector for Lotus Notes. At that time you also specify the name of the connector mailbox. All mail routed from Lotus Domino to Exchange 2003 is then sent to the connector mailbox, from which it is retrieved by Connector for Lotus Notes. The mailbox for badmail stores any mail that failed to transfer to Exchange 2003. Note If the user ID for Connector for Lotus Notes has Lotus Domino permissions to create new databases (configured in Lotus Domino Administrator on the Security tab of the Lotus Domino server Server document), these two databases are created automatically when you configure Connector for Lotus Notes. By default, Lotus Domino gives this permission to everyone, but most Lotus Domino administrators restrict this permission to privileged users. It is recommended that you create these databases manually.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 63

c.

Prevent the new user ID from being synchronized to Active Directory You might not want the new Lotus Domino user ID for Connector for Lotus Notes to appear in the Exchange address list after you synchronize with Lotus Domino, because this connector does not represent a user in your environment. To prevent propagation of this user ID, use Lotus Domino Administrator to hide the new user ID from Exchange users or downstream Lotus Domino domains.

64 Exchange Server 2003 Interoperability and Migration Guide

d.

Grant Depositor access to the server mailbox This is the level of access required by Connector for Lotus Notes. You must ensure that the user ID that you created for Connector for Lotus Notes has Depositor access to the server mailbox. Connector for Lotus Notes uses the server mailbox (mail.box, by default) to deposit mail from Exchange 2003 that is bound for Lotus Domino mailboxes. In most Lotus Domino environments, new user IDs are automatically granted Depositor access.

e.

Grant Editor access to the Lotus Domino directory To update the Lotus Domino directory, Connector for Lotus Notes requires Editor level access to the directory of the Lotus Domino target server. In addition, ensure that the Delete documents permission is granted to Connector for Lotus Notes.

f.

Grant Reader access to other Lotus Domino databases Lotus Domino allows users to create links between documents. These links are called DocLinks. Connector for Lotus Notes converts these links to one of three formats: •

OLE document link

•

Rich Text Format (RTF) attachment

•

URL shortcut Note Database links and view links are not supported. Exchange users receive an error message if database or view links are sent to them from Lotus Domino users.

If you choose to convert links to RTF attachments, Connector for Lotus Notes requires Reader access to the document associated with the link. Otherwise, it cannot generate and send the linked file as an RTF attachment. Therefore, the Lotus Domino user ID in Connector for Lotus Notes must be given Reader access in the access control list (ACL) to every database that might be linked or that contains a document to which a Lotus Domino user might link. One option is to update the ACL on each database in Lotus Domino Administrator. Alternatively, you can add the user ID for Connector for Lotus Notes to a group in the Lotus Domino directory that has Reader access to the necessary databases. g.

Identify Exchange as a foreign domain For messages to be routed correctly from Lotus Domino to Exchange 2003, the Exchange organization must be identified to Lotus Domino as a foreign domain in Lotus Domino Administrator. Note Incorrect settings in the foreign domain document can prevent Lotus Domino from routing messages to the connector's mailbox database (exchange.box).

3.

Install Exchange 2003 with Connector for Lotus Notes After you configure your Lotus Domino environment, you install Exchange 2003 on a dedicated connector server. As part of this setup, you install Connector for Lotus Notes. To install Exchange 2003 on the server, you must have Exchange Administrator permissions in the administrative group in which the Connector for Lotus Notes target routing group exists. You must also be a member of the Administrators group on the server on which you install Exchange 2003.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 65

4.

Prepare the Exchange 2003 environment After you install Exchange 2003 with Connector for Lotus Notes, you must install and configure Lotus Notes Client and enable Lotus Domino proxy addresses on the same server, as follows: a.

Install and configure Lotus Notes Client Before you install Lotus Notes on the Exchange 2003 connector server, make sure that you have a Lotus Notes Client access license for the connector. After the installation, copy the user ID file that you created earlier to the directory of your Lotus Notes client (for example, e:\lotus\notes, where e is the drive letter with Lotus Notes installed). After you copy the file, configure the Lotus Notes client for the user ID that you created for Connector for Lotus Notes so that Connector for Lotus Notes can use it to connect to the Lotus Domino server. Note It is important to include the Lotus Notes directory in the system search path on the connector server. Do not simply copy the nnotes.dll file from the Lotus Notes directory to \Winnt\System32. Also, to avoid connector problems, do not select another user ID on the connector server that uses the Switch ID command in Lotus Notes.

b.

Enable Lotus Domino Proxy Addresses Lotus Notes users see Exchange users as recipients in another Lotus Domino domain, as identified by the foreign domain created for the connector. By default, the Lotus Notes e-mail address format that is used for Exchange 2003 users is based on the user's display name and the name of the Exchange organization. Because Exchange organization names sometimes contain characters that are not valid for an e-mail address type, you can modify the address generation rule in a recipient policy, as explained in Chapter 1, "Understanding Interoperability and Migration." The Recipient Update Service automatically generates the NOTES addresses for each mailbox and mail-enabled account. The address rule uses a set of symbols to determine how Exchange recipients appear in the Lotus Domino organization. The resulting addresses must be unique within the address space. If the rule does not create a distinctive address, the Lotus Domino e-mail address generator modifies the address to ensure that it is unique. The default format for Lotus Notes addresses that are assigned to Exchange users is: &d/organization@domain name The following is a description of what each part of this address signifies: •

&d = The Lotus Notes display name (typically the full name) of the user.

•

Organization = The name of the user's Exchange organization.

•

Domain name = The Lotus Domino foreign domain name that represents the Exchange organization. This is the name that you specified when you configured the connector's foreign domain document in Lotus Domino Administrator.

You can use the placeholders listed in Table 2.3 to customize the NOTES address generation. Note that they differ from other placeholders in that & is used instead of %. Table 2.3

Proxy address configuration symbols

To substitute

Use this symbol

The user's alias

&M or &m

The user's initials

&I or &i

An e-mail address based on the user's display name

&D or &d

The first name of the user

&G or &g

66 Exchange Server 2003 Interoperability and Migration Guide

To substitute

Use this symbol

The last name of the user

&S or &s

An ampersand (&)

&&

For example, you set the address format to &d@Exchange. A user whose display name is Birgit Seidl receives a Lotus Notes address of: Birgit Seidl@Exchange. Caution After directory synchronization, the connector creates secondary proxy addresses for Lotus Domino recipients. These addresses, which do not display bold formatting on the E-Mail Addresses tab, are used as unique identifiers for Lotus Domino recipients. Do not delete these secondary proxy addresses. You should only delete addresses that you create manually.

5.

Configure Connector for Lotus Notes Connector for Lotus Notes is configured using the Exchange System Manager MMC snap-in. The location of the connector depends on whether you enable viewing for routing or administrative groups in Exchange System Manager. Figure 2.6 shows the location of the connector when viewing for both routing and administrative groups is enabled.

Figure 2.6

Location of Connector for Lotus Notes in Exchange System Manager

Among other things, you must specify the location of the Notes.ini file, the name of the connector mailbox that you configured earlier on your Lotus Domino server (for example, exchange.box), and the name of the server mailbox on the Lotus Domino bridgehead server to which Connector for Lotus Notes connects (the default is mail.box). You might also want to adjust the polling interval that Connector for Lotus Notes uses to check for new messages delivered to Exchange, and specify how to convert Lotus Notes DocLinks. Another important configuration parameter is the address space that you must specify for the connector so that Exchange 2003 can route messages to Lotus Notes. Use wildcards (*) where appropriate to allow all users to connect to Lotus Domino using Connector for Lotus Notes. 6.

Test e-mail connectivity To ensure that the message routing works, send test messages from Lotus Notes to Exchange 2003 and from Exchange 2003 to Lotus Notes. Use your NOTES proxy address to specify an Exchange recipient in Lotus Notes, for example Administrator/First Administrative Group/Contoso@Exchange. To find your proxy address, start Active Directory Users and Computers, and display the E-Mail Addresses tab for your user account.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 67

Implementing Multiple Connector Instances If you want to use multiple connector instances to connect an Exchange 2003 organization to a Lotus Domino environment, you must distribute the users in your Exchange organization across multiple Lotus Domino foreign domains. You can configure multiple recipient policies to generate NOTES addresses according to different formats. For example, you might assign Ted Bremer the address Ted Bremer/Contoso@Exchange1, and the administrator might have the address Administrator/Contoso@Exchange2.

Figure 2.7 Using multiple connector instances between an Exchange organization and a Lotus Domino domain The environment illustrated in Figure 2.7 corresponds to an Exchange 2003 organization with two foreign domains. Therefore, you must create two foreign domain documents in Lotus Domino/Notes: one for the first foreign domain and one for the second foreign domain. Point these foreign domains to separate mailbox databases of different connectors in Lotus Domino Administrator. In this way, multiple connector instances can share the message traffic to Exchange 2003. Note When you implement multiple connector instances, carefully design the directory synchronization topology to avoid duplicating address information. Directory synchronization configuration is covered later in this chapter.

Specifying Routable Lotus Domino Domains Just as an Exchange 2003 organization can have multiple administrative groups, a Lotus Domino environment can have multiple domains. These domains can transfer messages indirectly to the Exchange 2003 organization through another domain in which the connector's Lotus Domino server resides (Figure 2.8). Connector for Lotus Notes can allow all users in all domains to communicate with each Exchange user, but additional configuration is required to support message transfer in the opposite direction. You must identify downstream domains in the Advanced tab of the connector object in Exchange System Manager. Click the Add button under Routable Domains, and type the domain names in the Add Routable Domains dialog box. You can identify Lotus Domino domains that are referenced in the Connection, Foreign Domain, and Nonadjacent Domain documents. Exclude the foreign domains created for Exchange 2003. In

68 Exchange Server 2003 Interoperability and Migration Guide

addition, you must assign correct address space information to the Connector for Lotus Notes to allow for proper message routing.

Figure 2.8 Using a single Connector for Lotus Notes instance to reach multiple Lotus Domino domains

Configuring Directory Synchronization After you configure Connector for Lotus Notes, you can synchronize directories between Lotus Domino and Exchange 2003 (Active Directory). When directories are synchronized, both Lotus Domino and Exchange 2003 users can select each other in the Exchange address book or Lotus Domino directory, and send messages to each other as if they belong to the same messaging environment. Before configuring directory synchronization, ensure that you successfully test message transfer using Connector for Lotus Notes. Note The following section is a conceptual discussion of configuration steps. For complete procedures with detailed step-by-step instructions for configuring directory synchronization between Lotus Domino and Exchange 2003, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality."

You must complete the following steps to configure directory synchronization with Lotus Domino: 1.

Specify an import container for Lotus Domino recipients The import container is the target organizational unit in Active Directory where Connector for Lotus Notes places the recipient objects that are created during directory synchronization for Lotus Domino users. There can only be one import container. Note You must grant the computer account of your Exchange 2003 server permission to create and modify recipients in the selected import container. This is necessary for directory synchronization from Lotus Domino to Exchange 2003 to work. Exchange System Manager can automatically configure the computer account with the required permissions when you configure Connector for Lotus Notes.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 69

2.

Specify which Exchange recipients to export to Lotus Domino An export container is an organizational unit in Active Directory that Connector for Lotus Notes uses to export Exchange recipient objects to the Lotus Domino directory. You can specify multiple export containers in the Connector for Lotus Notes configuration. Nested organizational units are not selected for export if you select the parent organizational unit. You must select each organizational unit individually. In addition to selecting export containers, you can decide whether to export contacts and groups to Lotus Domino. For a discussion of the advantages and disadvantages of synchronizing group objects, see Chapter 1, "Understanding Interoperability and Migration." Note You must grant the computer account of your Exchange 2003 server permission to access and read recipient information in the selected export container. This is necessary for directory synchronization from Lotus Domino to Exchange 2003 to work. Exchange System Manager can automatically configure the computer account with the required permissions when you configure Connector for Lotus Notes.

3.

Configure a directory synchronization schedule Directory synchronization can require that large amounts of data be processed through Connector for Lotus Notes, which can slow message traffic throughput during synchronization cycles. For this reason, schedule synchronization during off-peak traffic hours. If your directory information changes infrequently, synchronizing once a day might be sufficient. Otherwise, schedule synchronization for two or more times a day. You can specify the directory synchronization schedule on the connector's Dirsync Options tab.

4.

Adjust Lotus Notes address book settings You might want to configure address book settings if you choose not to use the default Lotus Domino directory file name (names.nsf), or if you want to specify different address books for other Lotus Domino domains. You can do this on the connector's Dirsync Options tab, using the Address Book Settings button.

5.

Test directory synchronization You should start the first directory synchronization cycle manually to verify that Connector for Lotus Notes is configured correctly and that the directories synchronize. On the connector's Dirsync Options tab: a.

Under Exchange to Notes directory synchronization, click Immediate full reload. A pop-up message indicates that directory synchronization has begun. This process synchronizes directory objects from Active Directory to the Lotus Domino directory.

b.

Under Notes to Exchange directory synchronization, click Immediate full reload. Again, a popup message indicates that directory synchronization has begun. This process synchronizes directory objects from the Lotus Domino directory to Active Directory.

Allow a few minutes for synchronization to finish. Then check Active Directory to verify that the Lotus Domino users and objects have been added. Also, check the Lotus Domino directory to ensure that Exchange 2003 users and objects have been added there. If the directories are not updated, an error occurred. The following list provides general troubleshooting tips. For more troubleshooting guidelines, see Chapter 5, "Troubleshooting Interoperability and Migration Issues." •

Verify that there is connectivity between the Exchange server with Connector for Lotus Notes and the bridgehead server running Lotus Domino. To do this, stop the Connector for Lotus Notes service and then start the Lotus Notes Client application. Verify that you can access the connector mailbox using the Lotus Notes user ID created for Connector for Lotus Notes. Note As a best practice, never use Lotus Notes Client on the Exchange 2003 server at the same time that Connector for Lotus Notes is running.

70 Exchange Server 2003 Interoperability and Migration Guide

•

Verify the configuration of both the Lotus Domino server and the Exchange 2003 server. Verify that you configured everything correctly in the previous configuration steps. Specifically, check all server, domain, and file names, and verify that they are correct on both Lotus Domino and Exchange. Most synchronization issues are the result of configuration problems.

•

Check Event Viewer on the Exchange 2003 server for any errors in the application log. These might help you to determine at what point the problem occurred. Also check the logs and console on the Lotus Domino server for any errors.

If your synchronization is successful, you will find the recipient objects in the Lotus Domino and Exchange directories. Users on both servers can now interact as if they are members of the same messaging environment. The next step is to enable users on both servers to access each other's free/busy information.

Implementing Calendar Connectivity Calendar Connector enables Lotus Domino and Exchange users to access each other's free/busy information when they schedule meetings. Before you configure Calendar Connector, ensure that both Exchange and Lotus Domino users can send messages to each other and that directory synchronization works. Note The following section is a conceptual discussion of configuration steps. For complete procedures with detailed step-by-step instructions for configuring calendar connectivity between Lotus Domino and Exchange 2003, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality."

The following steps are required to configure calendar connectivity: 1.

Ensure that prerequisites are met Before you install and configure Calendar Connector, you must ensure that you have the necessary permissions and are running the required software. You install Calendar Connector on an existing Exchange 2003 server. Before proceeding, ensure that the server on which you install Calendar Connector meets the following prerequisites: •

The server is running Exchange Server 2003.

•

The server is part of the same routing group as the server running Connector for Lotus Notes. The simplest option is to install Calendar Connector on the server running Connector for Lotus Notes.

•

The server is running Lotus Notes release 4.6 or later. Note Ensure that you have a Lotus Notes Client access license for the server on which you install Calendar Connector.

In addition, the Lotus Domino server to which Calendar Connector connects must meet the following prerequisites: •

The operating system must be either Microsoft Windows NT® 4.0, Windows® 2000 Server, or Windows Server™ 2003.

•

The name of the Lotus Domino server must be the same as the name of the server running Windows.

•

The server must be equipped with x86-based processors.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 71

2.

Install Calendar Connector You must install Calendar Connector on an Exchange 2003 server that belongs to the same administrative group as the server running Connector for Lotus Notes. Calendar Connector is included in Exchange Server 2003 and can be installed when you start the Exchange 2003 Setup program. You must have the following permissions to install and administer Calendar Connector:

3.

•

Exchange Administrator These permissions are required to install Calendar Connector on the Exchange server.

•

Local Administrator You must be a member of the Administrators group on the computer on which you install Calendar Connector.

Add a local replica for the SCHEDULE+ FREE BUSY public folder Schedule information for users in an Exchange 2003 messaging environment is stored in a hidden public folder called SCHEDULE+ FREE BUSY (Figure 2.9). This folder is configured for each administrative group in the Exchange organization. Calendar Connector uses the SCHEDULE+ FREE BUSY public folder to read and write the schedule information for Lotus Domino users so that Exchange 2003 users can access that information.

Figure 2.9

The SCHEDULE+ FREE BUSY public folder

Calendar Connector always looks for the SCHEDULE+ FREE BUSY public folder on the local Exchange 2003 server on which it is installed. Therefore, you must ensure that the Exchange 2003 server holds a local replica of the SCHEDULE+ FREE BUSY public folder. To add a local replica of the folder to the local Exchange server, use Exchange System Manager. If there are multiple administrative groups in an Exchange 2003 organization, each administrative group has its own SCHEDULE+ FREE BUSY public folder. In this case, free/busy information for Exchange users might be stored in a different public folder than free/busy information for Lotus Domino users whose information is replicated to Exchange 2003. You must ensure that the administrative group's SCHEDULE+ FREE BUSY public folder is configured to replicate to the server running Calendar Connector. In an Exchange 2003 organization with multiple administrative groups, remember the following:

72 Exchange Server 2003 Interoperability and Migration Guide

4.

•

When it is storing free/busy information for Lotus Domino users, Calendar Connector always uses the administrative group in which Connector for Lotus Notes is installed. The user's free/busy information is stored in the public folder associated with this administrative group because the Connector for Lotus Notes is used to import these users into Active Directory.

•

If the SCHEDULE+ FREE BUSY public folder used by Calendar Connector is replicated to a public folder store in a different administrative group, you must install another instance of Calendar Connector in that administrative group. If you do not install another instance, Calendar Connector does not intercept queries that are made to that replica.

•

If you already have an instance of Calendar Connector installed on one administrative group that imports users from Lotus Domino to Active Directory, and you want to install another Calendar Connector on a different administrative group, you must refer the newly installed Calendar Connector to the original instance of Calendar Connector.

Prepare the Lotus Domino environment Before you configure Calendar Connector, you must perform the following tasks on the Lotus Domino server: a.

Create a Lotus Domino user ID for Calendar Connector It is recommended that you install and configure Calendar Connector on the server that is already running Connector for Lotus Notes. Installing Calendar Connector on a different server is useful in high-traffic situations in which you want to offload some of the processing work from the server running Connector for Lotus Notes. Note If you install Calendar Connector on a different server from the server running Connector for Lotus Notes, you must add a new Lotus Domino user ID for Calendar Connector on the bridgehead server running Lotus Domino, as explained earlier in this chapter. This step is not required if you install Calendar Connector on the server running Connector for Lotus Notes, because you can use the user ID you created earlier.

b.

Install the Calendar Connector add-in for Lotus Domino To allow Lotus Notes users to query for an Exchange user's free/busy information, a task called the Calendar Connector add-in (Excalcon.exe) must run on the Lotus Domino server. When you install Calendar Connector, Excalcon.exe is installed in the \Program Files\Exchsrvr\BIN\CalCon directory. You must copy this file to the Lotus Domino installation directory on the Lotus Domino server, and then run the server console in Lotus Domino Administrator to load the Calendar Connector add-in. Use the command excalcon <exchange-server-name> <mail-file-name>, where exchange-servername is the name of the Exchange 2003 server with Calendar Connector installed, and mail-filename is the name of the mailbox database of Connector for Lotus Notes. For example, if your Exchange server name is server01, and you used the name exchange.box for the mailbox database name, type: load excalcon server01 exchange.box. To verify that the Calendar Connector add-in loaded correctly, type show tasks at the console, and then ensure that there is an entry for Exchange Cal Conn. Using the previous example, it should look something like the following: Exchange Cal Conn Stats=0 0/0 0

Not Connected to server01 for exchange.box.

The Stats information can be understood according to the following syntax: Stats= , where: •

= the total number of calendar requests made from Lotus Domino to Exchange.

•

= the average number of invitees over the average response time, in seconds, per Exchange calendar request made from Lotus Domino.

•

= the maximum response time, in seconds, for all calendar requests.

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 73

By default, the Calendar Connector add-in must be started manually each time the Lotus Domino server restarts. You can automate startup of the Calendar Connector add-in by updating the notes.ini file on the Lotus Domino server. Note The Lotus Calendar Connector add-in must run on an x86-based computer with Windows NT 4.0 or Windows 2000. If you are using Lotus Domino on an Alpha-based or UNIX server, you must use a different x86-based Lotus Domino server to connect to Exchange.

c.

Update the foreign domain document for Exchange You must update the calendar server name in the foreign domain document for your Exchange 2003 organization with the name of the Lotus Domino server with the Calendar Connector add-in. You must also specify the name of the mailbox database file as the Calendar system. Specify the full name of the Lotus Domino server running the Calendar Connector add-in, as demonstrated in Figure 2.10.

Figure 2.10 d.

Updating calendar information for the Exchange foreign domain

Edit individual calendar profiles Individual Lotus Notes users can configure a list of users who have access to their free/busy (or Free Time) information. For Calendar Connector to work, this list must be configured either to allow everyone access or to allow the user ID for Calendar Connector access. If your Lotus Notes users want to allow Exchange users access to their free/busy information, they might need to edit their calendar profiles and add the name of the Calendar Connector user ID to the list of users or groups that can view the user's free/busy information. If the list is empty, no further action is needed. Note This list is exclusive, so if it is not blank and does not contain the user name of the Calendar Connector, Exchange users cannot view the free/busy information of Lotus Notes users.

5.

Configure Calendar Connector Like Connector for Lotus Notes, Calendar Connector is configured using Exchange System Manager and the location of the connector is the same as for Connector for Lotus Notes. You must specify the Connector for Lotus Notes that is used to connect to the bridgehead Lotus Domino server, as well as the name of the Lotus Domino server. To specify the Connector for Lotus

74 Exchange Server 2003 Interoperability and Migration Guide

Notes, on the General tab, click Modify next to the Connector used to import users into Active Directory text box, and then select the required setting on the Select Exchange Notes or GroupWise Connector tab. To specify the Lotus Domino server, on the Notes Calendar Connection tab, in the NT Server Hosting the Notes Server text box, type the name of the bridgehead server running Lotus Domino. Do not include the certifier information. For example, if your full Lotus Domino server name is listed as server01/contoso, type server01. You might also want to adjust the number of days that users are able to see free/busy information for users on the other messaging system (Number of days of free/busy information to request from foreign calendars). Free/busy information beyond the number of days specified is not retrieved by Calendar Connector and appears as free, even if meetings are scheduled during this time. Another important configuration parameter refers to the number of minutes of free/busy information that Calendar Connector can accept (Maximum age in minutes of foreign free/busy data in Exchange that can be used without querying the foreign calendar). If the free/busy information is beyond the specified number of minutes, Calendar Connector requests updated data. If the free/busy information is within the specified number of minutes, Calendar Connector uses the current free/busy information. When requesting free/busy updates, the Maximum number of seconds to wait for response from foreign calendars setting determines the time that Calendar Connector waits for a response for an individual user's free/busy information. Set this to a low number, because each recipient on a meeting request is handled in turn, and a long response interval can cause the mail client to stop responding as it proceeds down the list of recipients. 6.

Start the Calendar Connector service In the Services Microsoft Management Console (MMC) snapin, right-click Microsoft Exchange Calendar Connector, and then click Start. The default startup type for Calendar Connector is Manual. It is recommended that you change this setting to Automatic, so that the Calendar Connector service starts automatically the next time you restart the server.

Migrating from Lotus Domino to Exchange Server 2003 This section explains how to migrate a group of users from Lotus Domino to Exchange 2003. The guidelines are recommended for most migrations, and consist of extracting data from the Lotus Domino server and immediately importing it into Exchange 2003. However, in some cases you might want to edit the extracted data before you import the data into Exchange 2003, as explained in Chapter 1, "Understanding Interoperability and Migration." Note The following section is a conceptual discussion of configuration steps. For complete procedures with detailed step-by-step instructions for migrating Lotus Domino/Notes users to Exchange 2003 using the Exchange Migration Wizard, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality."

A Lotus Domino to Exchange 2003 migration consists of the following steps: 1.

Grant access to users' mailboxes To migrate data from Lotus Domino to Exchange 2003, the Exchange Migration Wizard requires access to the mailbox for each user who is migrated. By default, only the owner of the mailbox has access. Everyone else, including Lotus Domino administrators, is denied access. There are two ways for the user ID used by the Exchange Migration Wizard to gain access to users' mailboxes:

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 75

•

Have users grant access to their mailboxes using Lotus Notes The most direct way to gain access to a user's mailbox is for the user to grant it. Using their Lotus Notes clients, all users should grant access to the user ID used by Connector for Lotus Notes. Each user who migrates to Exchange should first perform the following procedure. In Lotus Notes, on the menu bar, click File, point to Database, and then click Access Control.

•

Create a link from the local database to the Lotus Domino database The second way to gain access to a user's mailbox is to establish a link to the Lotus Domino database from the local database and then update the ACL on the user's mailbox through the link in Lotus Domino Administrator. For security reasons, you should delete the folder link after you update the ACLs on the users' mailboxes.

76 Exchange Server 2003 Interoperability and Migration Guide

2.

Migrate data from Lotus Domino to Exchange 2003 The next step in performing a migration from Lotus Domino to Exchange 2003 is to migrate the users and mailboxes from the Lotus Domino server to the Exchange 2003 server. You do this by running the Exchange Migration Wizard on an Exchange 2003 server with Lotus Notes Client (for example, the server you configured to run Connector for Lotus Notes). Before you start, ensure that the installation path for the Lotus Notes client on the Exchange 2003 server is in the system path, as illustrated with step-by-step instructions in Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality." The Exchange Migration Wizard stops responding if the Lotus Notes installation path is not in the Windows system path. Important Stop the Connector for Lotus Notes service during migration to prevent directory synchronization from deleting Lotus Domino mailboxes before you verify that migration is successful. If a migration attempt ends unsuccessfully, delete any mailboxes and recipient objects created during the migration attempt from Active Directory. Restart the Connector for Lotus Notes, and perform a manual directory synchronization. For more about troubleshooting migration problems, see Chapter 5, "Troubleshooting Interoperability and Migration Issues."

It is often sufficient to accept the defaults in the Exchange Migration Wizard. However, if you have specific needs, you can change the following options on the Migration Information wizard page: •

Information to create mailboxes When selected, a new mailbox is created for users migrated from Lotus Domino to Exchange.

•

Personal e-mail messages When selected, the user's e-mail messages that are stored on the Lotus Domino server are migrated to Exchange. You can either select All to migrate all of the user's e-mail messages, or Dated from to specify a date range of messages to migrate.

•

Schedule information When selected, the user's schedule information is migrated to Exchange. You can either select All to migrate all of the user's schedule information, or Dated from to specify a date range of schedule information to migrate. Note Any meeting requests in users' Inboxes that have not been accepted are migrated as text messages. Users must manually add these meetings to their calendars. Before you complete the migration, ensure that users accept any outstanding meeting requests.

•

Specify how to convert Notes DocLinks You can select the format that the Exchange Migration Wizard uses to convert Lotus Notes document links: •

OLE document link This format is represented by an icon in the Exchange message. When the user clicks the icon, Lotus Notes is started, and the document link works as usual, provided that the ID file that is being used has access to the document (Lotus Notes must be installed on the client).

•

RTF attachment (default) The document is converted to an RTF attachment. Because this attachment is a copy of the data from the actual Lotus Notes document, users are not able to edit the document.

•

URL shortcut This format converts the link to a URL. Clicking the URL starts the default Web browser, which attempts to access the server running Lotus Domino to which the link points. (The user still requires a Lotus Notes name, password, and license to access the document, unless anonymous authentication is allowed.)

The Exchange Migration Wizard creates a mailbox-enabled Active Directory account for each user being migrated. All new user accounts are placed in the target organizational unit that you select on the Container for New Windows Accounts page. If accounts already exist in Active Directory, for example because you created disabled Windows accounts for all Lotus Notes users through directory

Chapter 2: Migrating from Lotus Notes/Domino Messaging Infrastructures 77

synchronization beforehand, you must verify that the accounts are matched correctly. You can associate the correct account using the Find Existing Account option on the Windows Account Creation and Association page. You can also create a new account, using the Create New Account option. For new accounts, the Exchange Migration Wizard can generate a random strong password, which is stored in the Accounts.Password file in the \Program Files\Exchsrvr\Bin directory on the Exchange 2003 server. After migration is complete, review the Application Log for information about the migration progress. Look for event log messages the source of which is MSExchangeMig. It might be helpful to configure and apply a filter in Event Viewer to list only those event log messages from the Exchange Migration Wizard. 3.

Migrate calendar information The Exchange Migration Wizard migrates calendar information by generating a SCHEDULE+ FREE BUSY public folder import file for each user. This file contains the user's schedule information. Users receive this file as an attachment to a new message in their Inboxes. Your users must manually import their schedule data.

Message Conversion Issues When the Exchange Migration Wizard migrates data, it converts Lotus Domino messages and other items to Exchange 2003 formats. Table 2.4 shows how certain Lotus Domino items are converted during migration to Exchange 2003. Table 2.4 Lotus Domino item conversion Lotus Domino item

Converted to Exchange 2003

Task request

Converts as a text-based read note

Phone message

Converts as a text-based read note

Routing slip

Converts as a text-based read note

Calendar data

Converts as a SCHEDULE+ FREE BUSY public folder attachment

Table 2.5 shows how Lotus Notes message formatting is converted during the migration process. Table 2.5 Lotus Notes message formatting conversion Lotus Notes formatting

Converted to Microsoft Outlook

Size

Converts correctly.

Color

Converts correctly.

Bold

Converts correctly.

Underline

Converts correctly.

Italic

Converts correctly.

Strikethrough

Converts correctly.

Tables

Convert correctly if Word is used as the primary email editor in Outlook, but formatting is lost. Does not convert correctly if Outlook is the e-mail editor.

Embedded OLE objects, including graphics

Convert correctly, can be edited.

78 Exchange Server 2003 Interoperability and Migration Guide

Lotus Notes formatting

Converted to Microsoft Outlook

Double strikethrough

Does not convert.

Superscript

Does not convert.

Subscript

Does not convert.

Shadow

Does not convert.

Outline

Converts to italic.

Emboss

Does not convert.

Engrave

Does not convert.

Small caps

Does not convert.

All caps

Does not convert.

Drop caps

Does not convert.

Hidden

Does not convert, text is visible.

Underline other than single

Does not convert.

Bitmaps not embedded as OLE objects

Do not convert. Formatting is lost.

Bullets

Do not convert.

Table 2.6 shows how Lotus Notes folders convert to Exchange 2003 folders. Table 2.6 Lotus Notes folder conversion Lotus Notes folder

Exchange 2003 folder

Inbox

Converts correctly.

SubFolder

Converts correctly.

ToDo

Converts to ToDo items. Converts to Outlook Tasks only if items appear in the Notes Calendar View.

Drafts

Converts to Drafts.

C H A P T E R

3

Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures

This chapter describes how to deploy Microsoft® Exchange Server 2003 in a Novell GroupWise messaging environment and how to migrate from Novell GroupWise to an Exchange 2003 messaging environment using the tools that are included with Exchange Server 2003. At the end of this chapter, you should have a basic understanding of how to integrate Exchange 2003 into a Novell GroupWise environment using Microsoft Exchange Connector for Novell GroupWise and Microsoft Exchange Calendar Connector, and how to use the Exchange Migration Wizard to migrate Novell GroupWise users and mailboxes to Exchange 2003. Note Microsoft does not officially support interoperability with or migration from Novell GroupWise 6.0 or later. However, because the underlying technologies that are used for interoperability and migration remain the same as in earlier versions, Microsoft Product Support Services offers "commercially reasonable effort" support. An alternative to using Connector for Novell GroupWise for interoperability and directory synchronization is the Novell GroupWise Gateway for Microsoft Exchange. You might want to use this connector if you plan to migrate from Novell GroupWise 6.0 or later to Exchange 2003.

Before you deploy Exchange 2003 in a Novell GroupWise environment, you must have a thorough understanding of basic Novell NetWare, Novell Directory Services (NDS), and Novell GroupWise concepts. You also must have a thorough understanding of Exchange 2003, and Microsoft Windows Server™ 2003 deployment and administration concepts. If you are unfamiliar with concepts such as Novell GroupWise domains, post offices, the Active Directory® directory service and Exchange connectors, you must familiarize yourself with these concepts before deploying Exchange 2003. For more information, see Appendix F, "Resources." This chapter is divided into several main sections, which correspond to the order of steps in a multiphase migration from Novell GroupWise to Exchange 2003, as follows: 1.

Familiarizing yourself with interoperability issues between Exchange 2003 and Novell GroupWise

2.

Implementing Exchange 2003 to Novell GroupWise connectivity

3.

Configuring directory synchronization between Exchange 2003 and Novell GroupWise

4.

Implementing calendar connectivity

5.

Migrating from Novell GroupWise to Exchange 2003

80 Exchange Server 2003 Interoperability and Migration Guide

If you plan to migrate from Novell GroupWise to Exchange 2003 in a single step, you can go directly to the section "Migrating from Novell GroupWise to Exchange Server 2003." Note This chapter discusses Connector for Novell GroupWise, Calendar Connector, and Exchange Migration Wizard configuration tasks at a conceptual level. For detailed step-by-step instructions that outline how to configure Novell GroupWise and Exchange 2003 for messaging interoperability and migration, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

Understanding Interoperability Between Exchange and Novell GroupWise Exchange Server 2003 includes four tools for interoperability and migration between Novell GroupWise and Exchange 2003: •

Connector for Novell GroupWise Connector for Novell GroupWise supports bidirectional message transfer and directory synchronization. When you deploy Connector for Novell GroupWise, users of both messaging systems can interact with each other as if they are members of the same messaging system. This interoperability might be temporary (for example, the systems might need to coexist only while you migrate users from Novell GroupWise to Exchange 2003). In other cases, long-term coexistence might be required (for example, the messaging system of a department that is not moving to Exchange 2003 might require a permanent connection).

•

Calendar Connector Calendar Connector, in conjunction with Connector for Novell GroupWise, provides Exchange 2003 and Novell GroupWise users with almost real-time access to free/busy calendar information. Calendar Connector runs as a service on an Exchange server.

•

Exchange Migration Wizard The Exchange Migration Wizard is a tool that you can use to migrate users from Novell GroupWise to Exchange 2003. The Exchange Migration Wizard supports migration from Novell GroupWise to Exchange 2003 by copying existing mailboxes, messages, and other data, and importing that information into Exchange 2003, as explained in Chapter 1, "Understanding Interoperability and Migration."

•

Active Directory Cleanup Wizard The Active Directory Cleanup Wizard is a tool that you can use to merge duplicate Active Directory user accounts and contact objects into a single user account. This is not strictly a migration tool, but it can be useful during a migration from Novell GroupWise. Duplicate user accounts might be created, for example, if you use Microsoft Directory Synchronization Services (MSDSS) to replicate NDS with Active Directory and then use Connector for Novell GroupWise or the Exchange Migration Wizard to import directory information from Novell GroupWise into Exchange 2003/Active Directory. In this situation, the creation of duplicate accounts is intentional, because MSDSS operates independently of Connector for Novell GroupWise and the Exchange Migration Wizard. MSDSS is included in Microsoft Windows® Services for NetWare 5.0 Service Pack 1 to facilitate the introduction of Microsoft Windows Server™ 2003 and Active Directory into a Novell NetWare network environment with NDS or Novell eDirectory.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 81

Message Conversion and Transfer To transfer messages between Novell GroupWise and Exchange 2003 using Connector for Novell GroupWise, consider installing the connector on a dedicated bridgehead server (Figure 3.1). A specific bridgehead server can run exactly one connector instance. One connector can service one direct Novell GroupWise domain and an entire Exchange 2003 organization. A GroupWise Message Transfer Agent (GWMTA) is required in the Novell GroupWise domain to route messages within the Novell GroupWise environment to post offices, other domains, or external foreign domains.

Figure 3.1 Connecting Novell GroupWise and Exchange 2003 using Connector for Novell GroupWise The most fundamental element of a Novell GroupWise domain is the post office. Post offices are serviced by post office agents (POAs). POAs are the communication partners of GWMTAs, which deliver messages between GroupWise post offices within a domain, between post offices and gateways within a domain, and between domains within a Novell GroupWise organization. One GWMTA is required for each domain. For communication between a Novell GroupWise organization and other mail systems, such as Exchange 2003, you must deploy a gateway. For example, Connector for Novell GroupWise requires the Novell GroupWise API Gateway version 4.1 to connect to the Novell GroupWise domain. The connector uses the Novell GroupWise API Gateway version 4.1 to send and receive messages and to synchronize recipient

82 Exchange Server 2003 Interoperability and Migration Guide

information. To download Novell GroupWise API Gateway version 4.1, and for installation instructions, see the Novell Support Web site (http://support.novell.com). Note To support distribution list expansion during message delivery to Novell GroupWise, you must install Patch 2 for the GroupWise version 4.1 API for NetWare Loadable Module (NLM) on the Novell NetWare server that is running the connector's API Gateway. This patch is available from Novell.

Figure 3.2 shows the process for sending messages from Exchange 2003 to Novell GroupWise.

Figure 3.2 Sending messages from Exchange 2003 to Novell GroupWise The process for message transfer between Exchange 2003 and Novell GroupWise can be divided into four steps: 1.

Exchange 2003 determines that the recipient is a Novell GroupWise user (based on the target address of the user) and sends the message to the Exchange message transfer agent (MTA).

2.

The MTA delivers the message to the MTS-OUT directory, from which the LSMEXOUT process retrieves it, looks up Active Directory to replace target recipient information with corresponding GroupWise addresses, and delivers the message to the READYOUT folder.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 83

3.

The MEX2GW process converts the message to Novell GroupWise format before writing it as header and body files into the connector store on the Exchange server. Note The connector store is a file structure in the \Program Files\Exchsrvr\Conndata directory with subdirectories, such as \Dxagwise and \Gwrouter. Header and body files are keyword-based text files that the GroupWise API Gateway uses to communicate with Connector for Novell GroupWise. You can use a text editor, such as Microsoft Notepad, to read and write keywordbased text files in the API Gateway directory structure.

4.

The Exchange Router for Novell GroupWise service (GWROUTER) places the message in the directory of the Novell GroupWise API Gateway. The gateway works in conjunction with the GWMTA for delivery in the GroupWise organization.

Figure 3.3 shows the process for sending messages from Novell GroupWise to Exchange 2003.

Figure 3.3 Sending messages from Novell GroupWise to Exchange 2003 The process for message transfer from Novell GroupWise to Exchange 2003 can also be divided into four steps: 1.

The Router for Novell GroupWise service obtains the message from the API Gateway in the form of header and body files and places them in the connector store.

2.

The GW2MEX process converts the header and body files to a message in Exchange 2003 format before it places the message into the READYIN folder.

84 Exchange Server 2003 Interoperability and Migration Guide

3.

The LSMEXIN process obtains the converted message from the READYIN folder, verifies the validity of the recipient (converting the address into X.400 format, if necessary), and delivers the message to the MTS-IN folder.

4.

The Exchange store then processes the message from the MTS-IN folder and places it in the Simple Mail Transfer Protocol (SMTP) service's MTS-OUT folder, from which it is then routed to its destination in the Exchange organization.

Message Conversion Novell GroupWise supports several specific types of messages, such as e-mail messages, appointments, notes, tasks, forms, presentations, and documents. MAPI message types are mapped to corresponding message types in Novell GroupWise, when possible. In other words, e-mail messages appear as e-mail messages, meeting requests as appointments, and so on. Message types that are not supported in Exchange 2003, such as Novell GroupWise phone messages, are converted to regular e-mail items. Connector for Novell GroupWise is able to track delivery confirmation reports, read receipts, and non-delivery reports (NDRs). Connector for Novell GroupWise does not process free/busy information when creating meeting requests or appointments that are transferred between Novell GroupWise and Exchange 2003. To perform a free/busy query between the two systems to show attendee availability before scheduling an appointment, you must deploy Calendar Connector in addition to Connector for Novell GroupWise, as discussed later in this chapter. Table 3.1 Message conversion between Novell GroupWise and Exchange 2003 Exchange 2003 feature

GroupWise feature

GroupWise to Exchange 2003

Exchange 2003 to GroupWise

E-mail messages

Messages

Yes

Yes

E-mail read receipt

E-mail read receipt

Yes

Yes

Non-delivery report

Non-delivery report

Yes

Yes

Importance

Importance

Yes

Yes (low priority does not have a representation in GroupWise)

Sensitivity

Sensitivity

Yes

Yes

Meeting requests

Appointments

Yes

Yes

Meeting accepted

Meeting accepted

Yes

Yes

Meeting declined

Meeting declined

Yes

Yes

Meeting tentatively accepted

Meeting accepted

Appear as "Accepted"

Appear as "Accepted"

Meeting request read

Meeting request read

Yes

Yes

Meeting request delivery

Meeting request delivery

Yes

Yes

Meeting updates

Meeting updates

Appear as new meeting requests containing the word "Updated" in the subject line

Appear as new meeting requests containing the word "Updated" in the subject line

Meeting reminder times

Meeting reminder times

No

No

Meeting cancellation

Meeting cancellation

No

Yes

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 85

Exchange 2003 feature

GroupWise feature

GroupWise to Exchange 2003

Exchange 2003 to GroupWise

Task requests

Tasks

Task requests appear as e-mail messages

Tasks appear as e-mail messages

All day meeting requests

Meeting requests

Yes

Appear as meeting requests; however, if the meeting extends over multiple days, it is placed as a single instance on the first day with the date range in the message field

N/A

Phone messages

Appear as e-mail messages

N/A

Other messages

Other messages

Default to e-mail messages

Default to e-mail messages

Note Connector for Novell GroupWise does not support signed or encrypted messages.

E-Mail Message Type Conversion E-mail messages that originate in either Exchange or Novell GroupWise are converted to the format of the target system. Connector for Novell GroupWise also tracks message delivery by using delivery confirmation reports, read receipts, and non-delivery reports. Connector for Novell GroupWise handles meeting requests and phone messages as follows: •

Meeting Requests and Appointments Exchange meeting requests and Novell GroupWise appointments are exchanged through Connector for Novell GroupWise. Updated meeting requests are identified as "Updated" in their subject lines. Because of a limitation of the GroupWise API Gateway, meeting requests sent from Exchange 2003 users to GroupWise users cannot be updated automatically in Novell GroupWise and must be updated manually by the user. Note The API Gateway does not support recurring meeting requests from GroupWise that use the AutoDate feature. These recurring meeting requests are not transferred to Exchange 2003. Recurring meetings transferred from Exchange 2003 to Novell GroupWise are added to the Novell GroupWise calendar once, and recurring information is then displayed at the top of the message body. It is the user's responsibility to remember when the meetings take place or to enter multiple meeting occurrences individually in the calendar.

•

All Day Meeting Requests All day meeting requests generated in Exchange 2003 appear as meeting requests in Novell GroupWise. However, if the meeting is stretched over multiple days, the connector creates a single instance on the first day with the date range in the message field.

•

Phone Messages Novell GroupWise phone messages appear as e-mail messages in Exchange 2003.

86 Exchange Server 2003 Interoperability and Migration Guide

E-Mail Message Property Conversion Objects embedded in messages sent by Exchange 2003 clients (Microsoft Office Outlook®) are converted to attachments. These attachments, if embedded more than one level deep, appear as attachments of the primary message. If a Novell GroupWise user sends a message including an attached message that contains additional attachments, all attachments appear in Exchange 2003 as single attachments to the primary message. Table 3.2 E-mail message conversion between Novell GroupWise and Microsoft Outlook Novell GroupWise

Microsoft Outlook

Size

Converts correctly.

Color

Ignored.

Bold

Ignored.

Underline

Ignored.

Italic

Ignored.

Strikethrough

Converts correctly.

Tables

Convert correctly if Microsoft Word is used as the primary e-mail editor in Outlook. Do not convert correctly in Outlook.

Embedded OLE objects, including graphics

Convert correctly and can be edited.

Double strikethrough

Ignored.

Superscript

Ignored.

Subscript

Ignored.

Shadow

Ignored.

Outline

Converts to italic.

Emboss

Ignored.

Engrave

Ignored.

Small caps

Ignored.

All caps

Ignored.

Drop caps

Ignored.

Hidden

Ignored, text is visible.

Underline other than single

Ignored.

Bitmaps not embedded as OLE objects

Not migrated, formatting is lost.

Bullets

Ignored.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 87

Directory Synchronization Directory synchronization is the process of propagating directory information about Exchange 2003 users from Active Directory to the directory of a Novell GroupWise system, while propagating information about Novell GroupWise users to Active Directory for Exchange 2003 to use. When directory synchronization is complete, each system has a complete copy of the directory data (users, groups, and so on) for the combined messaging organization. Directory synchronization consists of two sequential processes: •

Synchronizing recipients from Active Directory to Novell GroupWise

•

Synchronizing recipients from Novell GroupWise to Active Directory

Using Connector for Novell GroupWise, you can enable automatic, scheduled directory synchronization between Exchange 2003 and Novell GroupWise. You can also begin directory synchronization on demand. The process is bidirectional during scheduled directory synchronization. User attributes are updated in both directories. Each time directory synchronization occurs, Connector for Novell GroupWise pulls information from Active Directory. This is the task of the DXAMEX process. This component works in conjunction with the DXAGWISE process that converts the address information into administration messages. The administration messages are placed in the connector store for delivery to the API Gateway, together with a request for GroupWise directory information. Novell GroupWise receives the information through the API Gateway, updates its directory, and replies to the directory request by polling its own directory. The API Gateway returns the GroupWise directory information to Connector for Novell GroupWise. DXAGWISE converts the address information received from GroupWise and delivers it to DXAMEX to apply it to Active Directory. Figure 3.4 shows the directory connection between Exchange 2003 and Novell GroupWise.

Figure 3.4 Directory synchronization between Novell GroupWise and Exchange 2003 Note Connector for Novell GroupWise synchronizes all valid Novell GroupWise users, resources, and distribution lists that have a GroupWise visibility setting of "system". Items with a visibility other than system are excluded from directory synchronization. Furthermore, Connector for Novell GroupWise does not synchronize recipient objects to Active Directory that contain a forward slash (/) in their name or exceed 50 characters.

88 Exchange Server 2003 Interoperability and Migration Guide

Synchronizing Directory Entries from Novell GroupWise to Active Directory When synchronizing directory entries from Novell GroupWise to Active Directory, Connector for Novell GroupWise generates a request to the GroupWise directory and puts the request into the input queue of the GroupWise API Gateway. The Novell GroupWise system generates a response after polling the GroupWise directory and Connector for Novell GroupWise updates Active Directory with new recipient objects and any changes to existing recipients that were made to GroupWise attributes, such as Telephone, Address, and so forth. It is recommended that you create a designated organizational unit for all GroupWise users in Active Directory for use during the migration process. During synchronization, existing Novell GroupWise recipients are created as user accounts or contacts in Active Directory. You can create the following types of user accounts in Active Directory: •

Disabled Windows user accounts Create disabled Windows user accounts if your Novell GroupWise users are not in your Active Directory environment yet, but will be after migration to Exchange 2003.

•

New Windows user accounts Create enabled Windows accounts for Novell GroupWise users who work in your Active Directory environment before migration.

•

Windows contacts Create Windows contacts for Novell GroupWise users who are not in your Active Directory environment. The Exchange Migration Wizard can convert these contact objects to user accounts during the migration process.

Synchronizing Directory Entries from Active Directory to Novell GroupWise When synchronizing directory entries from Exchange 2003 to Novell GroupWise, Connector for Novell GroupWise polls Active Directory and creates an export message that contains the transactions necessary to update existing contacts or create new contacts in the Novell GroupWise directory. Connector for Novell GroupWise allows you to filter addresses that you synchronize from Exchange 2003 to Novell GroupWise. You can use the address filters to: •

Define containers that hold subsets of Exchange 2003 users and select only the appropriate containers to synchronize to Novell GroupWise For example, you might synchronize your existing Novell GroupWise users to a specific container in Active Directory. You then choose not to synchronize the Active Directory container that holds the Novell GroupWise users, because they already exist in the Novell GroupWise directory.

•

Choose whether to synchronize contacts to Novell GroupWise If your Exchange 2003 organization is connected to multiple non-Exchange messaging systems (or if you created mail-enabled contacts for recipients on the Internet), you can propagate this information to Novell GroupWise. Users on Novell GroupWise can then conveniently communicate with all users in your messaging environment. However, you must examine your directory synchronization carefully to avoid duplicating address information, which might happen if the other non-Exchange messaging system is already synchronizing its directory with Novell GroupWise.

•

Choose whether to synchronize groups (distribution lists) to Novell GroupWise Connector for Novell GroupWise supports propagation of the names of groups (distribution lists) to Exchange 2003 and Novell GroupWise. However, the tool does not synchronize group membership. The target system (either Exchange 2003 or Novell GroupWise) automatically expands the group for message delivery to the members of the distribution list. Groups can contain members from both systems, but the members appear in the other mail system (Novell GroupWise or Exchange 2003) as contacts. You can address

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 89

distribution group issues in various ways, as discussed in Chapter 1, "Understanding Interoperability and Migration."

Mapping Attributes The directory synchronization component of Connector for Novell GroupWise synchronizes a subset of the many attributes supported by the Active Directory and Novell GroupWise directories. The default schema for each directory is defined in schema definition files. Files that contain mapping rules define how attributes from one schema correspond to attributes in another schema. Some attributes correspond in direct attributeto-attribute pairs; for example, when the GroupWise directory is synchronized with Active Directory, the Exchange 2003 attribute company is assigned the value of the attribute company in the GroupWise directory. The schema definition and mapping rule files in the \Program Files\Exchsrvr\Conndata\Dxagwise directory have the following purposes: •

GWAMAP.TBL Specifies GroupWise schema attributes to be synchronized.

•

MAPMEX.TBL Determines the attribute mapping from Exchange 2003 to Novell GroupWise.

•

MEXAMAP.TBL Specifies Exchange schema attributes to be synchronized.

•

MAPGWISE.TBL Determines the attribute mapping from Novell GroupWise to Exchange 2003. Note You can customize the control files in Notepad to change the attribute mapping. Remember to stop the connector services before you edit these files to ensure that the directory synchronization is not active. In addition, there are control files for the connector to check for address updates that require synchronization (EXTERNAL.TBL, GWPCTA.TBL, MEXPCTA.TBL). Do not edit these files manually.

Calendar Synchronization Calendar Connector provides Novell GroupWise and Exchange 2003 users with almost real-time access to free/busy status information. Queries from Exchange users reach the Novell GroupWise organization through Novell GroupWise API Gateway in the form of e-mail messages. A special class of mail object (with MSGTYPE = SEARCH) is sent as a high-priority message through the Novell GroupWise network from the sender's post office to the post office of the target user. Requests for free/busy data are processed by the home post office of the target user. The response is an e-mail message consisting of a list of busy dates and times. The API Gateway routes the message according to the MSG-TYPE keyword. Note Calendar Connector relies on Connector for Novell GroupWise to transfer free/busy information. It is recommended that you install both connectors on the same Exchange 2003 server.

Calendar Synchronization from Novell GroupWise to Exchange 2003 This section explains how Calendar Connector enables Exchange 2003 users to view the free/busy information for Novell GroupWise users. Calendar Connector processes the request by checking a system public folder named SCHEDULE+ FREE BUSY, which stores free/busy information for an administrative group in the Exchange 2003 organization. The following is an explanation of what happens when an Exchange 2003 user queries the calendar information for a Novell GroupWise user:

90 Exchange Server 2003 Interoperability and Migration Guide

1.

When an Exchange user queries a Novell GroupWise user's free/busy information, Calendar Connector intercepts the request.

2.

Calendar Connector checks for current free/busy information for the Novell GroupWise user in the SCHEDULE+ FREE BUSY public folder replica on the server on which Calendar Connector is installed. If the information has been updated within a preconfigured number of minutes, Calendar Connector returns the information to the user who is requesting it. If the information in the public folder is not found or not updated within the time allotted, Calendar Connector translates the request for free/busy information into a SEARCH-type message and transmits it to Connector for Novell GroupWise. Connector for Novell GroupWise deposits the message into the API Gateway's input queue. Note By default, Calendar Connector uses the cached free/busy information rather than querying Novell GroupWise if fewer than 15 minutes have passed since the Novell GroupWise user's calendaring information was requested. You can adjust this time period in the Calendar Connector properties if necessary. For step-by-step instructions for how to configure Calendar Connector, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

3.

The API Gateway forwards this request to Novell GroupWise. The SEARCH-type message is routed and processed just like a request that is generated from another Novell GroupWise user. The API Gateway's GWMTA routes the free/busy request to the appropriate target domain and post office. The GroupWise post office agent processes the free/busy request, and then sends the response back to the GWMTA. The GWMTA routes the results to the output queue of the API Gateway.

4.

Connector for Novell GroupWise picks up the response from the API Gateway output queue and delivers it to Calendar Connector. Exchange Connector for Novell GroupWise then deletes the file from the API Gateway output queue.

5.

Calendar Connector parses the file, translates the Novell GroupWise user's free/busy information into Exchange 2003 format, and writes the response to the Exchange 2003 SCHEDULE+ FREE BUSY system public folder.

6.

Calendar Connector sends the updated information to the Exchange 2003 user who requested it.

Figure 3.5 shows the process by which free/busy information is synchronized between Novell GroupWise and Exchange 2003. In this figure, an Exchange 2003 user is querying for the free/busy information of a Novell GroupWise user.

Figure 3.5 Calendar interoperability through Calendar Connector and Connector for Novell GroupWise You can set the following options on Calendar Connector: •

The number of days of free/busy information to request from the other system's calendars.

•

The maximum number of minutes that the Novell GroupWise system's free/busy information is stored in Exchange 2003 before querying the Novell GroupWise server for updated free/busy information.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 91

•

The maximum number of seconds that Calendar Connector waits for responses from Novell GroupWise. If Calendar Connector does not receive a response in the time that you specify, it returns the information currently stored in the SCHEDULE+ FREE BUSY public folder to the Exchange client.

Calendar Synchronization from Exchange 2003 to Novell GroupWise Here the query is reversed, and free/busy information from Exchange 2003 is synchronized to Novell GroupWise using Calendar Connector. The following is an explanation of what happens when a Novell GroupWise user queries the calendar information for an Exchange 2003 user: 1.

When a Novell GroupWise user queries for free/busy information of an Exchange user, the request is sent to the GroupWise post office agent, which receives the free/busy request and sends it through the GWMTA to the Novell GroupWise API Gateway. The API Gateway converts the request and places the files in the output queue of the API Gateway.

2.

Connector for Novell GroupWise obtains the request from the API Gateway and forwards it to Calendar Connector. Connector for Novell GroupWise then deletes the request from the API Gateway output queue.

3.

Calendar Connector processes the request and queries the Exchange SCHEDULE+ FREE BUSY public folder for the requested information.

4.

Calendar Connector translates the requested free/busy data of Exchange 2003 users into GroupWise format and delivers the information to Connector for Novell GroupWise.

5.

Connector for Novell GroupWise places the free/busy data in the input queue of the API Gateway. The API Gateway then routes the free/busy report to the GroupWise system for delivery. The GWMTA relays the information to the GWMTA of the domain where the original requestor was located, and then to the requestor's GroupWise client. Note Novell GroupWise users must be added to Active Directory as mail-enabled recipients (through directory synchronization), so that Exchange 2003 has the correct address information. To achieve this, Novell GroupWise users must have a visibility setting of System or higher.

Querying Groups You can query free/busy information for a group created in Exchange 2003 that contains GroupWise users. However, you cannot query free/busy information for groups that are hosted on GroupWise systems. In other words, an Exchange 2003 user cannot query a GroupWise group, regardless of the system in which the group's members reside.

System Attendant Dependencies Calendar Connector uses the System Attendant service to query Novell GroupWise for free/busy information. Any request from an Exchange user for a Novell GroupWise user originates from System Attendant. Therefore, it is critical that you assign System Attendant a Novell GroupWise e-mail address of the type GWISE. You must enable the generation of GWISE proxy addresses for your Exchange users in the default recipient policy. For more information about the configuration of recipient policies, see Chapter 1, "Understanding Interoperability and Migration."

92 Exchange Server 2003 Interoperability and Migration Guide

Supported Calendar Synchronization Implementations Exchange supports the following implementation scenarios: •

A single Calendar Connector with a single connection to a Novell GroupWise organization

•

Multiple administrative groups, each with their own Calendar Connector, connected to the same Novell GroupWise organization

•

A single Calendar Connector that queries users on an upstream domain

Exchange does not support the following implementation scenarios: •

Multiple Calendar Connectors within a single administrative group connected to the same Novell GroupWise organization

•

Free/busy switching or querying from one co-existence partner to another using Exchange as a backbone

•

Novell GroupWise as a backbone between two Exchange systems

Implementing Exchange to Novell GroupWise Connectivity In theory, you need only a single Exchange 2003 server to use Connector for Novell GroupWise. However, it is not recommended that you run Connector for Novell GroupWise on an Exchange server that hosts mailboxes. Therefore, you should have at least one Exchange 2003 server that includes your Exchange mailboxes and a separate Exchange 2003 server that includes Connector for Novell GroupWise. To simplify the discussion of how to configure Exchange 2003 to interoperate with a Novell GroupWise environment, this section is based on the assumption that you have a single Novell GroupWise post office. However, the information provided here can be applied to larger or more complex Novell GroupWise deployments. In larger deployments, the Novell GroupWise domain that you configure here acts as the bridgehead for other Novell GroupWise domains and post offices. Figure 3.6 shows the minimum Windows and Exchange 2003 configuration that you should consider for configuring and testing interoperability with Novell GroupWise.

Figure 3.6 Basic Windows and Exchange environment Note The following is a conceptual discussion of the steps involved in configuring the Connector for

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 93

Novell GroupWise. For detailed step-by-step instructions for configuring Novell GroupWise and Connector for Novell GroupWise, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

94 Exchange Server 2003 Interoperability and Migration Guide

You must complete the following steps to configure Connector for Novell GroupWise: 1.

Ensure that prerequisites are met Before you install Connector for Novell GroupWise on a new Exchange 2003 server, you must ensure that the Exchange 2003 server has Novell NetWare connectivity and can resolve the name of the Novell NetWare server running the API Gateway. All access to Novell GroupWise from Exchange 2003 is gained through the API Gateway using keyword-based text files. The advantage is that Exchange interacts with Novell GroupWise using Novell-supported technology. To communicate with Novell NetWare, either Gateway and Client Services or Novell NetWare Client for Windows must be installed on the Exchange 2003 server and Connector for Novell GroupWise. Note If your Novell NetWare environment is based on TCP/IP, use Novell NetWare Client for Windows to integrate the Exchange 2003 server into your Novell NetWare environment. Novell NetWare 4.8 is the preferred Novell Directory Services (NDS) client. If you want to use Gateway and Client Services instead, remember that this system configuration requires the NWLink (IPX/SPX) protocol between the Exchange 2003 server and the Novell API Gateway server. You must configure IPX routing in your TCP/IP-based Novell NetWare network to support Gateway and Client Services.

In addition, ensure that the server running Novell NetWare and Novell GroupWise has the following software installed:

2.

•

Novell NetWare 3.x

•

Novell NetWare Administrator

•

Novell GroupWise 4.1 or later

Prepare NDS and Novell GroupWise To support Connector for Novell GroupWise, you must deploy a dedicated API Gateway and configure a foreign GroupWise domain for your Exchange 2003 organization in the Novell NetWare Administrator program. You must work with Novell NetWare Administrator on a workstation where the GroupWise administration files have been installed. You must complete the following steps to prepare NDS and Novell GroupWise for interoperability with Exchange 2003: a.

Install the Novell GroupWise API Gateway on a Novell NetWare server You should use the NLM version of the API Gateway for Connector for Novell GroupWise. For installation, copy the corresponding gateway files to a directory on your NetWare server. Before you start the actual installation, it is a good idea to create a gateway directory in the \Wpgate subdirectory of your GroupWise domain (for example, \API41). On the System Console, run NWConfig to install the API Gateway in the NetWare Configuration program. Note It is recommended that you install Patch 2 for the GroupWise 4.1 API Gateway for NLM on the Novell NetWare server that is running the API Gateway. This patch is available from Novell in the form of a self-extracting file called GW41API2.exe, at http://support.novell.com.

b.

Configure the API Gateway in the Novell GroupWise domain After you have installed the GroupWise API Gateway files, you must start the Novell NetWare Administrator program and create a gateway object in the Novell GroupWise domain. You must create a GroupWise Gateway in the GroupWise domain object. Remember to enable directory synchronization for this object.

c.

Create a foreign domain document for the Exchange organization in the Novell GroupWise domain, and link it to the API Gateway To complete the configuration, create an external foreign domain for your Exchange organization and configure the link table of the GroupWise domain to connect the external foreign domain to your GroupWise domain through the API Gateway. Otherwise, Novell GroupWise cannot route messages to Exchange users.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 95

d.

Configure security for the API Gateway directory It is recommended that you restrict access to the API Gateway directory, because the gateway is able to perform management functions similar to a Novell NetWare Administrator. The following API Gateway directories are most important: •

API_IN Receives incoming message header files from non-GroupWise systems

•

API_OUT Holds outgoing message header files to non-GroupWise systems

•

ATT_IN Receives incoming message bodies and attachments from non-GroupWise systems

•

ATT_OUT Holds outgoing message bodies and attachments to non-GroupWise systems

•

WPCSIN The GWMTA inbound queue where incoming messages are placed after they are processed through the API Gateway

•

WPCSOUT The GWMTA outbound queue where outgoing messages are located before they are converted into keyword-based text files and placed into API_OUT and ATT_OUT through the API Gateway

To identify Connector for Novell GroupWise and grant it permissions to read and write messages in the API input and output directories, a dedicated Novell NetWare account is required. You must create this account using Novell NetWare Administrator and then use the Exchange System Manager Microsoft Management Console (MMC) snap-in to configure the connector (on the General tab) to use this account for API Gateway access. Note The connector's NetWare account must be a member of a special group called NTGATEWAY, which you need to create using Novell NetWare Administrator. The connector's NetWare account requires permissions to create, read, write, and delete files in the API Gateway directories.

3.

Install Exchange 2003 with Connector for Novell GroupWise After you configure your Novell GroupWise environment, you can install Exchange 2003 on a dedicated connector server. As part of this setup, you install Connector for Novell GroupWise. You must have Exchange Administrator permissions in the administrative group where the connector's target routing group exists to install Exchange 2003 on the server, and you must be a member of the local Administrators group on the server on which you install Exchange 2003.

4.

Prepare the Exchange 2003 environment Next, you must enable Novell GroupWise proxy addresses on the server running Exchange 2003 with Connector for Novell GroupWise installed. By default, Novell GroupWise users see Exchange users as recipients in an external foreign domain called Exchange. The post office name corresponds to the administrative group name. The Recipient Update Service automatically generates the proxy addresses for each mailbox- and mail-enabled account in the Exchange organization using a proxy address generator. The GroupWise proxy address generator is GWXPXGEN.DLL, which resides in the Program Files\Exchsrvr\Address\Gwise\i386 directory. It is possible to customize GWISE proxy addresses through recipient policies in Exchange System Manager. Make sure that GWISE address is enabled and then customize the address generation rule. For example, you might want to shorten or change the reference to the post office name, which by default refers to the administrative group, but you cannot remove the post office name portion of the address. GroupWise addresses must conform to the GroupWise naming convention of domain.post office.user alias. Do not change the domain name portion until you have created a corresponding external foreign domain in GroupWise. You can use the placeholders listed in Table 3.3 to customize GWISE address generation (they differ from other placeholders in that & is used instead of %).

96 Exchange Server 2003 Interoperability and Migration Guide

Table 3.3

Proxy address configuration symbols

To substitute

Use this symbol

The user's alias

&M or &m

The user's initials

&I or &i

An e-mail address based on the user's display name

&D or &d

The user's first name

&G or &g

The user's last name

&S or &s

An ampersand (&)

&&

For example, you can set the address format to Exchange.First Administrative Group.&d. A user whose display name is Birgit Seidl receives a Novell GroupWise address of: Exchange.First Administrative Group.Birgit Seidl. Caution After directory synchronization occurs, the connector creates secondary proxy addresses for Novell GroupWise recipients. These addresses, which do not display bold formatting on the user's E-Mail Addresses tab, are used as unique identifiers for Novell GroupWise recipients. Do not delete these secondary proxy addresses. In general, you should delete only addresses that you create manually.

5.

Configure Connector for Novell GroupWise Connector for Novell GroupWise is configured using Exchange System Manager. The location of the connector depends on whether you have enabled viewing for routing or administrative groups in Exchange System Manager. Figure 3.7 shows the location of the connector when viewing for both routing and administrative groups is enabled.

Figure 3.7 Manager

Location of Connector for Novell GroupWise in Exchange System

Among other things, you must specify the Universal Naming Convention (UNC) path to the root directory of the connector's API Gateway, identify the connector account (which must be a member of the

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 97

NTGATEWAY group, as mentioned earlier), and define message routing information for the connector. Alternatively, you can configure delivery restrictions to specify users and groups that are permitted or denied message transfer through Connector to Novell GroupWise. 6.

Test e-mail connectivity To ensure that the message routing works, send test messages from Novell GroupWise to Exchange 2003 and from Exchange 2003 to GroupWise. Use your GWISE proxy address to specify an Exchange recipient in Novell GroupWise, for example, Exchange.First Administrative Group.Administrator. To find your proxy address, start the Active Directory Users and Computers MMC snap-in and display the E-Mail Addresses tab for your user account. After the message is received in Microsoft Outlook, reply to it and verify that the reply is received in Novell GroupWise. Note Always test newly configured Exchange connectors in both directions.

Implementing Multiple Connector Instances You can configure multiple recipient policies to generate GWISE addresses according to different formats. For example, you might assign Birgit Seidl the address Exchange1.First Administrative Group.Birgit Seidl, while the Administrator might have the address Exchange2.First Administrative Group.Administrator. This corresponds to an Exchange organization with two external foreign domains in Novell GroupWise. You must create an external foreign domain in Novell GroupWise for Exchange1 and one for Exchange2 using Novell NetWare Administrator. To distribute the workload across multiple gateway instances, either point to the same API Gateway or to separate gateways (possibly in different GroupWise domains). In this way, multiple connector instances can share the message traffic to Exchange 2003 (Figure 3.8). To distribute outbound message traffic to GroupWise domains across multiple Connectors for Novell GroupWise, assign detailed GWISE address spaces to each connector.

Figure 3.8 Using multiple connector instances between Exchange 2003 and a Novell GroupWise organization Note When you are implementing multiple connector instances, carefully design the directory synchronization topology to avoid duplicating addresses.

98 Exchange Server 2003 Interoperability and Migration Guide

Specifying Routable Novell GroupWise Domains Just as an Exchange 2003 organization can have multiple administrative groups, a Novell GroupWise environment can have multiple domains. These domains can transfer messages indirectly to the Exchange 2003 organization through another domain in which the connector's API Gateway is installed (Figure 3.9). One Connector for Novell GroupWise can allow all users in all GroupWise domains to communicate with each Exchange user. Correct address space information must be assigned to the Connector for Novell GroupWise to allow for proper message routing. For example, assign an address space of GWISE:* to the connector to route messages to all GroupWise users through your connector instance. Additional configuration might be required in the Novell GroupWise environment. You must ensure that the link table configuration of the connector's GroupWise domain meets your GroupWise routing requirements. The GWMTA must be able to route inbound messages that are received from the API Gateway to their GroupWise destinations.

Figure 3.9 Using a single Connector for Novell GroupWise to reach multiple Novell GroupWise domains

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 99

Configuring Directory Synchronization After you configure Connector for Novell GroupWise, you can synchronize directories between Novell GroupWise and Exchange 2003 (Active Directory). When directories are synchronized, both Novell GroupWise and Exchange 2003 users can select each other in the Exchange address book or the Novell GroupWise directory, and send messages to each other as if they belong to the same messaging environment. Before configuring directory synchronization, ensure that message transfer using Connector for Novell GroupWise was tested successfully. Note The following section is a conceptual discussion of configuration steps. For detailed step-by-step instructions for configuring directory synchronization between Novell GroupWise and Exchange 2003, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

You must complete the following steps to configure directory synchronization with Novell GroupWise: 1.

Specify an import container for Novell GroupWise recipients The import container is the target organizational unit in Active Directory where Connector for Novell GroupWise places the recipient objects that are created during directory synchronization for Novell GroupWise users. It is a good idea to create a dedicated organizational unit for this purpose in Active Directory Users and Computers before configuring directory synchronization. There can only be one import container. Note If you change the import container at a later time, remember to move affected recipient objects to the new organizational unit to make sure that they are updated properly.

You also can specify the types of recipient objects to create in Active Directory if replicated mailboxes do not have accounts in the Windows domain (using the Create A Disabled Windows User Account, Create A New Windows User Account, and Create A Windows Contact options on the Import tab in the connector properties). Furthermore, you can select which Novell GroupWise recipients to include in directory synchronization. The default Import All Directory Entries option imports all addresses in the specified organizational unit. The remaining options allow you to restrict the address information, in which case you can define corresponding import filters. For example, you can specify GWDOMAIN.*.* in an import filter to prevent the import of GroupWise recipient objects that reside in a GroupWise domain called GWDOMAIN. Note You must grant the computer account of your Exchange 2003 server permission to create and modify recipients in the selected import container. This is necessary for directory synchronization from Novell GroupWise to Exchange 2003 to work. Exchange System Manager can configure the computer account with the required permissions automatically for you when you configure Connector for Novell GroupWise.

2.

Specify which Exchange recipients to export to Novell GroupWise An export container is an organizational unit in Active Directory that Connector for Novell GroupWise uses to export Exchange recipient objects to the Novell GroupWise directory. You can specify multiple export containers in the Connector for Novell GroupWise configuration. Nested organizational units are not selected for export if you select the parent organizational unit. You must select each organizational unit individually.

100 Exchange Server 2003 Interoperability and Migration Guide

In addition to selecting export containers, you can decide whether to export contact and groups to Novell GroupWise. Groups appear as user objects in the GroupWise target directories. Membership information is not synchronized. For this reason, you need to enable the distribution list expansion feature of the API Gateway, which is only supported if you installed the Novell GroupWise Patch 2 for API NetWare Loadable Module (NLM), as explained earlier. For a discussion of the advantages and disadvantages of synchronizing group objects, see Chapter 1, "Understanding Interoperability and Migration." Note You must grant the computer account of your Exchange 2003 server permission to access and read recipient information in the selected export containers. This is necessary for directory synchronization from Exchange 2003 to Novell GroupWise to work. Exchange System Manager can automatically configure the computer account with the required permissions when you configure Connector for Novell GroupWise.

3.

Configure a directory synchronization schedule Directory synchronization can require that large amounts of data be processed through Connector for Novell GroupWise, which can slow message traffic throughput during synchronization cycles. For this reason, schedule synchronization during off-peak traffic hours. If your directory information changes infrequently, synchronization once a day might be sufficient. Otherwise, schedule synchronization for two or more times a day. You can specify the directory synchronization schedule on the connector's Dirsync Schedule tab.

4.

Test directory synchronization You should start the first directory synchronization cycle manually to verify that Connector for Novell GroupWise is configured correctly and that the directories synchronize. On the connector's Dirsync Schedule tab: a.

Under Exchange to GroupWise directory synchronization, click Immediate full reload. A pop-up message indicates that directory synchronization has begun. This process synchronizes directory objects from Active Directory to the Novell GroupWise directory.

b.

Under GroupWise to Exchange directory synchronization, click Immediate full reload. Again, a pop-up message indicates that directory synchronization has begun. This process synchronizes directory objects from Novell GroupWise to Active Directory.

Allow a few minutes for synchronization to finish. Then check Active Directory to verify whether the Novell GroupWise users and objects have been added. Also, check the Novell GroupWise directory to ensure that users and objects have been added there for the external foreign domain that refers to the Exchange 2003 organization. If the directories are not updated, an error occurred. The following list provides some general troubleshooting tips. For more troubleshooting guidelines, see Chapter 5, "Troubleshooting Interoperability and Migration Issues." •

Verify connectivity between the Exchange server with Connector for Novell GroupWise and the bridgehead server running the API Gateway. To do this, you can stop the Connector for Novell GroupWise on the Exchange server and the API Gateway NetWare Loadable Module (NLM) on the Novell NetWare server, and then open the API Gateway directory in Windows Explorer. Verify that you can save and read text files in the API Gateway directory. Delete your test files before you restart the API Gateway and Connector for Novell GroupWise.

•

Verify the configuration of Novell GroupWise and the Exchange 2003 server. Verify that you configured everything correctly in the previous configuration steps. Specifically, check the names of the external foreign domain, the API Gateway, and the path to the API Gateway directory in Novell NetWare Administrator, and verify that the configuration parameters of Connector for Novell GroupWise correspond in Exchange System Manager. Most synchronization issues are the result of configuration problems.

•

Check Event Viewer on the Exchange 2003 server for any errors in the application log. These might help you to determine at what point the problem occurred. Also check the logs and console on the server running the Novell GroupWise API Gateway for any errors.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 101

If your synchronization is successful, you will find the recipient objects in the Novell GroupWise directory and Active Directory. Users on both servers can now interact as if they are members of the same messaging environment. The next step is to enable users on both servers to access each other's free/busy information.

Implementing Calendar Connectivity Calendar Connector enables Novell GroupWise and Exchange users to access each other's free/busy information when scheduling meetings. Before configuring Calendar Connector, ensure that both Exchange and Novell GroupWise users can send messages to each other and that directory synchronization works. Note The following section is a conceptual discussion of configuration steps. For detailed step-by-step instructions for configuring calendar connectivity between Novell GroupWise and Exchange 2003, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

The following steps are required to configure calendar connectivity: 1.

Ensure that prerequisites are met Before you install and configure Calendar Connector, you must ensure that you have the necessary permissions and are running the required software. You install Calendar Connector on an existing Exchange 2003 server and Connector for Novell GroupWise. Before proceeding, ensure that the server on which you install Calendar Connector meets the following prerequisites: •

The server is running Gateway and Client Services for NetWare or the Novell NetWare Client for Windows.

•

The server is running Exchange Server 2003.

•

The server is running Connector for Novell GroupWise. Note Ensure that you have a Novell GroupWise client access license for the server on which you install Calendar Connector.

In addition, the Novell GroupWise environment must meet the following requirements:

2.

•

The server is running Novell NetWare 3.x.

•

The server is running the NLM version of the Novell GroupWise 4.1 API Gateway Patch 2.

•

Novell NetWare Administrator is installed.

•

The server is running Novell GroupWise 4.x or 5.x.

Install Calendar Connector You must install Calendar Connector on an Exchange 2003 server that belongs to the same administrative group as the server running Connector for Novell GroupWise. It is recommended that you install and configure Calendar Connector on the server that is already running Connector for Novell GroupWise. Calendar Connector is included in Exchange Server 2003 and can be installed when you start the Exchange 2003 Setup program. You must have the following permissions to install and administer Calendar Connector: •

Exchange Administrator These permissions are required to install Calendar Connector on the Exchange server.

102 Exchange Server 2003 Interoperability and Migration Guide

• 3.

Local Administrator You must be a member of the Administrators group on the computer on which you install Calendar Connector.

Add a local replica for the SCHEDULE+ FREE BUSY public folder Schedule information for users in an Exchange 2003 messaging environment is stored in a special public folder called SCHEDULE+ FREE BUSY (Figure 3.10). This folder is configured for each administrative group in the Exchange organization. Calendar Connector uses the SCHEDULE+ FREE BUSY public folder to read and write the schedule information for Novell GroupWise users so that Exchange 2003 users can access that information.

Figure 3.10

The SCHEDULE+ FREE BUSY public folder

Calendar Connector always looks for this folder on the local Exchange 2003 server on which it is installed. Therefore, you must ensure that the Exchange 2003 server holds a local replica of the SCHEDULE+ FREE BUSY public folder. To add a local replica of the SCHEDULE+ FREE BUSY public folder to the local Exchange server, use Exchange System Manager. If there are multiple administrative groups in an Exchange 2003 organization, each administrative group has its own SCHEDULE+ FREE BUSY public folder. In this case, free/busy information for Exchange users might be stored in a different public folder than free/busy information for Novell GroupWise users whose information is replicated to Exchange 2003. You must ensure that the administrative group's SCHEDULE+ FREE BUSY public folder is configured to replicate to the server running Calendar Connector. In an Exchange 2003 organization with multiple administrative groups, remember the following facts: •

When storing free/busy information for Novell GroupWise users, Calendar Connector always uses the administrative group in which Connector for Novell GroupWise is installed. The user's free/busy information is stored in the public folder associated with this administrative group because the Connector for Novell GroupWise is used to import these users into Active Directory.

•

If the SCHEDULE+ FREE BUSY public folder that is used by Calendar Connector is replicated to a public folder store in a different administrative group, then you must install another instance of Calendar Connector in that administrative group. If you do not install another instance, Calendar Connector does not intercept queries made to that replica.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 103

•

If you already have an instance of Calendar Connector installed on one administrative group that imports users from Novell GroupWise to Active Directory, and you want to install another Calendar Connector on a different administrative group, you must refer the newly installed Calendar Connector to the original instance of Calendar Connector.

104 Exchange Server 2003 Interoperability and Migration Guide

4.

Prepare the Novell GroupWise environment Before configuring Calendar Connector, ensure that Connector for Novell GroupWise is working properly, and perform full directory synchronization. You must configure directory synchronization to update the directories on a regular basis. Novell GroupWise users who try to query nonexistent Exchange mailboxes will receive erroneous calendar information. You should use Novell NetWare Administrator to verify the following information, which is required to configure Calendar Connector:

5.

•

The name of the Novell GroupWise domain in which the API Gateway is installed

•

The name of the API Gateway in Novell GroupWise

Configure Calendar Connector Like Connector for Novell GroupWise, Calendar Connector is configured using Exchange System Manager and the location of the connector is the same as for Connector for Novell GroupWise. You must specify the Connector for Novell GroupWise that is used to connect to Novell GroupWise, as well as the name of Novell GroupWise API Gateway. To specify the Connector for Novell GroupWise, on the General tab, click Modify next to the Connector used to import users into Active Directory text box, and then make your choice on the Select Exchange Notes or Groupwise Connector tab. To specify the API Gateway, on the Calendar Connections tab, click New, and choose Novell GroupWise. Enter the name of the API Gateway in the form Domain.Gateway, where Domain refers to the Novell GroupWise domain in which the API Gateway is installed, and Gateway refers to the name of the API Gateway in GroupWise. On the General tab, you can also adjust the number of days that users are able to see free/busy information for users on the other messaging system (Number of days of free/busy information to request from foreign calendars). Free/busy information beyond the number of days specified is not retrieved by Calendar Connector and appears as free, even if meetings are scheduled during this time. However, the more data that is requested, the longer it will take for the free/busy information to be retrieved. Important The maximum number of days that Novell GroupWise supports for free/busy information is 389. If more than 389 days are requested, then no data is returned.

Another important configuration setting refers to the number of minutes that the Calendar Connector can cache free/busy information (Maximum age in minutes of foreign free/busy data in Exchange that can be used without querying the foreign calendar). If the free/busy information that is requested is older than the specified number of minutes, Calendar Connector requests updated data. If the free/busy information is within the specified number of minutes, Calendar Connector uses the current free/busy information. A value of 0 means that every free/busy query from an Exchange user will result in a query to Novell GroupWise. When requesting free/busy updates, the Maximum number of seconds to wait for response from foreign calendars setting determines the time span that Calendar Connector waits for a response for an individual user's free/busy information. Set this to a low number, because each recipient on a meeting request is handled in turn. A long response interval can cause the mail client to stop responding as it proceeds down the list of recipients. 6.

Start the Calendar Connector service In the Services MMC snap-in, right-click Microsoft Exchange Calendar Connector, and then click Start. The default startup type for Calendar Connector is Manual. It is recommended that you change this setting to Automatic, so that the Calendar Connector service starts automatically the next time you restart the server.

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 105

Migrating from Novell GroupWise to Exchange Server 2003 This section explains how to migrate a group of users from Novell GroupWise to Exchange 2003. The guidelines are recommended for most migrations and consist of extracting data from a Novell GroupWise post office and immediately importing it into Exchange 2003. However, in some cases you might want to edit the extracted data before importing the data into Exchange 2003, as explained in Chapter 1, "Understanding Interoperability and Migration." It is recommended that you configure a dedicated migration server rather than performing the migration through the connector server. Note The following section is a conceptual discussion of configuration steps. For detailed step-by-step instructions for migrating Novell GroupWise users to Exchange 2003 using the Exchange Migration Wizard, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

Performing a Novell GroupWise to Exchange 2003 migration consists of the following steps: 1.

Set up a migration server for Novell GroupWise and Exchange 2003 The computer that you use to run the Exchange Migration Wizard is generally referred to as a migration server. The migration server must be able to communicate with Novell GroupWise and Exchange 2003. To install the Exchange Migration Wizard on the migration server, run the Exchange 2003 Setup program and select the option to install Exchange System Manager. For best results with the Exchange Migration Wizard, use the following software versions on the migration server: •

GroupWise 5.2.5 This recommendation pertains only to the migration server. GroupWise users can use the latest GroupWise client.

•

Novell NetWare 4.8 This recommendation pertains only to the migration server. Users can use the latest NDS client. Note It is recommended that you install multiple migration servers to distribute the workload. For example, you can use five migration servers to migrate 100 users and balance the load so that each migration server handles 20 users. Powerful hardware is not required for your migration servers. You can use a workstation-type computer (a single-processor computer with 128 megabytes (MB) of RAM or more).

2.

Prepare the users' Novell GroupWise mailboxes To migrate data from Novell GroupWise to Exchange 2003, the Exchange Migration Wizard requires access to the mailbox for each user who is migrated. By default, only the owner of the mailbox has access. Novell GroupWise users must grant proxy access to the GroupWise account that you are using to perform the migration. For detailed step-bystep directions for granting proxy access, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality." It is also a good idea to run the Novell GroupWise Check (GWCheck) tool on the GroupWise accounts that you want to migrate to ensure that database inconsistencies are eliminated. The GWCheck tool is available from Novell. If you discover GroupWise database problems, you might have to run the GWCheck tool several times to repair a user's messaging database. If the GWCheck tool is unable to clear existing corruption, you might be able to solve the problem by creating a new Novell GroupWise post office in another location and moving the mailboxes that have

106 Exchange Server 2003 Interoperability and Migration Guide

problems into the new post office. This typically clears any corruption that is not resolved by the GWCheck tool. You can then migrate the users from the new post office to Exchange 2003 or move the users back to the old post office before migration. In addition to running the GWCheck tool, you might want to perform the following Novell GroupWise tasks:

3.

•

Delete users that no longer exist from Novell GroupWise.

•

Run the Novell VREPAIR tool, available from Novell, to repair any problems on traditional Novell NetWare volumes.

•

Run the Novell Timesync tool, available from Novell, at the server console to ensure that the time on all servers across the network is consistent.

•

Clean all mail queues of old mail.

Migrate data from Novell GroupWise to Exchange 2003 The next step in performing migration from Novell GroupWise to Exchange 2003 is to migrate the users and mailboxes from Novell GroupWise to the Exchange 2003 server. You do this by running the Exchange Migration Wizard on an Exchange 2003 server with Novell NetWare client and Novell GroupWise client installed (for example, the server that you configured to run Connector for Novell GroupWise). The Exchange Migration Wizard uses the Novell GroupWise client API to access GroupWise mailboxes. Important Stop the Connector for Novell GroupWise service during migration to prevent directory synchronization from propagating migrated Novell GroupWise accounts as Exchange 2003 mailboxes before you verify that your migration is successful. If a migration attempt ends unsuccessfully, delete any mailboxes and recipient objects created during the migration attempt from Active Directory. Restart Connector for Novell GroupWise and perform a manual directory synchronization to bring both messaging systems back in sync. For more information about troubleshooting migration problems, see Chapter 5, "Troubleshooting Interoperability and Migration Issues."

It is often sufficient to accept the defaults in the Exchange Migration Wizard. If you have specific needs, you can change the following options on the Migration Information wizard page: •

Information to create mailboxes When selected, a new mailbox is created for users migrated from Novell GroupWise to Exchange.

•

Personal e-mail messages When selected, the user's e-mail stored on Novell GroupWise is migrated to Exchange. You can select either All to migrate all of the user's mail or Dated from to specify a date range of messages to migrate.

•

Calendar Items When selected, the user's appointments, notes, and tasks are migrated to Exchange. You can select either All to migrate all the user's information or Dated from to specify a date range of schedule information to migrate. Note Any meeting requests in users' Inboxes that have not been accepted are migrated as text messages. Users must manually add these meetings to their calendars. Before you complete the migration, ensure that users accept any outstanding meeting requests.

The Exchange Migration Wizard creates a mailbox-enabled Active Directory account for each user being migrated. All new user accounts are placed in the target organizational unit that you select on the Container for New Windows Accounts page. If accounts already exist in Active Directory, for example because you created disabled Windows accounts for all Novell GroupWise users through directory synchronization beforehand, you must verify that the accounts are matched correctly. You can associate the correct account using the Find Existing Account option on the Windows Account Creation and

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 107

Association page. You can also choose to create a new account using the Create New Account option. For new accounts, the Exchange Migration Wizard can generate a random strong password, which is stored in the Accounts.Password file in the \Program Files\Exchsrvr\Bin directory on the Exchange 2003 server. After migration is complete, review the Application Log for information about the migration progress. Look for event log messages with the source MSExchangeMig. It might be helpful to configure and apply a filter in Event Viewer to list only those event log messages from the Exchange Migration Wizard. 4.

Migrate calendar information The Exchange Migration Wizard migrates calendar information by generating a SCHEDULE+ FREE BUSY public folder import file for each user. This file contains the user's schedule information. Users receive this file as an attachment to a new message in their Inboxes. Your users must manually import their schedule data.

Message Conversion Issues When the Exchange Migration Wizard migrates data, it converts Novell GroupWise messages and other items to Exchange 2003 formats. Table 3.4 shows how certain Novell GroupWise items are converted during migration to Exchange 2003. Table 3.4 Novell GroupWise item conversion Novell GroupWise item

Converted to Exchange 2003

Task request

Converts as a text-based read note

Phone message

Converts as a text-based read note

Routing slip

Converts as a text-based read note

Calendar data

Converts as Outlook Calendar information

Table 3.5 shows how Novell GroupWise message formatting is converted during the migration process. Table 3.5 Novell GroupWise message formatting conversion Novell GroupWise formatting

Converted to Microsoft Outlook

Size

Converts correctly.

Color

Converts correctly.

Bold

Converts correctly.

Underline

Converts correctly.

Italic

Converts correctly.

Strikethrough

Converts correctly.

Tables

Convert correctly if Word is used as the primary email editor in Outlook (formatting is lost). Do not convert correctly if Outlook is the e-mail editor.

Embedded OLE objects, including graphics

Convert correctly, can be edited.

Double strikethrough

Does not convert.

Superscript

Does not convert.

108 Exchange Server 2003 Interoperability and Migration Guide

Novell GroupWise formatting

Converted to Microsoft Outlook

Subscript

Does not convert.

Shadow

Does not convert.

Outline

Converts to italic.

Emboss

Does not convert.

Engrave

Does not convert.

Small caps

Does not convert.

All caps

Does not convert.

Drop caps

Does not convert.

Hidden

Does not convert. Text is visible.

Underline other than single

Does not convert.

Bitmaps not embedded as OLE objects

Do not convert. Formatting is lost.

Bullets

Do not convert.

Table 3.6 shows how Novell GroupWise folders convert to Exchange 2003 folders. Table 3.6 Novell GroupWise folder conversion Novell GroupWise folder

Exchange 2003 folder

Inbox

Inbox

Inbox/user name

Inbox

Inbox/user name/subfolder

Inbox/subfolder

Outbox

Sent items

Outbox/user name

Sent items

Outbox/user name/subfolder

Sent items/subfolder

Personal folders

Personal folders

Personal folders/subfolder

Personal folders/subfolder

Week view

Outlook calendar

Migrating Local Archives The Exchange Migration Wizard migrates data stored on the Novell GroupWise server, but not data in local archives on Novell GroupWise clients. Novell GroupWise clients include automatic archive functionality to store messaging data locally. To migrate local archives, users must convert their local archives back to standard e-mail data and transfer it back into the GroupWise mailboxes. Novell GroupWise users can store large amounts of e-mail data in their local archives, which means putting these items back into their GroupWise mailboxes will greatly increase the amount of data that must be migrated. You must ensure that your GroupWise system and the Exchange 2003 server have sufficient disk space to store the data. If you are concerned that migrating local archives impedes your migration process,

Chapter 3: Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures 109

you might want to consider migrating local archives for executives and employees with specific permission only. Note After migration is complete, your users can create local personal folder (.pst) files to store the email data that they previously stored in GroupWise local archives on the client computer.

Migrating Personal Address Books The Exchange Migration Wizard is unable to migrate personal address books from Novell GroupWise to Exchange 2003. However, it is possible to export personal address books from GroupWise into .nab files, which are text-based files that can be converted into comma-separated value (.csv) files using a macro in Microsoft Excel, for example. The primary task is to reorder the fields to match the layout required by Outlook. Outlook provides the functionality to import Contact objects from a .csv file. To determine the order of fields in a .csv file for Outlook, create a sample contact object in Outlook and then export this contact into a .csv file using the Import and Export command on the File menu in Outlook 2003. Chose Export to a file and then select Comma Separated Values (Windows). Select the Contacts folder where you created the sample contact, and complete the export procedure. Open the resulting .csv file in Excel. You should find the list of fields in the first row. The following is a list of all header fields that Outlook recognizes: "Title","First Name","Middle Name","Last Name","Suffix","Company","Department","Job Title","Business Street","Business Street 2","Business Street 3","Business City","Business State","Business Postal Code","Business Country","Home Street","Home Street 2","Home Street 3","Home City","Home State","Home Postal Code","Home Country","Other Street","Other Street 2","Other Street 3","Other City","Other State","Other Postal Code","Other Country","Assistant's Phone","Business Fax","Business Phone","Business Phone 2","Callback","Car Phone","Company Main Phone","Home Fax","Home Phone","Home Phone 2","ISDN","Mobile Phone","Other Fax","Other Phone","Pager","Primary Phone","Radio Phone","TTY/TDD Phone","Telex","Account","Anniversary","Assistant's Name","Billing Information","Birthday","Business Address PO Box","Categories","Children","Directory Server","E-mail Address","E-mail Type","E-mail Display Name","E-mail 2 Address","E-mail 2 Type","E-mail 2 Display Name","E-mail 3 Address","E-mail 3 Type","E-mail 3 Display Name","Gender","Government ID Number","Hobby","Home Address PO Box","Initials","Internet Free Busy","Keywords","Language","Location","Manager's Name","Mileage","Notes","Office Location","Organizational ID Number","Other Address PO Box","Priority","Private","Profession","Referred By","Sensitivity","Spouse","User 1","User 2","User 3","User 4","Web Page"

Note Users can re-create personal contacts as well as personal distribution lists in a Contacts folder in Outlook.

Migrating Personal Dictionaries Personal dictionaries cannot be migrated from Novell GroupWise to Exchange 2003 and Outlook. The Novell GroupWise spelling checker dictionary is stored in separate, identifiable files. However, these files are encrypted and encoded and cannot be migrated to Outlook. Users must add their words to the spelling checker dictionaries in Outlook and Microsoft Office manually.

110 Exchange Server 2003 Interoperability and Migration Guide

Migrating Client Rules and Proxy Access The Exchange Migration Wizard cannot migrate client rules from Novell GroupWise clients to Outlook 2000. Users must re-create their rules in Outlook. Users can access the Rules and Alerts command from the Tools menu in Outlook 2003 to re-create their rules. Users must also migrate proxy access permissions to the mailboxes manually. In Outlook, proxy access is referred to as delegate access. In Outlook 2003, from the Tools menu, click Options, and then in the Options dialog box, switch to the Delegates tab, where you can click the Add button to configure delegate access. Because Outlook and Exchange 2003 handle delegate access differently than Novell GroupWise does, it is recommended that you train your users to set up delegates and send messages on behalf of another user in Outlook before you perform the migration. Note Exchange users can grant delegate access only to accounts in the Exchange 2003 organization. Exchange users cannot grant delegate access to Novell GroupWise users.

Migrating Shared Folders Novell GroupWise users can share their mailbox folders with other users, and the Exchange Migration Wizard can migrate the shared folders to Exchange 2003, but shared folder permissions cannot be migrated. To share folders after the migration, users must re-create these permissions on the appropriate folders in Outlook. To grant another user access to a folder in Outlook 2003, right-click the folder, select Properties, and then switch to the Permissions tab. Note Exchange users can share their folders only with other Exchange users. They cannot give access to their folders to Novell GroupWise users.

Migrating External Entities The Novell GroupWise directory is separate from NDS, and Novell GroupWise allows objects to exist in the GroupWise directory without having an NDS linked object. This kind of object is called an external entity. In Exchange, external entities are handled as normal mailbox-enabled accounts and are migrated using the Exchange Migration Wizard.

C H A P T E R

4

Interoperating with and Migrating from Other Non-Exchange Messaging Systems

This chapter describes how to deploy Microsoft® Exchange Server 2003 and migrate from a variety of messaging systems, including Microsoft Mail for PC Networks , Lotus cc:Mail, Digital All-in-1, Verimation MEMO, IBM OfficeVision/VM, HP OpenMail, and others, where a direct gateway connector is not available in Exchange Server 2003. At the end of this chapter, you should have a basic understanding of how to deploy a general messaging connector, how to implement directory synchronization in the absence of a direct messaging connector, how to provide non-Exchange users with access to Exchange 2003 free/busy information without using Microsoft Exchange 2003 Calendar Connector, and how to migrate user data from non-Exchange messaging systems using stand-alone source extractors and the Exchange Migration Wizard. Before you deploy Exchange 2003 in an environment with a non-Exchange messaging system, you must have a thorough understanding of the existing messaging infrastructure. Furthermore, if you are migrating away from a host-based messaging system, such as Verimation MEMO, IBM OfficeVision/VM, or Fischer Totally Automated Office (TAO), you must also know how to connect the host-based environment with a PC-based environment, and how to run programs such as source extractors in a virtual machine (VM) on the host system. You also must be familiar with Exchange 2003 and Microsoft Windows Server™ 2003 deployment and administration concepts to design the Exchange 2003 organization according to the specific requirements of your company. For more information, see Appendix F, "Resources." This chapter is divided into several main sections, which correspond to the order of steps in a multiphase migration from a non-Exchange messaging system to Exchange 2003, as follows: 1.

Familiarizing yourself with general interoperability options, including the messaging connectors that are available and their advantages and disadvantages, as well as tools and programming interfaces that you can use to implement custom solutions for directory synchronization and for access to free/busy information.

2.

Implementing messaging connectivity, including the steps to configure an SMTP or X.400 connector for message transfer.

3.

Configuring directory synchronization between a non-Exchange messaging system and Active Directory, including the steps to extract directory information from the non-Exchange messaging system and import the directory information into Active Directory.

4.

Providing Exchange 2003 free/busy information to non-Exchange users, including the steps for configuring Microsoft Office Outlook® 2003 to publish free/busy information over the Internet or an intranet.

5.

Migrating from non-Exchange messaging systems to Exchange 2003, including recommendations for how to prepare the existing environment, how to run the Exchange Migration Wizard, and how to migrate local data.

112 Exchange Server 2003 Interoperability and Migration Guide

If you plan to migrate to Exchange 2003 in a single step, you can go directly to the section "Migrating from a Non-Exchange Messaging System to Exchange Server 2003," later in this chapter. Note This chapter discusses the X.400 connector and SMTP connector, as well as certain Outlook features, Active Directory tools, and Exchange Migration Wizard configuration tasks at a conceptual level. For detailed step-by-step instructions that outline how to configure X.400 or SMTP connectors for messaging interoperability and how to migrate users from a messaging system that supports Lightweight Directory Access Protocol (LDAP) and Internet Message Access Protocol version 4 (IMAP4), see Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System."

Understanding Interoperability Between Exchange 2003 and Non-Exchange Messaging Systems Microsoft provides several components for integrating Exchange 2003 into a non-Exchange messaging infrastructure and for migrating users to Exchange 2003: •

SMTP connector and X.400 connector For seamless interoperability, you must deploy a reliable bidirectional message transfer path. All modern messaging systems support SMTP, so you can use an SMTP connector to connect the systems. Or if the legacy messaging system relies on X.400, you can use an X.400 connector. This messaging connectivity might be temporary (for example, the systems might need to coexist only while you migrate users from the legacy system to Exchange Server 2003). In other cases, long-term coexistence might be required (for example, the messaging system of a department that is not moving to Exchange Server 2003 might require a permanent connection).

•

Active Directory tools and application programming interfaces You must synchronize the Active Directory® directory service and the directory of the legacy messaging system to establish a consistent global address list across both messaging systems. However, neither an SMTP connector nor an X.400 connector supports automatic directory synchronization. As mentioned in Chapter 1, "Understanding Interoperability and Migration," you can use Active Directory tools such as Ldifde.exe and Csvde.exe to perform manual directory synchronization or bulk export and import operations. With basic Microsoft Visual Basic® Scripting Edition (VBScript) programming skills, it is also possible to implement a more sophisticated, semi-automatic directory synchronization solution based on Active Directory Service Interfaces (ADSI) and Collaboration Data Objects for Exchange Management (CDOEXM). For more information about ADSI and CDOEXM, see the Exchange Software Development Kit (SDK) (http://go.microsoft.com/fwlink/?LinkId=25925).

•

Exchange Server programming interfaces for accessing free/busy information Cross-platform access to free/busy information is useful for scheduling meetings and conferences across different messaging systems. However, a calendar connector is not available for non-Exchange messaging systems other than Lotus Notes or Novell GroupWise when connected to the Exchange 2003 organization through Connector for Lotus Notes or Connector for Novell GroupWise. Although it is not possible to synchronize free/busy information between systems that are connected with each other through an SMTP connector or an X.400 connector, you can use Outlook to publish free/busy information in a shared location, or use Collaboration Data Objects for Exchange (CDOEX) to implement a custom solution that displays the

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 113

free/busy status of Exchange 2003 users in an ASP.NET page. For more information about CDOEX, see the Exchange SDK (http://go.microsoft.com/fwlink/?LinkId=25925).

114 Exchange Server 2003 Interoperability and Migration Guide

•

Exchange Migration Wizard The Exchange Migration Wizard is a tool that you can use to migrate users from a supported messaging system, such as Microsoft Mail for PC Networks, Microsoft Mail for AppleTalk Networks, or Lotus cc:Mail, to Exchange 2003. The Exchange Migration Wizard also supports LDAP and IMAP4, which is very useful if you must migrate from HP OpenMail, Sun ONE (formerly known as Netscape iPlanet), Openwave Email Mx, Alt-n MDaemon, or any other e-mail system that supports LDAP and IMAP4. The Exchange Migration Wizard supports migration by copying existing directory information, mailboxes, and messages and importing that information into Exchange Server 2003, as explained in Chapter 1, "Understanding Interoperability and Migration."

•

Stand-alone source extractors The Exchange Migration Wizard does not support legacy messaging systems directly, such as Dec All-in-One, Verimation MEMO, or IBM Professional Office System (PROFS) and OfficeVision/VM. However, stand-alone source extractors, available from both Microsoft and non-Microsoft vendors, can be used to extract existing data from mailboxes in the legacy messaging system into migration files that the Exchange Migration Wizard can import into Exchange Server 2003. To obtain a stand-alone source extractor for your legacy messaging system, contact Microsoft Product Support Services. For information about Product Support Services, including how to contact them, go to http://support.microsoft.com.

Message Transfer and Conversion Exchange Server 2003 supports two general messaging standards to connect to any type of messaging system: SMTP and X.400. SMTP is the native message transfer protocol of Exchange 2003, and therefore it is recommended that you choose SMTP over X.400. Also, an SMTP connector is more straightforward to configure than an X.400 connector. However, X.400 is a good choice if you are working in an environment that relies on an X.400 backbone or will not support SMTP unless you deploy additional components in the legacy infrastructure.

SMTP-based Message Transfer Exchange Server 2003 relies on the Windows 2003 SMTP service, extended with Exchange-specific transport components and modules, for communication with remote SMTP hosts. The SMTP service is represented in Exchange 2003 by virtual servers. For message transfer to work, SMTP virtual servers must be able to resolve SMTP domain names into IP addresses. This is typically accomplished through Domain Name System (DNS) queries. The SMTP hosts must be registered in mail exchanger (MX) records. It is also possible to forward all outbound SMTP messages to a single SMTP host for further delivery. This SMTP host is called a smart host. Internet service providers (ISPs) often provide their customers with a central smart host that handles message transfer across the Internet. SMTP message transfer to internal SMTP hosts is best accomplished through dedicated SMTP connectors, because SMTP connectors provide greater control over the configuration than SMTP virtual servers do. Connector settings have higher priority for message transfer than the settings for virtual servers. For example, you can use an SMTP connector to implement a central messaging bridgehead server that is responsible for all message transfer between the legacy messaging system and the Exchange 2003 organization. Figure 4.1 illustrates such an environment with a single bridgehead server. For fault tolerance and load balancing, you can define multiple bridgehead servers in the SMTP connector configuration.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 115

Figure 4.1 Connecting an Exchange 2003 organization to a non-Exchange messaging system through an SMTP connector When you configure an SMTP connector, you can specify whether to use DNS and MX records for message transfer or to forward all messages to a smart host. Using a smart host is usually the better option when transferring messages to another SMTP host in the internal network, because internal destinations are often not registered as MX records in DNS. To forward messages for a particular SMTP domain across an SMTP connector, you must identify the connector as responsible for the domain. You do this by defining an address space of type SMTP in the connector configuration that corresponds to the SMTP domain name of the target system. In Figure 4.1, this address space is: SMTP: legacy.contoso.com. Because the target system is identified by means of an SMTP domain name, the legacy messaging system and the Exchange 2003 organization cannot share the same SMTP domain name. For more information about how to deal with SMTP domain names in migration scenarios, see Chapter 1, "Understanding Interoperability and Migration." Note If a recipient address does not match any connector address spaces, the local SMTP virtual server settings are used for message delivery. By default, Exchange 2003 attempts to locate the remote SMTP host using DNS until you change the delivery options of the SMTP virtual server.

Exchange to SMTP Message Transfer Figure 4.2 shows the process for sending messages from Exchange 2003 to a non-Exchange messaging system through an SMTP connector.

116 Exchange Server 2003 Interoperability and Migration Guide

Figure 4.2 Sending messages from Exchange 2003 to a remote SMTP host The transfer of messages from Exchange 2003 to a non-Exchange messaging system through SMTP proceeds as follows: 1.

All messages sent to local or remote users must pass through the Exchange 2003 transport engine. The pre-submission queue is the entry point into the advanced queuing engine.

2.

The advanced queuing engine transfers the message from the pre-submission queue into the precategorization queue so that the categorizer can process it. The categorizer checks restrictions, applies per-sender and per-recipient limits, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to return it to the advanced queuing engine. Note The categorizer expands distribution lists, resolves recipient and sender names, determines home servers, determines what format messages must be converted to, and bifurcates messages. Bifurcation is the process of creating multiple copies of a message, which is required, for example, when recipients require different message formats.

3.

The advanced queuing engine transfers messages for non-local recipients from the post-categorization queue into the pre-routing queue and calls the routing engine. The routing engine maintains next-hop information in the link state table. Based on the user's target address, the routing engine determines that the recipient is a user on a non-Exchange messaging system and moves the message to the link queue for the SMTP connector. The queue manager component manages the link queues. The name of the queue matches the remote delivery destination.

4.

The SMTP protocol service picks up the message, determines the destination host from the SMTP connector configuration or through a DNS query based on the recipient's SMTP domain, establishes a TCP/IP connection to the destination host on TCP port 25, and transfers the message.

5.

The destination host delivers the message to its final destination.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 117

SMTP to Exchange Message Transfer An SMTP connector is used only for outbound message transfer from Exchange 2003. SMTP connectors are configuration objects that contain parameters that determine how the SMTP service establishes connections and transfers messages. Non-Exchange messaging systems, however, do not recognize these objects and parameters. Remote SMTP hosts simply establish a TCP/IP connection to the SMTP service on the Exchange 2003 server through TCP port 25 and transfer their messages. Figure 4.3 shows the process for receiving messages from a remote SMTP host.

Figure 4.3 Receiving messages from a remote SMTP host The transfer of messages from a remote SMTP host to Exchange 2003 can be divided into four steps: 1.

The remote SMTP host establishes a TCP/IP connection to the Exchange 2003 server on TCP port 25, and transfers the message. The local SMTP protocol service places the message in the pre-submission queue of the advanced queuing engine.

2.

The advanced queuing engine transfers the message from the pre-submission queue into the precategorization queue so that the categorizer can process it. The categorizer checks restrictions, applies limits for each sender and recipient, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to return it to the advanced queuing engine.

3.

The advanced queuing engine transfers messages for local recipients from the post-categorization queue into the local delivery queue.

4.

The Exchange store driver picks up the message and places it in the Inbox of the local recipient.

118 Exchange Server 2003 Interoperability and Migration Guide

Exchange/SMTP Message Conversion SMTP, as its name Simple Mail Transfer Protocol implies, does not define complex message types, such as delivery receipt requests, read receipt requests, meeting requests, or task requests. In fact, SMTP handles only one message type: a simple text message. An SMTP message consists of a sequence of seven-bit ASCII characters. The message header, which contains, among other things, sender and recipient information, subject, and date, is separated from the body by a null line, that is, a line with nothing preceding the carriage return/line feed character. As shown in Figure 4.4, the SMTP message format, defined in RFC 822, is indeed simple.

Figure 4.4 A basic SMTP message The basic SMTP message format can be used only for text-based e-mail messages. To support attachments, the original files must be encoded using UUENCODE or Multipurpose Internet Mail Extensions (MIME). Your decision about whether to use UUENCODE or MIME to encode message attachments will depend on the features that are supported by the receiving messaging client. UUENCODE is an encoding mechanism that converts binary data into printable ASCII characters so that the data can be included in the message body without violating SMTP conventions. The message shown in Figure 4.4 contains the seven-bit character stream of an attached uuencoded file. MIME provides another way for non-text information to be encoded as text. MIME, defined in RFC 1341 and successors, is a very flexible format. It describes a way to include multiple parts of various content types into an e-mail message, both textual and non-textual. Parts of a message can be text, images, audio, video, or other application-specific data. Note MIME uses the Base64 encoding/decoding algorithm, which is flexible and reliable but inflates the encoded data on an average by approximately 33 percent. This means that an SMTP connector must transfer 33 percent more data per message.

When you connect an Exchange 2003 organization to a non-Exchange messaging system through an SMTP connector, all of the message content must be encapsulated using UUENCODE or MIME to avoid losing formatting in Rich Text Format (RTF) and extended characters. The encapsulated message can be inserted into the message in the form of printable characters. By default, messages are encapsulated using MIME. However, you can specify the message format for each SMTP domain in the Exchange System Manager tool. Under Global Settings, display the properties for the Internet Message Format object, and switch to the Message Format tab. Among other things, you can choose to provide the message body as HTML, which is a good choice if the recipient's e-mail client supports

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 119

HTML-formatted messages. Formatting messages in HTML preserves most rich-text features that would be lost if you sent the message body as plain text. Note Some messaging administrators block HTML-formatted messages because HTML mail can include scripts that contain malicious code, such as worm viruses. Ask the remote administrator whether you can transfer messages in HTML format. The alternative to HTML is plain text or message encapsulation using Transport Neutral Encapsulation Format (TNEF), both of which are explained later in this section.

Table 4.1 shows which Exchange rich-text features convert correctly to HTML and which do not. Table 4.1 E-mail message conversion between RTF and HTML Rich Text Format (Exchange)

HTML (MIME/SMTP)

Size

Converts correctly

Color

Converts correctly

Bold

Converts correctly

Underline

Converts correctly

Italic

Converts correctly

Strikethrough

Converts correctly

Tables

Do not convert correctly

Embedded OLE objects, including graphics

Ignored

Double strikethrough

Converts to single strikethrough

Superscript

Converts correctly

Subscript

Converts correctly

Shadow

Ignored

Outline

Ignored

Emboss

Ignored

Engrave

Ignored

Small caps

Ignored

All caps

Ignored

Bullets

Convert, but line spacing is ignored

Numbered list

Converts correctly

To avoid losing formatting information when converting from RTF to HTML, Outlook users can configure their clients to compose messages in HTML format by default. Also, if users choose to use Microsoft Word as their e-mail editor, they can use the full HTML editing set available with Word when composing e-mail messages. For example, they compose a message in HTML format and insert a table into the message. The table is preserved during message transmission, because it is a native HTML structure. In contrast, a table that is inserted into a rich-text message will be lost during conversion from RTF to HTML. The issue is not whether an HTML-formatted message can have a table (or other specific rich-text feature), but whether the conversion from RTF to HTML supports this rich-text element.

120 Exchange Server 2003 Interoperability and Migration Guide

Another option is to send RTF information to the remote recipient encapsulated in TNEF format. This is a good choice if you know that the recipient works with a client that supports MAPI, such as Outlook with the IMAP4 transport driver. By sending messages in RTF, you can ensure maximum interoperability between Outlook users in different messaging systems, because all message properties are preserved. For example, calendar information requires rich-text formatting. Users can send special message types, such as meeting requests or task requests, to each other in RTF. Users can decide individually whether to send messages in RTF, but you can also enable this feature in Exchange System Manager for each SMTP domain. In the properties for the Internet Message Format object, switch to the Advanced tab, and under Exchange richtext format select the option Always use. Note When you send a TNEF-encapsulated message, all MAPI attributes are preserved, but the recipient must work with a MAPI-compliant messaging client. Clients that do not understand MAPI will display a plain-text or HTML-formatted message with an additional attachment named winmail.dat that the recipient is unable to use. This might confuse the recipient. Therefore, you should not send rich-text information to SMTP domains unless you are sure that the recipients work with a MAPI-conforming client.

X.400-based Message Transfer Before SMTP established itself as one of the leading standards for message transfer, commercial e-mail service providers and large corporations deployed X.400 backbones to connect different messaging systems. Today, SMTP is more popular than X.400 because it is simple and is established on the Internet. However, X.400 continues to be a common messaging standard in law firms and legal departments, financial institutions, insurance companies, and other organizations for which message transfer must be secure and traceable. In an SMTP-based backbone, it is difficult to find misrouted messages or determine the origin of an e-mail message with offensive text. In an X.400 backbone, however, every connection requires authentication. All message transfer agents (MTAs) must identify themselves as authorized MTAs before they can transfer messages. Now that the Internet is flooded with spam and e-mail-borne viruses, X.400 is regaining its popularity. Exchange Server 2003 supports X.400 through the Microsoft Exchange Message Transfer Agent (MTA) Stacks service. The Exchange MTA supports X.400 according to the 1988 conformance year and can communicate with remote X.400 1984 and 1988 systems through TCP/IP or X.25. X.400 systems of later conformance years (such as 1992) must reduce their feature sets to the standard of 1988 when communicating with Exchange 2003. The X.400 standard demands that X.400 systems scale back to the capabilities of their communication partners. Note The X.400 connector is available only in the Enterprise edition of Exchange Server 2003.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 121

Exchange to X.400 Message Transfer Figure 4.5 shows the process of sending messages from Exchange 2003 to a remote X.400 system.

Figure 4.5 Sending messages from Exchange 2003 to a remote X.400 MTA The transfer of messages from Exchange 2003 to a non-Exchange messaging system through X.400 proceeds as follows: 1.

The user sends a new message, which the Exchange store driver places into the pre-submission queue to pass it to the Exchange 2003 transport engine. In Exchange 2003, all messages for local or remote recipients must pass through the transport engine.

2.

The advanced queuing engine transfers the message from the pre-submission queue into the precategorization queue so that the categorizer can process it. The categorizer checks restrictions, applies limits for each sender and recipient, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to pass it back to the advanced queuing engine.

3.

The advanced queuing engine transfers messages for non-local recipients from the post-categorization queue into the pre-routing queue and calls the routing engine. The routing engine determines that the recipient is a user on an X.400 messaging system (based on the user's target address and the address space associated with the X.400 connector) and moves the message to the link queue for the Exchange MTA. The queue manager component manages the link queues.

4.

The Exchange store driver informs the Exchange MTA that a new message awaits transfer. The MTA obtains the message from the link queue, converts recipient information and message bodies from message database encoding format (MDBEF) into an appropriate X.400 format according to the conformance year and character set of the remote MTA as specified in the X.400 connector properties, and places the message in an MTA internal queue on the file system.

5.

The Exchange MTA establishes a connection to the remote MTA, identifies itself, and when the connection is accepted, transfers the message. The remote MTA then delivers the message to the final destination.

122 Exchange Server 2003 Interoperability and Migration Guide

X.400 to Exchange Message Transfer Figure 4.6 shows the process for receiving messages from a remote X.400 MTA.

Figure 4.6 Receiving messages from a remote X.400 MTA The transfer of messages from a remote X.400 MTA to Exchange 2003 can be divided into several steps: 1.

The remote X.400 MTA establishes a connection to the local Exchange MTA, identifies itself as an authorized MTA, and, after the Exchange MTA accepts the connection and the association is established successfully, transfers the message. The Exchange MTA stores the incoming message in its message database on the file system.

2.

The Exchange MTA converts the recipient information and message body into Exchange format and places the message into the SMTP mailbox store to pass it to the SMTP transport engine for delivery. In Exchange 2003, all messages must pass through the SMTP transport engine.

3.

The Exchange store driver places the message in the pre-submission queue of the advanced queuing engine.

4.

The advanced queuing engine transfers the message from the pre-submission queue into the precategorization queue so that the categorizer can process it. The categorizer checks restrictions, applies limits for each sender and recipient, and resolves the recipient information against Active Directory to determine whether the message is going to a local or a remote recipient. The categorizer then places the message in a post-categorization queue to return it to the advanced queuing engine.

5.

The advanced queuing engine transfers messages for local recipients from the post-categorization queue into the local delivery queue.

6.

The Exchange store driver picks up the message and places it into the Inbox of the local recipient.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 123

Exchange/X.400 Message Conversion X.400 connectors support a variety of content types and character sets. X.400 content types include P2 (1984 conformance year), P22 (1988 conformance year), Body Part 14 or Body Part 15 for binary data. When the Exchange MTA communicates with an X.400-84 MTA, the message body is sent using the P2 content type, and attachments are sent using Body Part 14. When communicating according to the 1988 conformance year, text is sent using the P22 content type, and you can configure the server to send attachments using either Body Part 14 or Body Part 15 formatted as a File Transfer Body Part (FTBP). The Exchange MTA supports the following X.400 body parts for message text: •

International Alphabet 5 (IA5) A character set that is similar to US-ASCII and includes western European characters.

•

International Organization for Standardization (ISO) 6937 A character set that includes 333 characters from the Latin script plus non-spacing diacritical marks. To support other languages, character set switching is required as defined in ISO 2022. ISO 6937 is a superset of the Teletex character set definition.

•

ISO 8859 A family of eight-bit single-coded character sets. Most languages that are based on singlebyte characters can be supported in one of the ISO 8859 alphabets.

•

Teletex 61 (T.61) A subset of ASCII, plus international eight-bit characters.

None of the character sets in the P2 or P22 content types can represent RTF information or even OLE objects. Support for RTF is available only if the receiving side can understand MAPI message formats. Many X.400based messaging systems, such as HP OpenMail, support Outlook and therefore MAPI. The Exchange MTA can encapsulate the entire message in TNEF and send it an additional file attachment. The principle is the same as discussed earlier for the SMTP connector. If the receiving system can process the TNEF attachment (for example, if the recipient is using Microsoft Outlook), the message is displayed with all RTF information. However, if the receiving system cannot process TNEF, the message text and attachments might not be readable. You must ensure that the X.400 connector configuration corresponds to the capabilities of the non-Exchange messaging system.

Directory Synchronization Directory synchronization is the process of propagating directory information about Exchange 2003 users from Active Directory to the directory of a non-Exchange messaging system, while propagating information about users from the non-Exchange messaging system to Active Directory to be used by Exchange 2003. When directory synchronization is complete, each system has a complete copy of the directory data (users, groups, and so on) for the combined messaging organization. Directory synchronization consists of two sequential processes: •

Synchronizing recipients from Active Directory to a non-Exchange messaging system

•

Synchronizing recipients from a non-Exchange messaging system to Active Directory

Unfortunately, you cannot use an SMTP connector or an X.400 connector to enable automatic, scheduled directory synchronization between Exchange 2003 and a non-Exchange messaging system, so you must implement a manual or semi-automated solution. When you implement a custom solution for directory synchronization, remember that you must implement a bidirectional process, because recipient attributes must be updated in both directories. For information about how to work programmatically with directory information in a non-Exchange messaging system, contact the vendor of the messaging system. This section explains how to work with Active Directory using standard Active Directory tools.

124 Exchange Server 2003 Interoperability and Migration Guide

Synchronizing Directory Entries from a Non-Exchange Messaging System to Active Directory Directory synchronization from a non-Exchange messaging system to Active Directory includes the following processes: 1.

Extracting directory information from the non-Exchange messaging system You can use a variety of tools to obtain the source directory information, including application programming interfaces (APIs) or LDAP. If the non-Exchange messaging system supports LDAP, you can use the Exchange Migration Wizard to extract directory information from the non-Exchange messaging system. For LDAP directories, ensure that you select the option Migrate from Internet Directory (LDAP via ADSI), and on the next wizard page select the option Extract migration files only. The Exchange Migration Wizard places the extracted directory information into a primary migration file called directory.pri, which is a comma-separated value (.csv) text file that you can use as the basis for further processing, such as for a directory import. For more information about migration files and the Exchange Migration Wizard, see Chapter 1, "Understanding Interoperability and Migration." Note LDAP-conforming directories typically provide SMTP address information, so you should use an SMTP connector if you are using LDAP-conforming directories to connect the messaging systems. If you use an X.400 connector instead, ensure that you obtain the address information in X.400 format. Most messaging systems provide proprietary directory export features that you can use. Ask the administrator who is responsible for the legacy messaging system to provide you with exported directory information in the format that corresponds to the connector that you deploy between Exchange 2003 and the non-Exchange messaging system.

2.

Preparing the directory information for an import into Active Directory The tool that you use to import directory information into Active Directory determines how you must structure the data so that the import can be completed successfully. For example, if you are using Ldifde.exe, you must provide the source data in LDAP Data Interchange Format (LDIF). LDIF is defined in RFC 2849. However, if you are familiar with programming with ADSI or CDOEXM, you can develop a custom solution to import the data. The format of the source data depends on the parsing routines that you implement in your custom solution. Ideally, you use a tool that can parse the input file without requiring format conversions. For example, you might want to parse the .csv-based structure of a directory.pri file directly, in the format in which it was exported from an LDAP directory, to import recipient information into Active Directory. For more information about programming with ADSI or CDOEXM, see the Exchange SDK (http://go.microsoft.com/fwlink/?LinkId=25925).

3.

Importing the directory information into Active Directory You cannot use the Exchange Migration Wizard to perform the actual directory synchronization because the Exchange Migration Wizard is designed to create mailboxes in Exchange 2003. Directory synchronization is based on the assumption that the recipients are still in the legacy system. To perform directory synchronization correctly, your solution must create mail-enabled user accounts or mail-enabled contacts instead of mailbox-enabled user accounts. It is recommended that you create a designated organizational unit for all non-Exchange users in Active Directory for use during the migration process. For non-Exchange users, you can create the following types of user accounts in Active Directory: •

Disabled Windows user accounts Create disabled Windows user accounts if your non-Exchange users are not in your Active Directory environment yet, but will be after migration to Exchange 2003.

•

New Windows user accounts Create enabled Windows accounts for non-Exchange users who work in your Active Directory environment prior to migration.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 125

•

Windows contacts Create Windows contacts for non-Exchange users who are not in your Active Directory environment. The Exchange Migration Wizard can convert these contact objects to user accounts during the migration process.

An interesting question arises regarding distribution lists in the legacy messaging system. You can synchronize distribution lists as contact objects, which has the advantage that you do not need to maintain distribution list membership information in Active Directory. However, if you synchronize distribution lists as contact objects, messages that are sent to a distribution list must first be transferred to the legacy messaging system for distribution list expansion before the messages can be delivered to the individual recipients. If the distribution list contains recipients that refer back to users in the Exchange 2003 organization, messages must return to the Exchange 2003 organization after the distribution list is expanded. To avoid this unnecessary message transfer, you can create mail-enabled groups in Active Directory and specify the individual members directly. If you do this, Exchange 2003 can expand the distribution list immediately and without the overhead of additional message transfer to the legacy messaging system. Groups in Active Directory can contain any type of recipient objects (for example, user accounts, contacts, or other groups). After you create mail-enabled user accounts or mail-enabled contacts in Active Directory that correspond to the recipients in the legacy system, you can mirror the distribution lists from the legacy system and add the required recipient objects as members. When you migrate users later using the Exchange Migration Wizard, the wizard will find existing mail-enabled objects by matching the e-mail address of the account to be migrated to the e-mail address of the target object in Active Directory. During the migration process, the Exchange Migration Wizard converts those recipient objects into mailbox-enabled user accounts and preserves the distribution group membership information. However, if you do not use the Exchange Migration Wizard, you must take extra steps to add the mailbox-enabled user accounts back to all of their distribution groups after migration. It is possible to perform this step programmatically. Note The Exchange Migration Wizard does not export directory information about distribution lists from the legacy messaging system. You must use a different directory export method or create the distribution lists manually in Active Directory.

4.

Updating the directory information in Active Directory After directory information is imported into Active Directory, you must ensure that directory information is kept up-to-date in both directories. For example, if you change or delete a user in the legacy system, the corresponding recipient object must also be updated or deleted in Active Directory. Changing or deleting an existing recipient object requires that you find the existing object in Active Directory and then perform the update. To find recipient objects in Active Directory that correspond to: •

Changed recipient objects in the non-Exchange messaging system You can use the e-mail address of the recipient object to locate its counterpart in Active Directory, because the primary email address of the Active Directory object is the SMTP or X.400 address of the recipient in the legacy messaging system. However, you must account for situations in which e-mail addresses do not match. A user might have a user account in Active Directory that has not been mail-enabled yet or the user's original e-mail address might have changed (for example, a user is given a new SMTP address in the legacy messaging system). In such situations, matching e-mail addresses does not work, and you must use additional attributes to find the matching recipient object. You can use the display name or alias of the user in the legacy system, or any other attribute that allows you to establish a reliable association between the source and target recipient objects.

•

Deleted recipient objects in the non-Exchange messaging system Finding a target object in Active Directory when the source object has been deleted from the legacy non-Exchange messaging system is complicated. The deleted source object no longer exists, so it cannot be used as a reference to locate the corresponding recipient object in Active Directory. In this situation, you can either

126 Exchange Server 2003 Interoperability and Migration Guide

delete the corresponding recipient object manually from Active Directory, or compare the complete address list from the non-Exchange messaging system with the complete list of corresponding recipient objects in Active Directory to determine which objects exist only in Active Directory. Mailenabled Active Directory accounts without a counterpart in the source messaging system indicate that the source objects have been deleted. To compare address lists, you must associate the recipient objects that you create in Active Directory with their counterparts in the non-Exchange messaging system. You might be able to use the SMTP domain name of the legacy messaging system to establish this association. Another option is to use an organizational unit exclusively for the recipient objects that belong to a specific legacy messaging system. You can then compare the objects in that organizational unit to the list of recipients in the legacy system. A third, and perhaps the most reliable way to compare address lists, is to write specific information about the messaging system that the recipients reside in into an attribute of the recipient objects in Active Directory. You can then use this attribute as the basis for an LDAP query. You can either use an extension attribute or the attribute called importedFrom to register your specific synchronization information. Figure 4.7 shows the general process for transferring directory information from a non-Exchange messaging system to Active Directory based on LDAP, the Exchange Migration Wizard, and a custom script that processes the directory.pri file. If you prefer a solution without a custom script, you can replace the custom script with Ldifde.exe, but remember that you must then convert the directory.pri file format into an LDF format to support Ldifde.exe.

Figure 4.7 Directory synchronization from a non-Exchange messaging system to Active Directory

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 127

Synchronizing Directory Entries from Active Directory to a Non-Exchange Messaging System Directory synchronization from Active Directory to a non-Exchange messaging system is based on the same principles as directory synchronization from a non-Exchange messaging system to Active Directory. You must extract information about mailbox-enabled user accounts from Active Directory, process the information, and then import, update, or delete the information in the legacy directory. You can use tools such as Ldifde.exe, Csvde.exe, or ADSI to extract Active Directory data. You can also use the Exchange Migration Wizard, because Active Directory is a supported LDAP-conforming directory. The advantage of using the Exchange Migration Wizard to extract Active Directory data is that the extracted directory information is placed in a directory.pri file in exactly the same way as the directory information from any other LDAP directory. Therefore, you can re-use the file-parsing routines that you used for non-Exchange to Active Directory directory synchronization. Only the APIs or tools for importing the directory information into the legacy directory will differ. For details about how to import directory information into the legacy messaging system, contact the messaging system vendor. Note For Active Directory to non-Exchange directory synchronization to work, the non-Exchange messaging system must be able to hold directory information for users who are outside the local messaging system. Most systems allow you to associate SMTP or X.400 recipient objects with connectors or remote domains in their directory. When connecting the messaging systems through SMTP, you must synchronize Exchange users as Internet recipients. When connecting the messaging systems using an X.400 connector, you must synchronize Exchange users as X.400 recipients. All Exchange users have at least one SMTP address and one X.400 address.

Figure 4.8 shows the general process for transferring directory information from Active Directory to a nonExchange messaging system using the Exchange Migration Wizard and a custom script that uses nonMicrosoft APIs or import tools to place the recipient objects into the legacy directory.

128 Exchange Server 2003 Interoperability and Migration Guide

Figure 4.8 Directory synchronization from Active Directory to a non-Exchange messaging system One disadvantage of using the Exchange Migration Wizard to extract directory information from Active Directory is that you cannot extract information for mail-enabled user accounts, contacts, or distribution groups from Active Directory. If your Exchange 2003 organization is connected to multiple nonExchange messaging systems, or if you created mail-enabled objects for recipients on the Internet, you might want to include these mail-enabled objects in your custom directory synchronization process so that users in the non-Exchange messaging systems can communicate conveniently with all users in your messaging environment using the Exchange 2003 organization as a backbone. You must use tools such as Ldifde.exe, Csvde.exe, or ADSI to extract mail-enabled objects from Active Directory. The best way to synchronize mailenabled distribution groups is as contact objects, so that you can bypass the group membership synchronization. You can address distribution group issues in various ways, as discussed in Chapter 1, "Understanding Interoperability and Migration." Note If you decide to synchronize mail-enabled contacts, you must examine your directory synchronization processes carefully to avoid duplicating address information, which might happen if you synchronize mail-enabled objects that refer back to actual recipients in the legacy messaging system.

Directory Synchronization Alternatives Implementing a custom solution for directory synchronization is a good choice for system administrators who prefer to work with command-line tools and APIs. If you prefer to implement a more readily available solution, however, you might want to consider the following options: •

Messaging connectors available in Exchange Server 5.5 or Exchange 2000 Server If you are running a mixed Exchange organization, you might be able to use messaging connectors for message transfer and directory synchronization that were included with Exchange 5.5 or Exchange 2000 but are

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 129

not available in Exchange 2003. For example, you can use Exchange 2000 to connect seamlessly to Microsoft Mail for PC Networks or Lotus cc:Mail, and Exchange 5.5 to connect to Microsoft Mail for PC Networks, Lotus cc:Mail, IBM PROFS, and IBM Systems Network Architecture Distribution Services (SNADS) with a direct gateway connector. •

Microsoft Metadirectory Services (MMS) You can use MMS to integrate multiple directories with each other. MMS supports a broad range of directory services, including Active Directory, the Exchange 5.5 directory, Microsoft Windows NT® domains, Lotus Notes/Domino, Lotus cc:Mail, Novell NetWare Directory (NDS) or Novell NetWare Bindery, Novell GroupWise, Banyan Systems BeyondMail and Intelligent Messaging, Structured Query Language (SQL)/Open DataBase Connectivity (ODBC) and LDAP-based directory servers such as Netscape, Sun ONE (formerly known as Netscape iPlanet), and X.500-based directories. MMS is a good choice if your Exchange 2003 organization must permanently coexist with a non-Exchange messaging system. However, if you are planning to replace the legacy infrastructure by migrating to Active Directory and Exchange 2003 in the foreseeable future, an investment in MMS might not be warranted. For more information about MMS, visit http://go.microsoft.com/fwlink/?LinkId=25926.

•

Connector for Lotus Notes If you are connecting Exchange 2003 to Lotus Notes/Domino, but want to send e-mail messages through SMTP instead of using Connector for Lotus Notes, you can keep the directories synchronized using the directory synchronization features that Connector for Lotus Notes provides. You only have to modify the mapping tables for the directory attributes so that Exchange recipients appear as SMTP recipients in Lotus Notes, and Lotus Notes recipients appear as SMTP contacts in Active Directory. For detailed information about how to edit the mapping tables, see Microsoft Knowledge Base Article 303724 "Directory Synchronization Between Notes and Exchange with SMTP Addresses" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=303724).

Calendar Integration Exchange 2003 maintains free/busy information in a hidden system public folder called SCHEDULE+ FREE BUSY, and it requires a Calendar Connector instance to place free/busy information for non-Exchange users into this system folder. Unfortunately, Calendar Connector is not available when you connect Exchange 2003 to a non-Exchange messaging system through an SMTP connector or an X.400 connector. You can work around this limitation by using Outlook Internet Free/Busy (IFB) publishing. Outlook users can use this feature to publish free/busy information in a shared location so that other users, who otherwise would not have access to the information, can retrieve it. Outlook users can publish their free/busy times using the Microsoft Office Internet Free/Busy service or at a location in the internal network. When using the Free/Busy service, you can limit access to the published information so that only service members that you specifically authorize can view your information. By default, Outlook updates the free/busy information on the Free/Busy service every 15 minutes, so that it reflects your latest schedule. When other users schedule a meeting with you, the free/busy times that you published to the Free/Busy service are automatically displayed as shaded bars on the Scheduling tab in their meeting request, so that they know at which times you are not available. For more information about the Free/Busy service, go to http://go.microsoft.com/fwlink/?LinkId=25927. Alternatively, you can publish your free/busy information on an internal server. The advantage of this option is that no service memberships are required. You can use a Web server on the intranet, an internal File Transfer Protocol (FTP) server, or a file server to provide the shared repository. The only difference among these options is the Uniform Resource Locator (URL) that you must specify in your Outlook configuration for the location where free/busy information should be published. You can use any valid URL format, such as: http://, file://\, or ftp://. Figure 4.9 shows one possibility for implementing free/busy information sharing in an environment with a non-Exchange messaging system.

130 Exchange Server 2003 Interoperability and Migration Guide

Figure 4.9 Sharing free/busy information between Outlook users in different messaging systems Publishing free/busy information over the Internet or intranet works well if all users have Outlook. However, IFB publishing is supported only if you use Outlook with the Internet Mail Only option. For information about how to configure Outlook with the Internet Mail Only option, see your Outlook product documentation. Other messaging clients might also support publishing free/busy information over the Internet or intranet, because IFB publishing is based on an Internet Engineering Task Force (IETF) standard called iCal. IFB publishing is based on the vCalendar standard that is part of iCal and an emerging standard for the format and storage of free/busy information. If you enable IFB publishing in an Exchange organization where users typically access their mailboxes through the MAPI transport service for Exchange, Outlook will continue to use the SCHEDULE+ FREE BUSY system public folder for all Exchange recipients that are in the server-based address lists. It will not check the Free/Busy service or a shared repository for these server-based accounts in addition. These serverbased accounts include all Exchange users and also all non-Exchange recipients that you synchronized with Active Directory. In other words, IFB publishing works well until you perform directory synchronization. This is because, as far as Outlook is concerned, mail-enabled user accounts and mail-enabled contacts in Active Directory are both recipients in the Exchange 2003 organization for which Outlook does not expect to find free/busy information published at a shared location in the corporate network. IFB publishing does not work because Outlook checks only the SCHEDULE+ FREE BUSY system public folder for non-Exchange users with synchronized recipient objects, but the free/busy information does not exist at this location. To work around the fact that IFB publishing does not work with Outlook, except with the Internet Mail Only option, you have the following choices:

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 131

•

Do not perform directory synchronization If sharing calendar information is more important than providing consistent address lists across all messaging systems, you can choose not to synchronize the directories. However, synchronizing directories is usually required for seamless interoperability, and it is a higher priority than IFB publishing. If you want to provide consistent server-based address lists, you must look for a different solution to provide cross-platform access to free/busy information.

•

Save calendar information as a Web page If you do not want to use the IFB publishing feature, you can publish a one-month snapshot of your calendar with all appointments and meetings to a Web page. However, it is important to note that this method discloses all details about your meetings and other appointments. You are publishing more than free/busy times in this scenario. In addition, the Web page does not automatically update as you add, remove, or revise appointments in your Calendar folder, so you need to save your calendar each time you want to update the Web version.

•

Provide access to calendar information through an ASP.NET page Instead of saving calendar snapshots as Web pages, you can choose to implement a custom solution for free/busy lookups using Exchange programming APIs, such as CDOEX. CDOEX provides a GetFreeBusy method through the IAddressee interface that you can call programmatically in an ASP.NET page or a Visual Basic program. You can also use other programming languages, such as C++ or Microsoft C#. As the name implies, the GetFreeBusy method gets the free/busy information of a valid Exchange 2003 user. Note CDOEX can only be used directly on a server running Exchange 2000 or Exchange 2003. For this reason, it is best to use the GetFreeBusy method in an ASP.NET page published through Microsoft Internet Information Services (IIS) on an Exchange 2003 server.

The following Visual Basic .NET code example, taken from the Exchange SDK, demonstrates how to obtain free/busy information for a specified user. You can use this code to provide non-Exchange users with a Web-based solution to access free/busy information of Exchange users. For more information about the GetFreeBusy method, see "Checking Free/Busy Status" (http://go.microsoft.com/fwlink/?LinkId=25928). ' Reference to Microsoft ActiveX Data Objects 2.5 Library ' Reference to Microsoft CDO for Exchange 2000 Library ' Reference to Active DS Type Library Function GetFreeBusyString(ByVal strUserUPN As String, _ ByVal dtStartDate As Date, _ ByVal dtEndDate As Date, _ ByVal Interval As Integer) As String Try ' Variables. Dim iAddr As New CDO.Addressee() Dim freebusy As String Dim Info As New ActiveDs.ADSystemInfo() iAddr.EmailAddress = strUserUPN If Not iAddr.CheckName("LDAP://" & Info.DomainDNSName) Then Throw New System.Exception("Error occurred!") End If ' Get the free/busy status in Interval minute intervals ' from dtStartDate to dtEndDate.

132 Exchange Server 2003 Interoperability and Migration Guide

freebusy = iAddr.GetFreeBusy(dtStartDate, dtEndDate, Interval) GetFreeBusyString = freebusy Catch err As Exception Console.WriteLine(err.ToString()) GetFreeBusyString = "" End Try End Function

The GetFreeBusy method can be used only to obtain Exchange free/busy information. However, many messaging systems provide Web interfaces for accessing data in mailboxes and public repositories. Check with the vendor of your legacy system to see if a similar API is available, so that you can provide Exchange users with access to calendaring information through a custom Web-based solution as well. •

Configure Outlook to use IFB publishing, but use another solution to access published free/busy information Another, and perhaps better, option for providing both non-Exchange and Exchange users with access to each other's free/busy information in an ASP.NET solution is to parse the vCalendar files that the Outlook clients can write to a shared directory when IFB publishing is enabled. Publishing free/busy information always works; only the lookup of free/busy information for synchronized recipient objects is a problem for Exchange users. An ASP.NET solution can solve this problem. Exchange and non-Exchange users can configure their Outlook clients to publish free/busy information on a Web server and then use the ASP.NET-based solution as a tool when they book meetings and conferences. Implementing an ASP.NET solution to parse vCalendar files is beyond the scope of this book. For more information, see the Exchange SDK (http://go.microsoft.com/fwlink/?LinkId=25925).

•

Ignore the issue Another option is to avoid free/busy integration altogether. If it is possible to migrate teams and departments as one unit, users may not need cross-platform free/busy information. If you migrate all likely meeting candidates to Exchange 2003 at the same time, users can use the standard Outlook feature for free/busy lookups when they plan meetings.

Implementing Messaging Connectivity After you gain a general understanding of Exchange 2003 interoperability options, you can prepare to implement seamless connectivity. One important consideration is which connector to deploy. The flowchart shown in Figure 4.10 can be used as a guide for finding the right connector.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 133

Figure 4.10 Determining Exchange 2003 to non-Exchange connectivity options Consider the following recommendations: 1.

If you can deploy a direct gateway connector to the legacy messaging system, you might want to use this direct connector so that you can implement automated, scheduled directory synchronization.

2.

If a direct gateway connector is not available, but the legacy messaging system supports SMTP, use an SMTP connector to connect the messaging systems. Implementing SMTP connectivity is more straightforward than implementing X.400 connectivity.

3.

If the legacy messaging system supports only X.400, use an X.400 connector.

4.

If there is no connector, or if the cost of implementing a connectivity solution is prohibitive, perform a single-phase migration, as discussed in Chapter 1, "Understanding Interoperability and Migration."

This chapter focuses on connector components that are available in Exchange Server 2003, specifically the SMTP connector and the X.400 connector. In theory, you need only a single server running Exchange 2003 to deploy either of these connectors. However, running the SMTP connector or the X.400 connector on an Exchange server that hosts mailboxes is not recommended. You should have at least one Exchange 2003 server that includes your Exchange mailboxes and a separate Exchange 2003 server that includes the SMTP connector or the X.400 connector. For the purposes of this section, it is assumed that you have a single non-Exchange messaging host. However, the information provided here can be applied to larger or more complex deployments. In larger deployments, the non-Exchange messaging system that you connect to acts as the bridgehead for other messaging systems in the legacy infrastructure.

134 Exchange Server 2003 Interoperability and Migration Guide

Figure 4.11 shows the most basic Windows and Exchange 2003 configuration that you should consider for configuring and testing interoperability with a non-Exchange messaging system.

Figure 4.11 Basic Windows and Exchange environment Note The following section is a conceptual discussion of configuration steps. For complete procedures with detailed step-by-step instructions for configuring the SMTP connector and the X.400 connector, see Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System."

Implementing SMTP Connectivity You must complete the following steps to configure an SMTP connector to a non-Exchange messaging system: 1.

Ensure that prerequisites are met Before you configure an SMTP connector on a bridgehead server running Exchange 2003, you must ensure that the Exchange 2003 server can resolve the name of the remote SMTP host to an IP address and can open a TCP/IP connection to TCP port 25, which is the standard port for SMTP. It might be necessary to verify the internal DNS configuration so that the Exchange bridgehead server and the remote SMTP host can locate each other. An alternative is to specify the remote SMTP host in the SMTP connector configuration directly and provide similar configuration settings in the remote messaging system, so that messages can be transferred in both directions without DNS lookups.

2.

Prepare the existing messaging environment To support proper message routing between Exchange 2003 and the legacy messaging system, the two environments cannot share the same SMTP domain name. For example, if the users in the legacy environment have an SMTP domain named fabrikam.com, users in the Exchange 2003 organization cannot also have fabrikam.com as their SMTP domain name. SMTP message routing does not work if the two SMTP domain names are the same, because the systems cannot distinguish non-Exchange from Exchange users. One option is to change the SMTP domain name so that users in the legacy messaging environment belong to an SMTP domain named legacy.fabrikam.com and the users in the Exchange 2003 organization belong to an SMTP domain named exchange.fabrikam.com. An alias file on a central smart host can then be used to map external user addresses in the form of [email protected] to the internal addresses [email protected] or [email protected]. This configuration is shown in Figure 4.12. Additional options for preserving the public SMTP addresses of your users in a multiphase migration are discussed in Chapter 1, "Understanding Interoperability and Migration."

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 135

Figure 4.12 Splitting an SMTP domain into subdomains 3.

Prepare the Exchange 2003 environment If the Exchange 2003 organization already exists, you might need to change the SMTP domain name of your Exchange users as well. You do this by changing the default recipient policy in Exchange System Manager. Recipient policy objects reside in the Recipient Policies container under the Recipients node. Display the properties for the Default Policy object, switch to the E-Mail Addresses (Policy) tab, and then change the SMTP address reference. For example, specify @exchange.fabrikam.com instead of @fabrikam.com. Remember that you must implement a solution to preserve the existing e-mail addresses of your users so that e-mail communication with external environments, such as customers and business partners, is not disrupted. Do not change the domain name until you have decided how to resolve this issue. It is possible to adjust the SMTP addresses in a recipient policy even further. For example, you can change the user name portion, which by default refers to the name of the user account. For a list of placeholders that you can use in address generation rules to customize SMTP address generation, see Table 1.6 in Chapter 1, "Understanding Interoperability and Migration." For example, you can set the address format to %[email protected]. As a result, a user whose display name is Ted Bremer receives an SMTP address of [email protected].

136 Exchange Server 2003 Interoperability and Migration Guide

4.

Configure the SMTP connector and Internet message formats The SMTP connector is configured using Exchange System Manager. The location of the connector in Exchange System Manager depends on whether you have enabled viewing for routing or administrative groups. Figure 4.13 shows the location of the connector when viewing for both routing and administrative groups is enabled.

Figure 4.13

Location of connector instances in Exchange System Manager

At a minimum, you must specify whether the SMTP connector instance should use DNS to determine the remote SMTP host through MX records, or provide the host name or IP address of the remote SMTP host directly on the General tab. You also must specify the local bridgehead servers that will use this connector instance to transfer messages. It is possible to specify multiple remote and local bridgehead servers. You must also define an address space for the connector on the Address Space tab to identify the SMTP domain to which this connector instance connects (for example, legacy.fabrikam.com). The remaining connector parameters do not usually apply when you use an SMTP connector to connect to a non-Exchange SMTP host in the internal TCP/IP network. Because you are connecting to a non-Exchange messaging environment in which the capabilities of the messaging clients are well known, you might also want to configure an explicit SMTP policy for the SMTP domain that refers to the legacy messaging system. SMTP policies are configured in the Internet Message Formats container under Global Settings in Exchange System Manager. See Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System," for an example of how to configure an SMTP policy for a non-Exchange messaging environment with users using Outlook in an IMAP4 configuration. 5.

Test e-mail connectivity To ensure that message routing works, send test messages from the nonExchange messaging system to Exchange 2003 and then reply to these messages to ensure that message transfer also works in the opposite direction. Note Always test newly configured Exchange connectors in both directions.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 137

Implementing X.400 Connectivity You must complete the following steps to configure an X.400 connector to a remote MTA: 1.

Ensure that prerequisites are met Configuring an X.400 connector is a complex task, especially when you are connecting to a non-Exchange X.400 system. You must specify all configuration settings carefully and ensure that they match the configuration of the remote system. You must obtain all of this information from the administrator of the remote X.400 MTA prior to configuring a connector instance, and you must provide the remote administrator with information about the local configuration. X.400 connectivity requires that both sides specify, among other things, MTA names and passwords. If this information does not match the configuration of the remote X.400 system, connection requests will be refused, and messages will not be transferred. You can find the local MTA information in Exchange System Manager, in the properties of the X.400 object located in the Protocols container under your bridgehead server.

2.

Prepare the Exchange MTA You must install a transport stack in Exchange System Manager for the X.400 connector instance to use. Two transport stacks are available: the TCP/IP transport stack and the X.25 transport stack. The transport stack configuration concerns the configuration of the remote MTA. It defines the address information for the remote system, such as the remote host name or IP address for a TCP/IP X.400 connector, or the X.121 address for an X.25 X.400 connector. You must also specify SSAP, PSAP, and TSAP if the remote MTA (S Selector, P Selector, and T Selector) uses this address information. Ask the remote administrator for this information. You must also inform the remote administrator about the transport stack configuration of your Exchange MTA. If the remote administrator requires you to use specific local Open System Interconnection (OSI) address information when you connect to the remote MTA, you can specify this information on a per-connector basis on the Override tab of the X.400 connector.

3.

Configure the X.400 connector instance After you have added the transport stack, you are ready to configure the X.400 connector object in Exchange System Manager. As with the SMTP connector object, the location of the connector object in Exchange System Manager depends on whether you enable viewing for routing or administrative groups. Figure 4.13 shows the location of the connector when viewing for both routing and administrative groups is enabled. In addition to specifying the remote MTA name and password on the General tab, specifying the host name or IP address on the Stack tab, overriding the local MTA name and password, as well as local OSI address information and other protocol parameters on the Override tab, and specifying a correct X.400 address space on the Address Space tab, you must adjust the Exchange MTA conformance features on the Advanced tab when connecting to a non-Exchange remote MTA. Important settings are the X.400 conformance year and body parts. The MTA conformance year, for example, must match the conformance year of the remote MTA, because significant differences exist between the 1984 and 1988 X.400 standards. If the MTA conformance year of the local MTA does not match the conformance year of the remote MTA, the local MTA overtaxes the remote MTA and communication problems occur. Ensure that the Allow Exchange Contents check box is not selected, because Exchange message content is not X.400 conforming. The remote MTA will refuse messages that violate the X.400 standard. You can send Exchange message content only when connecting to a remote Exchange MTA in another routing group of the same Exchange organization.

138 Exchange Server 2003 Interoperability and Migration Guide

4.

Test e-mail connectivity To ensure that the message routing works, send test messages from the nonExchange messaging system to Exchange 2003 and then reply to these messages to ensure that message transfer also works in the opposite direction. To find your X.400 address, start Active Directory Users and Computers and display the E-Mail Addresses tab for your user account. As mentioned earlier, you must test newly configured Exchange connectors in both directions. This is especially important for X.400 connectivity where incorrect configuration settings often affect one side only. Note Exchange 2003 assigns the administrative management domain portion in X.400 addresses a single space character (" ") by default. You must specify this space in the address information when sending test messages. X.400 addresses without administrative management domain information violate the X.400 standard.

Implementing Multiple Connector Instances You can configure multiple SMTP or X.400 connector instances to the same target system for load balancing and fault tolerance. Configuring multiple SMTP connectors might not be necessary, because a single connector instance can use multiple remote and local SMTP bridgehead servers. However, to achieve load balancing and fault tolerance over X.400, multiple connectors must be deployed, because a single X.400 connector can only be used to connect one Exchange MTA to one remote X.400 MTA. When you assign a particular connector instance an address space, you also assign this address space a cost value. If multiple routes are available and each has a different cost value, the connection with the lowest overall cost value is chosen. If more than one link has the same cost, Exchange 2003 chooses connectors installed on the local computer over connectors installed on remote Exchange servers. When there is more than one potential local connector, random load balancing is performed. Random load balancing is also performed when multiple bridgehead servers are specified in a single SMTP connector instance. For more information about address spaces and load balancing, see the Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=26041). If you want to implement a preferred SMTP connection between Exchange 2003 and a remote SMTP host, you must configure multiple SMTP connector instances and then assign all instances the same address space, but different cost values, with the lowest cost value identifying the most preferred connector. Exchange 2003 performs dynamic message routing over less preferred connector instances based on link state information if the preferred connector is unavailable. Inbound to Exchange 2003, multiple message paths can also be provided if you have multiple Exchange servers. If the remote SMTP host uses DNS to locate its communication partners, you can register your Exchange bridgehead SMTP servers in MX records and assign different DNS preference values. The MX record with the lowest value is chosen unless this mail exchanger host is unavailable, in which case the mail exchanger with the next lowest value is chosen. Figure 4.14 shows a connector and DNS MX record configuration for an Exchange 2003 organization with two bridgehead servers running separate SMTP connector instances. One bridgehead server is primarily responsible for outbound message transfer, and the remote SMTP host usually chooses the other bridgehead server for inbound messages because its MX record has a lower priority value.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 139

Figure 4.14 Preferred bridgehead servers for inbound or outbound SMTP message transfer

Implementing Directory Synchronization This section explains how to perform directory synchronization manually between an LDAP-conforming directory and Active Directory. For more information about how to create recipient objects programmatically, see Chapter 1, "Understanding Interoperability and Migration." You must complete the following steps to perform directory synchronization between a non-Exchange messaging system and Exchange 2003: 1.

Extract the source directory information into a migration file Directory information can usually be obtained from a messaging system in several ways. One way is to use directory export features included in the administrative tools included with the non-Exchange messaging system. Another way to obtain directory information from a messaging system is to use the Exchange Migration Wizard, as discussed earlier in this chapter. For example, you can use the Exchange Migration Wizard to extract directory information from an LDAP-conforming directory. Step-by-step instructions for using the Exchange Migration Wizard to extract LDAP directory information are included in Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System." If you run the Exchange Migration Wizard against an LDAP directory other than Netscape Directory Server, you might notice that the migration wizard is unable to identify user objects correctly and thus is unable to perform the extraction. Some clues that this problem exists include users being listed as Internet containers on the Containers wizard page and an empty accounts list on the Account Migration wizard page.

140 Exchange Server 2003 Interoperability and Migration Guide

By default, the Exchange Migration Wizard expects user accounts to have an object class of inetOrgPerson. If your directory uses another object class, the migration wizard cannot identify and migrate the user accounts unless you edit the .ini file called mlmigad.ini, located in the \Program Files\Exchsrvr\Bin directory and specify the object class of the user account in the ADSI_ObjectClass line. For example, Active Directory uses an object class of organizationalPerson for user accounts. Table 4.2 lists all settings that you can specify in mlmigad.ini. Table 4.2

Mlmigad.ini configuration parameters for LDAP directory exports

Parameter

Default value (corresponds to Netscape Directory Server)

Active Directory equivalent

Description

ADSI_ObjectClass

inetOrgPerson

organizationalPerson

Used to determine which objects are mail users.

ADSI_UserID

uid

cn or sAMAccountName

When extracting LDAP information for a subsequent migration of IMAP4 mailboxes, this parameter is used by the IMAP extractor to log on to the IMAP mailbox. This is a required attribute.

ADSI_MailServer

mailhost

Mailhost

When extracting LDAP information for a subsequent migration of IMAP4 mailboxes, this parameter is used by the IMAP extractor to log on to the IMAP mailbox. This is a required attribute.

ADSI_EmailAddress

mail

Mail

When extracting LDAP information for a subsequent migration of IMAP4 mailboxes, this parameter is used as a secondary proxy address in Exchange. Mail sent to this address is routed to the Exchange mailbox. This is a required attribute.

ADSI_FullName

not specified

displayName

Used to create a display name in Exchange. If this is left blank, the display name is created from other attributes, such as the email address. This is an optional attribute.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 141

Parameter

Default value (corresponds to Netscape Directory Server)

Active Directory equivalent

Description

ADSI_FirstName

givenname

givenName

The user's first name. This is an optional attribute.

ADSI_LastName

sn

Sn

The user's last name. This is an optional attribute.

ADSI_Initials

initials

Initials

The user's middle initial(s). This is an optional attribute.

ADSI_NickName

uid

mailNickname

The user's short name, also used for the Exchange alias. This is an optional attribute.

ADSI_Title

title

Title

The user's title. This is an optional attribute.

ADSI_Company

not specified

company

The user's company name. This is an optional attribute.

ADSI_Department

ou

department

The user's department name. This is an optional attribute.

ADSI_Office

roomnumber

physicalDeliveryOfficeName The location of this user's office. This is an optional attribute.

ADSI_PostalAddress

postaladdress

streetAddress

The user's postal address. This is an optional attribute.

ADSI_City

l

L

The user's city. This is an optional attribute.

ADSI_StateOrProvince

st

St

The user's state or province. This is an optional attribute.

ADSI_PostalCode

postalcode

postalCode

The user's postal code. This is an optional attribute.

ADSI_Country

not specified

Co

The user's country. This is an optional attribute.

ADSI_TelephoneNumber telephonenumber

telephoneNumber

The user's business telephone number. This is an optional attribute.

ADSI_TelephoneNumber not specified 2

otherTelephone

The user's second business telephone number. This is an optional attribute.

142 Exchange Server 2003 Interoperability and Migration Guide

Parameter

Default value (corresponds to Netscape Directory Server)

Active Directory equivalent

Description

ADSI_TelephoneHome

homephone

homePhone

The user's home telephone number. This is an optional attribute.

ADSI_TelephoneHome2

not specified

otherHomePhone

The user's second home telephone number. This is an optional attribute.

ADSI_TelephoneMobile

mobile

mobile

The user's mobile telephone number. This is an optional attribute.

ADSI_TelephonePager

pager

Pager

The telephone number of the user's pager. This is an optional attribute.

ADSI_TelephoneFax

facsimiletelephonenumber facsimileTelephoneNumber

The telephone number of the user's fax machine. This is an optional attribute.

ADSI_AssistantName

secretary

assistant

The name of the user's assistant. This is an optional attribute.

ADSI_AssistantPhone

not specified

telephoneAssistant

The telephone number of the user's assistant. This is an optional attribute.

ADSI_AlternateAddress

mailalternateaddress

proxyAddresses

Used as an additional SMTP address for the user in Exchange. This is an optional attribute.

ADSI_Comment

description

Info

The comment for this user. This is an optional attribute.

Note The Exchange Migration Wizard ignores nonexistent or misspelled directory attributes.

2.

Format the exported directory information for directory import Running the Exchange Migration Wizard with a properly configured mlmigad.ini file against an LDAP directory creates a directory.pri migration file that contains all of the exported recipient information. Figure 4.15 shows a sample directory.pri file from an Internet mail system.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 143

Figure 4.15

A sample directory.pri file

You can use the information from this file to format an import file in LDAP Data Interchange Format (LDIF) so that you can use Ldifde.exe to create or update recipient information in Active Directory. The following listing shows an LDIF file for importing three accounts into Active Directory. Importing this LDIF file creates mail-enabled contacts in a dedicated organizational unit named Remote SMTP Recipients. You must create the organizational unit before you import the accounts.

144 Exchange Server 2003 Interoperability and Migration Guide

dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add objectClass: contact cn: Ted Bremer sn: Bremer givenName: Ted displayName: Ted Bremer mailNickname: Ted targetAddress: SMTP: [email protected] mail: [email protected] extensionAttribute1: Manual DirSync Process dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add objectClass: contact cn: Birgit Seidl sn: Seidl givenName: Birgit displayName: Birgit Seidl mailNickname: Birgit targetAddress: SMTP: [email protected] mail: [email protected] extensionAttribute1: Manual DirSync Process dn: CN=Kim Akers,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add objectClass: contact cn: Kim Akers sn: Akers givenName: Kim displayName: Kim Akers mailNickname: Kim targetAddress: SMTP: [email protected] mail: [email protected] extensionAttribute1: Manual DirSync Process

Note For more information about how to use Ldifde.exe to create user accounts and how to convert a .csv file into an LDIF file using a Microsoft Excel macro, see Chapter 1, "Understanding Interoperability and Migration."

3.

Import the directory information into Active Directory Importing a properly formatted LDIF file using Ldifde.exe is a straightforward process. Use the following commands at a command prompt: ldifde -i –f -s <Server>, for example, ldifde -i -f c:\importfile.ldf -s Server01.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 145

If you attempt to create new accounts for users who already exist in Active Directory, Ldifde.exe reports an error and stops the import process. You might need to search Active Directory for existing user accounts that correspond to recipients in the non-Exchange messaging system and modify the import file to change attributes for those accounts instead of adding new accounts. Searching and updating Active Directory objects is explained below. The following response indicates that an account already exists: Importing directory from file "c:\importfile.ldf" Loading entries. Add error on line 1: Already Exists The server side error is "An attempt was made to add an object to the directory with a name that is already in use." 0 entries modified successfully.

In contrast, a positive response contains the following information: Logging in as current user using SSPI Importing directory from file "c:\importfile.ldf" Loading entries.... 3 entries modified successfully.

The mail-enabled contacts now exist in Active Directory and Exchange users can select these contacts from the global address list to send them messages. Figure 4.16 shows the contact objects in the Remote SMTP Recipients organizational unit.

Figure 4.16 4.

Mail-enabled contacts imported for Internet mail users

Keep the directory information updated in Active Directory You might want to perform an update of recipient information whenever the address lists change in the source directory system, so that all directories contain consistent information. The simplest way to do this is to delete all previously imported recipient objects from Active Directory and then perform a new import with fresh information extracted from the source directory. You need to find only the previously imported objects. When you analyze the LDIF import listing shown above, you will find the following line in each account section:

146 Exchange Server 2003 Interoperability and Migration Guide

extensionAttribute1: Manual DirSync Process. This information is used to associate the user

accounts with the manual directory synchronization process. You can create a filter based on this information to retrieve all objects that were previously created from Active Directory. For example, you can use the following command at a command prompt to search through an entire domain in a global catalog server for all recipient objects for which extensionAttribute1 has a value of Manual DirSync Process: ldifde -f c:\Exportuser.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(extensionAttribute1=Manual DirSync Process)" -l "targetAddress"

Ldifde.exe writes the following results into the export file: dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add targetAddress: SMTP: [email protected] dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add targetAddress: SMTP: [email protected] dn: CN=Kim Akers,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add targetAddress: SMTP: [email protected]

To delete these accounts, you must change the exported file into an import file with the following LDIF content and import the file using an LDIFDE import command, such as ldifde -i -f c:\importfile.ldf -s Server01: dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: delete dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: delete dn: CN=Kim Akers,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: delete

After you have deleted the outdated account information, you can re-import the new address list to recreate all contacts with fresh directory information. However, deleting and re-creating the entire address list each time changes occur might not be a good approach. The Recipient Update Service must assign all objects new e-mail addresses, all objects must be replicated to the global catalog again, and deleting the old accounts might not even be possible if your Internet mail users work with mail-enabled user accounts in Active Directory. Important If you delete a Windows user account and re-create it afterwards, you create an entirely new object with a different security identifier. In other words, your users will lose all special permissions to file shares and other resources that have been assigned to their old user accounts individually. Therefore, if your users work with mail-enabled user accounts, do not use the approach of deleting and recreating recipient objects in Active Directory to keep directory information synchronized.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 147

A best practice when performing directory updates is to compare the address information from the source directory with the directory information that is in Active Directory. You can use the common name, email address, or any other user attribute that supports a reliable association of directory objects to access the existing information in Active Directory. For example, the following LDIFDE command retrieves the display name and telephone number for all recipient objects that have an SMTP domain of legacy.fabrikam.com in their e-mail address from a global catalog server. ldifde -f c:\Exportuser.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(mail=*@legacy.fabrikam.com)" "displayName,telephoneNumber"

-l

You can examine the resulting export file to determine all recipients with changed display names or telephone numbers, create a new LDIF file with updated values, and import this file into Active Directory to update the values for the existing accounts. The following LDIF file shows how to modify the display name for two recipients. To demonstrate how to modify two attributes for an account, the telephone number is also changed for the first object: dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: modify replace: displayName displayName: Ted replace: telephoneNumber telephoneNumber: 425 5550150 dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: modify replace: displayName displayName: Birgit -

5.

Perform directory synchronization in the opposite direction You must also update the non-Exchange directory using the same principles discussed for Active Directory updates to implement directory synchronization from Active Directory to the legacy directory. As outlined earlier, the Exchange Migration Wizard can extract directory information from Active Directory into a directory.pri file. Ensure that you specify organizationalPerson for the ADSI_ObjectClass in the mlmigad.ini file. Otherwise, the Exchange Migration Wizard will not be able to identify the user accounts. You can also use Ldifde.exe to export all users with mailboxes in Exchange Server 2003, which enables you to export selected mailboxenabled user accounts only. You must exclude all mail-enabled recipient objects that refer to users with mailboxes in the legacy messaging system. The following command retrieves all mailbox-enabled user accounts from a global catalog server: ldifde -f Exportuser.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(&(objectClass=User)(homeMDB=*))" -l "cn,mail,samAccountName"

Note For information about how to import directory information for SMTP recipients, contact the vendor of your non-Exchange messaging system.

148 Exchange Server 2003 Interoperability and Migration Guide

Implementing Calendar Interoperability For the purposes of this section, it is assumed that all non-Exchange and Exchange users work with Outlook 2003. As a MAPI-based client, Outlook can be used in a variety of messaging configurations with Exchange, Microsoft Mail for PC Networks, IMAP4, Lotus Notes, Novell GroupWise, HP OpenMail, AT&T Mail, CompuServe, and other messaging systems for which a MAPI transport driver is available. Note Microsoft only supports the IFB publishing feature when Outlook is configured for the Internet Mail Only mode.

You must complete the following steps to share free/busy information using the IFB publishing feature (for step-by-step instructions, see Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System"): 1.

Configure Outlook to publish free/busy information To publish free/busy information, you must enable the option to publish and search for free/busy information using the Internet Free/Busy service or publish free/busy information at an internal location. You can find corresponding configuration options in Outlook by clicking Tools, clicking Options, clicking Calendar Options on the Preferences tab, and then clicking Free/Busy Options. If you publish the free/busy information on an internal server, type the fully qualified path to the server in the text box that becomes available when you select the Publish at My Location option. You can specify the location in HTTP, FTP, or FILE URL format. If you are using an FPT server with Anonymous Login disabled, you must specify the user and password information in the FTP URL as follows: ftp://User:[email protected]/Usersfolder/Freebusy/<SMTP domain>/<SMTP alias>.vfb

User is the user name of the account and Password is the password associated with the account. SMTP domain corresponds to the user's SMTP domain name, and SMTP alias refers to the user's e-mail address within the SMTP domain. Free/busy files have an extension of .vfb. You should choose the file name and path to the file for publishing free/busy information carefully, so that users do not need to maintain a specific search location for each individual user. Outlook supports the %NAME% and %SERVER% substitutions in the search location. In an SMTP address, Outlook replaces %NAME% with all of the characters before the at sign (@) and replaces %SERVER% with all of the characters following the @. Because the name portion of an e-mail address is guaranteed to be unique within an SMTP domain, this way of organizing .vfb files prevents naming conflicts. Ensure that the folder structure exists before you configure the IFB publishing feature in Outlook. Figure 4.17 shows the recommended folder structure for two SMTP domains.

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 149

Figure 4.17 2.

Publishing free/busy information organized by SMTP domain

Set the global free/busy search path in Outlook If all of your users store their free/busy information on the same server, you can set the search path for this information globally for all contacts. You must specify only the fully qualified path to the location where you want to search for the free/busy information in the Search locations text box in the Free/Busy Options dialog box. If you followed the recommendations for the free/busy folder structure, you can specify the search path using the %NAME% and %SERVER% substitutions. For example, in Figure 4.17, the global search path would be as follows (the structure is similar for HTTP and FTP URLs): file://\Server01\Freebusy\%SERVER%\%NAME%.vfb

You can also set the search path specifically for each SMTP recipient, which is useful if the location of free/busy information varies by recipient. First, create a contact object for the recipient in your Contacts folder. You can then specify the path to that recipient's .vfb file in the Address text box in the Internet Free-Busy section on the Details tab. 3.

Implement an ASP.NET-based solution so that Exchange users can parse .vfb files As mentioned earlier in this chapter, Exchange users cannot access published free/busy information for SMTP recipients if mail-enabled user accounts or mail-enabled contacts exist for these recipients in Active Directory. To provide Exchange users with access to the free/busy information, you can implement an ASP.NET application published through IIS on the IFB publishing server. You can use the TreeView Web control to display the SMTP recipients organized by SMTP domains. For more information about the TreeView Web control, see "Using the TreeView IE Web Control" (http://go.microsoft.com/fwlink/?LinkId=25929).

150 Exchange Server 2003 Interoperability and Migration Guide

Migrating from a Non-Exchange Messaging System to Exchange Server 2003 This section explains how to migrate a group of users from a non-Exchange messaging system to Exchange 2003. The guidelines are recommended for most migrations, and involve extracting data from the legacy messaging system and immediately importing it into Exchange 2003. However, in some cases you might want to edit the extracted data before importing the data into Exchange 2003, as explained in Chapter 1, "Understanding Interoperability and Migration." You can use source extractors and the Exchange Migration Wizard to migrate from the following messaging systems to Exchange 2003: •

Internet mail systems that support IMAP4 The Exchange Migration Wizard supports IMAP4. For messaging connectivity, deploy an SMTP connector between Exchange 2003 and the Internet mail system. For complete procedures with detailed step-by-step instructions for migrating Internet mail users to Exchange 2003 using the Exchange Migration Wizard, see Appendix C, "Configuration Procedures for Migrating from a Non-Exchange Messaging System."

•

Microsoft Mail for PC Networks The Exchange Migration Wizard supports Microsoft Mail for PC Networks. However, a direct messaging connector is not available in Exchange Server 2003. You can use Microsoft Exchange Connector for Microsoft Mail if you are running an earlier version of Exchange in your organization, such as Exchange 2000. Connector for Microsoft Mail supports automated directory synchronization. For Exchange Server 2003 messaging connectivity, consider deploying a Microsoft Mail gateway to SMTP or a Microsoft Mail gateway to X.400. You can use the Exchange Migration Wizard to create a user list; however, the migration wizard will export Microsoft Mail for PC Networks address information, which you must replace with SMTP addresses before you import the recipients into Active Directory.

•

Microsoft Mail for AppleTalk Networks The Exchange Migration Wizard does not directly support Microsoft Mail for AppleTalk Networks or StarNine Technologies' Quarterdeck Mail. You must use the Microsoft Mail for AppleTalk source extractor to copy the data from Microsoft Mail for AppleTalk version 3.0 or later to migration files. You can then import these migration files to Exchange 2003 using the Exchange Migration Wizard.

•

Lotus cc:Mail The Exchange Migration Wizard supports the Lotus cc:Mail DB6 and DB8 formats. However, a direct messaging connector is not available in Exchange Server 2003. You can use Microsoft Exchange Connector for Lotus cc:Mail if you are running an earlier version of Exchange Server in your organization, such as Exchange 2000 Server. Connector for Lotus cc:Mail supports automated directory synchronization. For Exchange 2003 messaging connectivity, consider using the built-in SMTP feature available in Lotus cc:Mail. You can use the Exchange Migration Wizard to create a user list; however, the migration wizard will export Lotus cc:Mail address information, which you must replace with SMTP addresses before you import the recipients into Active Directory. Alternatively, you can use the Import and Export tools that are included with Lotus cc:Mail for directory import and export operations.

•

IBM PROFS, IBM OfficeVision/VM, Fischer TAO, and other PROFS-based systems The Exchange Migration Wizard does not directly support host-based messaging systems, such as IBM PROFS. You must use the PROFS and OfficeVision/VM source extractor to copy the data from PROFS to

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 151

migration files. You can then import these migration files to Exchange 2003 using the Exchange Migration Wizard. For messaging connectivity, consider using a host-based SMTP solution, such as TBS Software OfficePath/SMTP-Send (OP/SS), or an X.400 gateway. Alternatively, you can use Microsoft Exchange Connector for IBM OfficeVision/VM, if you still have a server running the Enterprise edition of Microsoft Exchange 5.5 in your organization. •

Verimation MEMO The Exchange Migration Wizard does not directly support Verimation MEMO. You must use the MEMO source extractor to copy the original MEMO documents to migration files. You can then import these migration files to Exchange 2003 using the Exchange Migration Wizard. For messaging connectivity, consider using a host-based SMTP solution, such as MEMO Integrator and MEMO SMTP Connector or MEMO/X400. Alternatively, you can use Microsoft Exchange Connector for SNADS, if you still have a server that runs the Enterprise edition of Exchange 5.5 in your organization.

•

Digital All-In-1 The Exchange Migration Wizard does not directly support Digital All-In-1. You must use the All-In-1 source extractor to copy the original documents to migration files. You can then import these migration files to Exchange 2003 using the Exchange Migration Wizard. For messaging connectivity based on SMTP or X.400, consider using Digital MAILbus 400. Important For detailed information about how to migrate from non-Exchange messaging systems using protocols other than IMAP4, consult the Exchange Migration Wizard documentation and the documentation for the source extractor that you want to use. To obtain a stand-alone source extractor for your legacy messaging system, contact Microsoft Product Support Services. For information about Product Support Services, including how to contact them, go to http://support.microsoft.com.

Preparing for a User Migration Perform the following steps to prepare the existing environment for a migration to Exchange 2003: 1.

Prepare a migration server It is recommended that you configure a dedicated migration server to run the Exchange Migration Wizard. This computer must be able to communicate with the legacy messaging system, Active Directory, and Exchange 2003. Installing Exchange System Manager through the Exchange 2003 Setup program installs the Exchange Migration Wizard on your migration server. Note It is recommended that you install multiple migration servers to distribute the workload. For example, you can use five migration servers to migrate 100 users and balance the load so that each migration server handles 20 users. Powerful hardware is not required for your migration servers. You can use standard workstations.

2.

Prepare the user mailboxes It is a good idea to run any available mailbox maintenance tools on the non-Exchange messaging system that you want to migrate to eliminate inconsistencies in the messaging data. If you discover problems with individual mailboxes, you might need to run the maintenance tools more than once to repair the messaging data. In addition to running maintenance tools, you might want to perform the following tasks: •

Delete mailboxes in the legacy messaging system for users that no longer exist in the environment.

•

Instruct users to delete old messages and calendar data to reduce the amount of data that must be migrated. Users should also empty their deleted items folders or wastebaskets.

•

Check the file system on which the messaging data resides to repair any problems on data volumes.

•

Ensure that the time on all servers across the network is consistent.

•

Delete old mail from all mail queues.

152 Exchange Server 2003 Interoperability and Migration Guide

Performing an Internet Mail Migration to Exchange 2003 You must complete the following steps to perform an Internet mail migration to Exchange 2003: 1.

Prepare an IMAP4 migration file for the Exchange Migration Wizard To migrate data from an Internet mail system to Exchange 2003, the Exchange Migration Wizard requires access to the mailbox of each user who is migrated. By default, only the owner of the mailbox has access, so you must specify each individual user name and password. You can provide this information during the migration process in a .csv file that contains information about the mailboxes being migrated, their SMTP addresses, as well as the user accounts and passwords to log on to each individual mailbox. The IMAP4 server where the mailbox resides can be specified through a fully qualified host name or IP address. Table 4.3 lists the possible fields for the IMAP4 user list file. Table 4.3

IMAP4 user list fields

Field

Description

IMAP_Mailbox

IMAP4 mailbox account name.

SMTP_Address

Exchange destination mailbox SMTP address. Alternatively, you can provide the alias of the Exchange destination mailbox. If you do not add the destination mailbox alias, the Exchange Migration Wizard migrates the mail to the mailbox with the SMTP address that you specify.

IMAP_Server

The IMAP4 server name.

Ex_Mailbox

Exchange mailbox alias. If each user does not already have a mailbox in Exchange, the wizard creates one using the IMAP4 mailbox name and the SMTP address that you specify. This is an optional field.

IMAP_Port

IMAP port. You can specify an alternate TCP/IP port for the Exchange Migration Wizard to use to bind to the IMAP server. The default IMAP port is 143. If you do not add the optional IMAP port field to the user list file, the wizard will try to connect through port 143. This is an optional field.

IMAP_SSL

You can specify whether to encrypt the transmission of each user's mailbox contents using Secure Sockets Layer (SSL). By default, if the IMAP_SSL field is not in the user list file, information is not transmitted using SSL. This is an optional field that can have the following values: •

Y, Yes, T, or True The Exchange Migration Wizard uses SSL when transmitting the contents of that mailbox.

•

N, No, F, or False The Exchange Migration Wizard does not use SSL when transmitting the contents of that mailbox.

Note If you receive errors during an IMAP4 migration, check the user list file to verify that you have specified the correct IMAP4 server name and port number.

The following is an example of a .csv file for an IMAP4 migration: IMAP_Mailbox,SMTP_Address,IMAP_Password,IMAP_Server Ted,[email protected],password,192.168.202.101 Birgit,[email protected],password,192.168.202.101

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 153

Kim,[email protected],password,192.168.202.101

If you create this file rather than using sample code, remember to include the header line, and remember that each line must have exactly four pieces of information separated from each other by a comma. If, however, your Internet mail system also supports LDAP, you can perform an LDAP directory migration as a first step to automatically create a .csv file named Imapusr.csv, which the Exchange Migration Wizard places in the migration files directory. After you edit this file to verify the account and server information, you are ready to approach the actual IMAP4 migration. Note When migrating from Internet mail systems to Exchange 2003, it is recommended that you first create a user list file, called Imapusr.csv, using the Internet Directory component of the Exchange Migration Wizard.

2.

Migrate server-based data to Exchange 2003 The next step in performing a migration from an Internet mail system to Exchange 2003 is to migrate the users and mailboxes from the Internet host to the server running Exchange 2003. You do this by running the Exchange Migration Wizard. It is often sufficient to accept the defaults in the Exchange Migration Wizard. If you have specific migration needs, you can change the following options on the Migration Information wizard page: •

Information to create mailboxes When this check box is selected, a new mailbox is created for users being migrated from the Internet host to Exchange.

•

Personal e-mail messages When this check box is selected, the user's e-mail messages that are stored on the Internet host are migrated to Exchange. You can either select All to migrate all of the user's mail, or Dated from to specify a date range of messages to migrate.

Table 4.4 lists the data elements that the Exchange Migration Wizard preserves during migration. Table 4.4

Data elements that are preserved in IMAP4 migrations

Item

In Exchange

IMAP4-compliant mail messages

MAPI or HTML messages (for Microsoft Office Outlook Web Access).

Attachments

Attachments.

Calendar information

Plain text message.

Encrypted messages

Encrypted messages. Users must move their private keys and certificates to Outlook to be able to use Outlook to read migrated encrypted mail. Alternatively, users can reconfigure the IMAP client that contains their certificates and keys so that they can read the encrypted mail from their Exchange mailboxes.

The Exchange Migration Wizard creates a mailbox-enabled Active Directory account for each user who is being migrated. All new user accounts are placed in the target organizational unit that you specify on the Container for New Windows Accounts page. If accounts already exist in Active Directory, for example because you created disabled Windows accounts for all Internet mail users through a semiautomated directory synchronization process beforehand, you must verify that the accounts are matched correctly. You can associate the accounts using the Find Existing Account option on the Windows Account Creation and Association page. You can also choose to create a new account using the Create New Account option. For new accounts, the Exchange Migration Wizard can generate a random strong password, which is stored in the Accounts.Password file in the \Program Files\Exchsrvr\Bin directory on the server running Exchange 2003.

154 Exchange Server 2003 Interoperability and Migration Guide

After migration is complete, review the application log for information about the migration progress. Look for event log messages for which the source is MSExchangeMig. You might find it helpful to configure and apply a filter in Event Viewer to list only those event log messages from the Exchange Migration Wizard. If a migration attempt ends unsuccessfully, you can delete any mailboxes and recipient objects that were created during the migration attempt from Active Directory. Perform a manual directory synchronization to bring both messaging systems back in sync. For information about troubleshooting migration problems, see Chapter 5, "Troubleshooting Interoperability and Migration Issues." 3.

Migrate local messaging data The Exchange Migration Wizard only migrates data stored on the IMAP4 server. Internet messaging clients, however, often store messaging data locally. Data stored in local archives on client computers is not migrated. To migrate local data, users must use Outlook to import the data after Exchange mailboxes have been created using the Exchange Migration Wizard. Outlook can import local messaging data from Eudora Pro and Microsoft Outlook Express. Outlook Express also provides a mail importer component for Netscape Communicator and Netscape Mail. IMAP4 users can also place message items back into their server-based mailboxes prior to migration. However, this can greatly increase the amount of data that must be migrated if large amounts of e-mail data are stored on the users' workstations. You must ensure that your Internet mail system and Exchange 2003 server have sufficient disk space to store the data. If you are concerned that migrating local data will impede your migration process, you might want to consider migrating local data only for executives and employees with specific permission. Note After migration is complete, your users can create local personal folder store (.pst) files to store the e-mail data that was previously stored in local folders on the client computer.

4.

Migrate personal address books The Exchange Migration Wizard cannot migrate personal address books from Internet mail users. Users must migrate their personal address books after they connect to Exchange 2003 using Outlook. Outlook detects and silently imports information from supported messaging clients, such as Netscape Messenger 4.0 and Outlook Express. For unsupported clients, you might be able to use an address book converted in Outlook Express before you import the data into Outlook. Outlook Express supports a number of address book formats, including Eudora Pro, LDIF, Netscape Address Book, Netscape Communicator Address Book, and .csv files. If an address book converter is not available, you might be able to export personal address books from the old messaging client into text-based files that can be converted into .csv files using a macro in Microsoft Excel, for example. The main task is to reorder the fields to match the layout required by Outlook. Outlook is able to import Contact objects from a .csv file. To determine the order of fields in a .csv file for Outlook, create a sample Contact object in Outlook and then export this contact into a .csv file using the Import and Export command on the File menu in Outlook 2003. Choose Export to a file and then select Comma Separated Values (Windows). Select the Contacts folder where you created the sample contact, and complete the export procedure. Open the resulting .csv file in Excel. You should find the list of fields in the first row. The following is a list of all header fields that Outlook recognizes: "Title","First Name","Middle Name","Last Name","Suffix","Company","Department","Job Title","Business Street","Business Street 2","Business Street 3","Business City","Business State","Business Postal Code","Business Country","Home Street","Home Street 2","Home Street 3","Home City","Home State","Home Postal Code","Home Country","Other Street","Other Street 2","Other Street 3","Other City","Other State","Other Postal Code","Other Country","Assistant's Phone","Business Fax","Business Phone","Business Phone 2","Callback","Car Phone","Company Main Phone","Home Fax","Home Phone","Home Phone 2","ISDN","Mobile Phone","Other Fax","Other

Chapter 4: Interoperating with and Migrating from Other Non-Exchange Messaging Systems 155

Phone","Pager","Primary Phone","Radio Phone","TTY/TDD Phone","Telex","Account","Anniversary","Assistant's Name","Billing Information","Birthday","Business Address PO Box","Categories","Children","Directory Server","E-mail Address","E-mail Type","E-mail Display Name","E-mail 2 Address","E-mail 2 Type","E-mail 2 Display Name","E-mail 3 Address","E-mail 3 Type","E-mail 3 Display Name","Gender","Government ID Number","Hobby","Home Address PO Box","Initials","Internet Free Busy","Keywords","Language","Location","Manager's Name","Mileage","Notes","Office Location","Organizational ID Number","Other Address PO Box","Priority","Private","Profession","Referred By","Sensitivity","Spouse","User 1","User 2","User 3","User 4","Web Page"

Note Users can re-create personal contacts, as well as personal distribution lists, in a Contacts folder in Outlook.

C H A P T E R

5

Troubleshooting Interoperability and Migration Issues

As the previous chapters illustrate, integrating Microsoft® Exchange Server 2003 into a non-Exchange environment and migrating users to Exchange 2003 is a complex undertaking that usually involves deployment and configuration of several components included in Exchange 2003, as well as non-Microsoft software. You must deploy correct versions of the software and perform configuration steps in both the legacy system and in Exchange 2003. There are many opportunities to make configuration errors that can adversely affect the interoperability and migration process. Interoperability and migration issues can be grouped according to the following categories: •

Message transfer Messages between the legacy messaging system and Exchange 2003 are lost or stuck in message queues, or result in message loops or non-delivery notifications.

•

Directory synchronization Recipient information is not synchronized between the legacy messaging system and Exchange 2003, or address lists in either system are incomplete.

•

Calendar connectivity Users in the legacy messaging system or in Exchange 2003 are not able to query each other's free/busy information when they schedule meetings.

•

Mailbox migration using the Exchange Migration Wizard The process of extracting messaging data from legacy mailboxes into migration files or importing the data into Exchange 2003 mailboxes fails.

This chapter describes issues that might arise in messaging environments that include Exchange Server 2003. You will learn how to troubleshoot messaging connectors, directory synchronization, and Microsoft Exchange Calendar Connector. This chapter also explains how to handle problems that might occur during a migration from a non-Exchange messaging system to Exchange 2003 using the Exchange Migration Wizard.

Understanding Troubleshooting in Interoperability and Migration Projects It is recommended that you adopt the following troubleshooting strategy, shown in Figure 5.1, when you troubleshoot interoperability and migration issues: 1.

Locate the issue Before you can troubleshoot an issue, you must determine its probable causes. This usually involves checking the legacy system, as well as Exchange 2003. Use a methodical approach to pinpoint the issue.

Chapter 5: Troubleshooting Interoperability and Migration Issues 157

2.

Analyze the issue Try to replicate the problem so that you can understand exactly what is happening. Change only one setting or configuration at a time so that you can keep track of the behavior before and after the change. Carefully document the changes you make. After you determine the cause of the problem, check the configuration to find out why the affected component fails.

3.

Solve the issue Devise a solution to prevent the problem from happening again. Do not apply your solution until you have carefully tested it for side effects in a test lab. For example, service packs contain many solutions for known issues, but you should not apply a service pack without first testing it on a test server.

Figure 5.1

Recommended troubleshooting approach

Troubleshooting Tools Exchange 2003 includes features and tools that can help you troubleshoot interoperability and migration issues. Microsoft Windows Server™ 2003 also includes many valuable troubleshooting tools. You can use the following standard tools to troubleshoot Exchange 2003 interoperability and migration issues. Some of these tools are grouped together in the Performance tool that is available in the Administrative Tools program group; others are included in Exchange System Manager. Which tools you use to troubleshoot a system and in which order depends on the problem you are troubleshooting. •

System Monitor System Monitor is part of the Performance tool that is included in the Administrative Tools program group. Among other things, you can use System Monitor to monitor the behavior of messaging connectors in real time. You can determine the number of messages in inbound and outbound message queues and other information, such as the total number of messages that have been transferred by a connector since the connector service was started. It is a good idea to check message queues using System Monitor, because numerous messages queuing up in a messaging connector might indicate a performance bottleneck or a malfunctioning connector component. To add performance counters for connector queues to System Monitor, start the Performance tool and then, in the toolbar, click the Add button indicated by a plus sign (+). Table 5.1 lists important performance objects that you can select from the Performance object list in the Add Counters dialog box. If you select a connector component, you can then find appropriate performance counters for message queues under Select counters from list. For example, Connector for Novell GroupWise (Performance object: MSExchangeGWC) provides counters such as Message Queued Inbound and Message Queued Outbound.

158 Exchange Server 2003 Interoperability and Migration Guide

Table 5.1

Important Exchange 2003 performance objects

Resource

Performance object

Address lists

MSExchangeAL

Directory Service Access caches

MSExchangeDSAccess Caches

Directory Service Access global counters

MSExchangeDSAccess Global Counters

Directory Service Access processes

MSExchangeDSAccess Processes

Epoxy queues and activity

Epoxy

Mailbox store

MSExchangeIS Mailbox

Public folder store

MSExchangeIS Public

Exchange store

MSExchangeIS

Connector for Lotus Notes

MSExchangeNMC

Message Transfer Agent

MSExchangeMTA

Message Transfer Agent connections

MSExchangeMTA Connections

Connector for Novell GroupWise

MSExchangeGWC

Simple Mail Transfer Protocol

SMTP Server

Exchange routing engine

SMTP Routing

•

Performance Logs and Alerts This tool is also included in the Performance tool. You can use Performance Logs and Alerts to collect data automatically from local or remote computers. Performance Logs and Alerts is similar to System Monitor in that you can define performance objects, performance counters, and object instances, as well as set sampling intervals for monitoring. You can use this tool to create reports that document system behavior over a specified period of time. These reports can be viewed in the Performance tool, or the data can be exported to a spreadsheet or database for analysis.

•

Exchange System Manager Use the Exchange System Manager tool to check the health of your bridgehead server and the state of messaging connectors. For example, you can use the Monitoring and Status tool in the Tools container in Exchange System Manager to determine which connectors and bridgehead servers are available and which are not. Select the Status container beneath Monitoring and Status to display this information. In addition, you can use the Notifications container to configure email or script notifications to alert you automatically when a critical system state is detected.

•

Message Queues You can use the Queues container object beneath a server object in Exchange System Manager to list all queues and all messages within those queues that are currently awaiting message transfer on the server. You can freeze a particular message or all messages, which prevents them from being transferred through a connector until you unfreeze the messages. You can also delete a message from a message queue (with or without sending a non-delivery report back to the originator), which might be necessary if a corrupted message is blocking other messages. Exchange 2003 supports two types of message queues: •

System queues There are three providers for system queues: SMTP (for the SMTP transport engine), X.400 (for the Exchange message transfer agent (MTA)), and MAPI (Connector for Lotus Notes and Connector for Novell GroupWise).

•

Link queues The SMTP transport engine creates link queues when there are multiple messages bound for the same destination. These queues are listed in the Queues container only when they have messages waiting to be routed. The name of the queue matches the remote delivery destination.

Chapter 5: Troubleshooting Interoperability and Migration Issues 159

•

Message Tracking Center This is another important Exchange System Manager component, which is used to track messages across an Exchange organization. You can track all kinds of messages, including system messages and regular e-mail messages that are going to or coming from a non-Exchange messaging system. For example, public folder replication messages that Exchange stores exchange with each other to synchronize public folder instances on separate servers are system messages. You can use Message Tracking Center to locate messages that have failed to arrive in your users' mailboxes, such as messages that are stuck in a connector's message queue. Note Message Tracking Center is unable to track messages within a non-Exchange messaging system. Message tracking ends (or begins, in the case of inbound messages) at the messaging connector that connects your Exchange organization to another messaging system. However, message tracking is not enabled by default. You must enable it on your Exchange servers individually or jointly in a server policy.

•

Exchange Management Pack for Microsoft Operations Manager Keeping track of issues that involve many servers across an organization can be difficult when you are using standard tools. If you are responsible for a complex organization with multiple Exchange servers, you might want to implement a centralized tool, such as Microsoft Operations Manager with the Exchange 2003 Management Pack, for monitoring and alerting, reporting, and trend analysis. The Exchange 2003 Management Pack provides preconfigured scripts, rules, and reports specific to Exchange with which you can monitor an entire Exchange organization or specific servers. The Exchange Management Pack also includes an extensive set of Microsoft Knowledge Base articles to provide you with background information and troubleshooting information. With Exchange Management Pack for Microsoft Operations Manager, you can: •

Check the system status of multiple Exchange servers from a single console

•

Create sophisticated rules to respond to system events

•

Generate custom reports

•

Handle operational tasks and obtain background information for troubleshooting

For more information about the Exchange Management Pack, see the Exchange Management Pack Technical Reference, (http://go.microsoft.com/fwlink/?LinkId=23230). •

Event Viewer Many of the internal Exchange 2003 components record events in the Event Log. An event is any occurrence in the system or in a program that might require administrator attention. Event logs can help you identify and diagnose the source of current system problems or help you predict potential issues. Table 5.2 lists various Event Viewer logs that you might find on your Exchange 2003 servers. The standard logs, Application, System, and Security, exist in all computer configurations. Others, such as the Directory Service log, are available only in specific configurations, such as on domain controllers. Table 5.2

Important Windows 2003 Event Viewer logs

Event log

Description

Application log

The Application log contains events that are logged by Exchange 2003 and other applications. Most Exchange 2003 events are logged in the application log.

160 Exchange Server 2003 Interoperability and Migration Guide

Event log

Description

System log

The System log contains events that are logged by Microsoft Windows® system components. For example, the failure of a driver or other system component to load during startup is recorded in the system log.

Security log

The Security log can record security events such as valid and invalid logon attempts, as well as events related to resource use, such as creating, opening, or deleting files. An administrator can specify what events are recorded in the security log. For example, if you enable logon auditing, attempts to log on to the system are recorded in the security log.

Directory Service log

The Directory Service log contains events from the Active Directory® directory service, such as reported connection problems between a server and the global catalog.

File Replication Service log

The File Replication Service log contains events logged by the Windows File Replication service. For example, file replication failures between domain controllers are recorded in the File Replication Service log.

Many system components and programs write events into the application event log. If you are only interested in a specific component, you can filter the events by selecting Filter from the View menu in Event Viewer. Under Event source, you can select the information source that you are interested in. The names of most Exchange 2003 event sources start with MSExchange. For example, the Exchange message transfer agent (MTA) is named MSExchangeMTA, and the event source for the internal transport engine of Exchange 2003 is MSExchangeTransport. Note If you want to increase the amount of information that an Exchange component writes to the event log, start Exchange System Manager and display the properties of the server in which you are interested. Click the Diagnostics Logging tab and then select the component of interest from the Services list. Next, select all or individual categories for this component from the Categories list. Then, under Logging Level, determine the amount of information that is written to the event log: None, Minimum, Medium, or Maximum.

•

Network Monitor Network Monitor is a useful tool for detecting and troubleshooting problems that can occur during communication between server components over the computer network. You can identify problems related to message transfer over a messaging connector or client-to-server connection, find a computer that makes a disproportionate number of protocol requests, and identify unauthorized users on your network. For example, if you are experiencing problems transferring messages over an X.400 connector, tracing the communication between the X.400 systems using Network Monitor can reveal protocol details that would not otherwise be visible. With Network Monitor, you can: •

Identify network traffic patterns and network problems

•

Capture frames (also called data packets) directly from the network

Chapter 5: Troubleshooting Interoperability and Migration Issues 161

•

Display, filter, save, and print the captured frames

For more information about Network Monitor, see the following Microsoft Knowledge Base articles: •

294818, "Frequently Asked Questions About Network Monitor" http://go.microsoft.com/fwlink/?linkid=3052&kbid=294818

•

148942, "How to Capture Network Traffic with Network Monitor" http://go.microsoft.com/fwlink/?linkid=3052&kbid=148942

•

168862, "How to Install ISO and TP4 Parser for Network Monitor" http://go.microsoft.com/fwlink/?linkid=3052&kbid=168862

Where to Get Help If you are dealing with a complex connectivity problem, you can get additional information and assistance from the following sources: •

Microsoft Knowledge Base Search or browse through the Knowledge Base to find information about the various Exchange Server 2003 components. Many Knowledge Base articles provide straightforward answers to frequently asked questions or discuss known issues. Some articles clarify which components and configurations are supported by Microsoft, and others explain how to use troubleshooting tools. You can search the Knowledge Base using keywords, header text, or full text.

•

Microsoft TechNet TechNet is a central information and community resource designed for IT professionals. The TechNet program includes technical briefings, special offers, the TechNet Web site, and an electronic newsletter, in addition to a CD subscription. TechNet offers information about Microsoft strategies and industry trends, provides "how-to" information and bug fixes for known problems, and serves as a forum for sharing information, ideas, and opinions with other Exchange specialists. The Microsoft Knowledge Base is a TechNet resource, for example.

•

Exchange-specific Web sites and newsgroups You can visit numerous Web sites and newsgroups to obtain information about Exchange Server 2003. For the latest news and articles, visit http://go.microsoft.com/fwlink/?LinkId=21277.

•

Microsoft Product Support Services If you cannot solve a problem without direct assistance from a support specialist, contact Microsoft Product Support Services online or by phone. For information about Product Support Services, including how to contact them, visit http://support.microsoft.com.

Troubleshooting Messaging Connectivity This section discusses how to identify and isolate message flow issues. Problems related to message flow fall into the following two general categories: •

Message routing problems Message routing refers to the process of directing messages to their destinations from one hop to the next. The SMTP service, with its internal transport engine, is at the core of the Exchange 2003 message transport architecture. When a message is passed to the SMTP transport engine, the routing module inside the transport engine determines the correct destination and passes the message to the next messaging component. Which messaging component the message is passed to depends on where the recipients are located, as follows:

162 Exchange Server 2003 Interoperability and Migration Guide

•

•

Local recipients For these recipients, the next messaging component is the Exchange Information Store service, which delivers the message to the recipient's mailbox.

•

Recipients on another Exchange server within the local routing group For these recipients, the next messaging component is the SMTP service to send the message to the destination server. The destination server might be the recipient's home server where the mailbox actually resides or a bridgehead server that connects the local routing group to other Exchange routing groups.

•

Recipients outside of the local Exchange 2003 organization For these recipients, the next messaging component is the SMTP service if the target messaging system is connected through an SMTP virtual server or an SMTP connector. Otherwise, the message is passed to the Exchange message transfer agent (MTA) to transfer the message. The Exchange MTA might pass the message to Connector for Lotus Notes, Connector for Novell GroupWise, or an X.400 connector.

Message transfer problems Message transfer problems are often the result of a configuration error or a malfunctioning connector component. Messages accumulating in an outbound or inbound message queue or connector store indicate message transfer problems. Exchange 2003 uses outbound message queues to pass messages to connectors. The messaging connector obtains the message, converts it to the format of the destination system, if required, and transfers the message. During the conversion process, messages are often placed temporarily in a connector store. The connector store can be located within the Exchange store or on the Exchange server's file system. For inbound traffic, the connector receives the message, converts it into Exchange format, and places it into its inbound message queue. If messages accumulate in a message queue, Exchange 2003 generates delivery status notifications at intervals to inform the sender that the message has not reached its destination yet. If the connector problem is permanent, the problem will result in a delivery failure later on, which Exchange 2003 indicates to the sender in a non-delivery report (NDR). User complaints that messages do not reach their recipients in a timely manner also indicate transfer problems. It is recommended that you monitor your bridgehead servers and messaging connectors continuously using the tools mentioned earlier in this chapter, so that you can react to message transfer problems before users start noticing that their messages are delayed.

Troubleshooting Message Routing Problems Exchange 2003 maintains routing information in the Active Directory configuration naming context. You configure the routing information by means of the address spaces and cost factors that you assign to the individual connector instances in Exchange System Manager. Address spaces are subsets of e-mail address information that are used to categorize recipients. Table 5.3 lists the various types of address spaces in Exchange 2003. Table 5.3 Standard address spaces in Exchange 2003 Address space type

Example

Applies to

NOTES

NOTES:*@*

Lotus Notes recipients.

SMTP

SMTP:*

SMTP recipients, such as recipients on the Internet.

X400

X400:c=*;

X.400 recipients. At a minimum, the country information must be specified in the form of a wildcard.

Chapter 5: Troubleshooting Interoperability and Migration Issues 163

Address space type

Example

Applies to

MS

MS:*/*/*

Microsoft Mail for PC Networks recipients.

CCMAIL

CCMAIL:* at *

Lotus cc:Mail recipients.

GWISE

GWISE:*

Novell GroupWise recipients.

Table 5.3 lists examples of most general address spaces. For example, NOTES:*@* is an address space that applies to all Lotus Notes recipients. You can also assign more detailed address spaces, such as NOTES:*@Contoso, which is useful if you want to distribute the message traffic over multiple connector instances. In general, the Exchange transport engine chooses more detailed address spaces over general address spaces. However, it is recommended that you assign the most general address space possible to include all possible recipients in the same address space. For example, you should configure NOTES:*@* if you are using only one Connector for Lotus Notes instance to connect your entire Exchange 2003 organization to a global Lotus Notes/Domino environment. You can use the WinRoute tool to view message routes and connector states when you are troubleshooting problems related to message routing in an Exchange 2003 organization. The WinRoute tool extracts link state information from Exchange 2003 and presents the information in a readable format. You can download this tool from http://go.microsoft.com/fwlink/?LinkId=25049. Note If the routing module cannot match a recipient address to a connector address space, a nondelivery report (NDR) is generated. This report indicates that the recipient name could not be resolved. The numerical error code will be either 5.0.0 (There is no route) or 5.4.0 (Host not found in DNS). For details about the information contained in NDRs, see Knowledge Base article 284204, "Delivery Status Notifications in Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204).

Troubleshooting Lotus Notes Connectivity The following are typical causes of message transfer problems to and from Lotus Notes: •

Incorrect configuration settings Ensure that you have installed and configured Connector for Lotus Notes properly. The initial installation only copies the files to the correct locations on the hard disk drive. You must configure the connector after installation and prepare the Lotus Domino server for the connector. For step-by-step instructions for configuring Lotus Notes connectivity, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality."

•

Incorrect access permissions to Lotus Notes databases The account ID that Connector for Lotus Notes uses to access the Lotus Domino server must have no password and requires the following access rights to perform message transfer: •

Mail.box The connector account needs Depositor permissions to be able to drop mail messages and to perform database maintenance operations.

•

Exchange.bad The connector account needs Manager permissions with Delete rights to be able to move badmail to this database and to run database maintenance operations.

•

Exchange.box The connector account needs Manager permissions with Delete rights to pick up mail from this database and to run database maintenance operations.

•

Names.nsf The connector account needs Editor permissions with Delete rights to perform directory synchronization.

164 Exchange Server 2003 Interoperability and Migration Guide

•

Regular Databases The connector account needs Reader permissions to convert Lotus Notes DocLinks to rich-text attachments or OLE documents.

Chapter 5: Troubleshooting Interoperability and Migration Issues 165

•

Corrupted Lotus Notes databases Database corruption in the Exchange.box database can lead to message transfer problems. To resolve these problems, run the Lotus Notes database fixup process on the Lotus Domino server using the following at a command prompt: load fixup exchange.box

Note You can also use the fixup tool to correct database corruption in the Mail.box or Exchange.bad database. Replace exchange.box in the command line with the corresponding database name.

•

No network connection to the Lotus Domino server Connector for Lotus Notes uses a Lotus Notes client to communicate with the Lotus Domino server. Communication cannot take place if an incorrect client version is used. Connector for Lotus Notes requires Lotus Notes Client release 4 or later.

•

Lotus Notes client is not included in system search path Ensure that the Lotus Notes client can make a successful connection to the target Lotus Domino server and that the correct Notes ID is assigned to that client. You will not be able to start the Lotus Notes client if it is not included in the system search path or if multiple Nnotes.dll files are within the system path. You also should verify in the Person document for the connector's Notes ID that the home server points to the correct Lotus Domino server. For Lotus Notes Client release 4.x, the default location for the Notes.ini file is the Windows directory (for example, \Winnt). If you are using Lotus Notes Client release 5 or later, the default location for the Notes.ini file is the folder in which you installed the client (that is, c:\Lotus\Notes). If you have more than one client version installed, ensure that Connector for Lotus Notes is using the correct version. You can verify which Notes.ini file is being used in the connector properties in the Notes INI file location box on the General tab.

Testing Messaging Connectivity The best way to test messaging connectivity is to send e-mail messages to an Exchange user from a Lotus Notes client. To determine which NOTES proxy address to specify for an Exchange recipient, start the Active Directory Users and Computers MMC snap-in, display the properties of the user account, and then switch to the E-mail Addresses tab. Verify that a proxy e-mail address of the type NOTES has been assigned to the user, such as Administrator/First Administrative Group/Contoso@Exchange, and then use this address to specify the recipient in your Lotus Notes client. The fact that messages are delivered from Lotus Notes to Exchange 2003 does not mean that messages are being transferred from Exchange to Lotus Notes. Ensure that message routing works in both directions. To test message transfer in the other direction, reply to the test message in Microsoft Office Outlook®, and ensure that the message is received in Lotus Notes. When you test messaging connectivity, it is a good idea to increase the level of event logging for the Connector for Lotus Notes instance in Exchange System Manager. To do this, display the properties of the bridgehead server, switch to the Diagnostics Logging tab, select LME-NOTES from the Services list, and then select Controller, Notes Interface, Transport to Exchange, Transport from Exchange, Exchange to Notes Conversion, Notes to Exchange Conversation, and Notes Directory Synchronization from the Categories list. Set the logging level to Maximum to obtain the most detailed information. Note Setting the diagnostics logging level to Maximum can cause a large number of events to be written to the application event log. As a best practice, set the size of the application and system event log to 30 megabytes (MB) and enable the option to overwrite events as needed. Remember to reapply the default setting of None after you finish testing your connector.

166 Exchange Server 2003 Interoperability and Migration Guide

Examining Message Flow Between Lotus Notes and Exchange 2003 If messages are not transferred correctly, check the individual repositories and processes involved in transferring messages. Figure 5.2 shows these repositories and processes for message transfer from Lotus Notes/Domino to Exchange 2003.

Figure 5.2 Message flow from Lotus Notes to Exchange 2003 Check the message flow from Lotus Notes to Exchange 2003 in the following order: 1.

Check the mail.box database Start the Lotus Notes client and open the mailbox for the Lotus Notes Mail Router: a.

In the File menu, point to Database, and then select Open.

b.

In the Open Database dialog box, in the Server section, enter the name of your Lotus Domino server. In the Filename section, type mail.box.

c.

Click Open.

Chapter 5: Troubleshooting Interoperability and Migration Issues 167

If your messages are queuing up in the mail.box database, verify that your Mail Router process is running on the Lotus Domino server. At the server console, type show tasks and ensure that Router is listed. If it is not listed, enter load router and verify that the Router process starts normally and begins transferring messages from the mail.box database. Note Lotus Domino must be configured to recognize the Exchange organization as a foreign domain. The Lotus Notes Mail Router must deposit messages for the Exchange foreign domain into the exchange.box database on the Lotus Notes server. If you need assistance with troubleshooting Lotus Notes Mail Router issues, contact IBM Lotus.

2.

Check the exchange.box database Repeat the steps you performed in the Lotus Notes client to open the exchange.box database (enter exchange.box instead of mail.box in the Open Database dialog box). If your messages are queuing up in the exchange.box database, verify that your Connector for Lotus Notes is started and that the LSNTSMEX process is operational. Lsntsmex.exe polls exchange.box according to your connector configuration, obtains the messages from the exchange.box database using the Lotus Notes client API, converts them from Lotus Notes format to Exchange format, and then places them in the connector's READYIN folder in the Exchange store. Note If Connector for Lotus Notes is unable to transfer messages from the exchange.box database into the READYIN folder, check the application event log and look for events for which the source is MSExchangeNOTES and for which the Category is either Notes Interface or Notes to Exchange Conversion. Many problems at this stage relate to communication from a Lotus Notes client to a Lotus Domino server. A typical application event log error related to communication problems between the Lotus Notes client and the Lotus Domino server is "Unable to connect to the Notes Server".

3.

Check the READYIN folder Examine this folder when you open the Queues container under the bridgehead server object in Exchange System Manager. Select READYIN in the details pane, click Find Messages, and then, in the Find Messages dialog box, click Find Now to list all messages in this folder under Search Results. If messages are stuck in this folder, you might be experiencing a problem related to the LSMEXIN process. Lsmexin.exe performs address translation and Active Directory lookup for the intended recipients of a message. The LSMEXIN process also moves the messages from the READYIN folder to the connector MTS-IN folder. Note If Connector for Lotus Notes is unable to transfer messages from the READYIN folder into the MTS-IN folder, check the application event log and look for events for which the source is MSExchangeNOTES and for which the Category is Transport to Exchange. Also look for events for which the category is Notes Interface to verify that the LSMEXIN process started successfully.

4.

Check the connector's MTS-IN folder To examine this folder in Exchange System Manager, in the Queues container, select MTS-IN, and then click Find Messages. If you find messages in the MTS-IN folder, these messages are waiting for the store driver to move them to the Exchange MTA. Ensure that the Exchange MTA is started (in the Services tool, check for the Microsoft Exchange MTA Stacks service). More information about message transfer through the Exchange MTA is included later in this section.

5.

Check the SMTP Mailbox Store queue The Exchange MTA puts the message in its SMTP Mailbox Store queue to get it transferred to the SMTP transport engine. (You can view this queue in Exchange System Manager. In the Queues container, select SMTP Mailbox Store and then click Find Messages.) The store driver picks up the message from this queue and transfers it to the SMTP service. The SMTP transport engine receives the message, categorizes it, and then routes it to the target recipients. More information about message transfer through the SMTP service is included later in this section.

168 Exchange Server 2003 Interoperability and Migration Guide

The message queues and connector processes differ when messages are transferred in the opposite direction. Figure 5.3 shows the queues and processes for Exchange 2003 to Lotus Notes/Domino message transfer.

Figure 5.3 Message flow from Exchange 2003 to Lotus Notes It is recommended that you check the Exchange 2003 to Lotus Notes message flow in the following order: 1.

Check the Outbox folder in your Outlook client When you send a message to another user, the mailbox store receives the message from your client and then the store driver passes the message to the SMTP service for routing and transfer. If messages do not leave your Outbox, check that the SMTP service on your mailbox server is running. Note Messages that are stuck in the Outbox might also indicate a problem with the mailbox store. To check a database for consistency, you can use the command eseutil /mh . You must dismount the mailbox store before you run the eseutil tool.

2.

Check the internal message queues of the SMTP transport engine The Queues container in Exchange System Manager contains several SMTP message queues. These queues contain messages during various stages in the routing process. For more information about SMTP message queues, see the section "Troubleshooting SMTP Connectivity" later in this chapter. For Lotus Notes recipients, the routing proceeds as follows: a.

The message is passed to the Advanced Queuing component in the SMTP service, where it is placed in a pre-categorization queue.

Chapter 5: Troubleshooting Interoperability and Migration Issues 169

3.

b.

The categorizer resolves both recipient and sender addresses, and expands any mail-enabled groups. For Lotus Notes recipients, the message is then placed in a post-categorization queue. The categorizer is discussed in more detail in Chapter 4, "Interoperating with and Migrating from Other Non-Exchange Messaging Systems."

c.

Because the message is for a remote recipient, the advanced queuing engine moves the message to the pre-routing queue.

d.

The routing engine picks up the message from the pre-routing queue and determines the routes for delivering the message. It assigns the message to the Connector for Lotus Notes instance that handles the address type of the recipient (that is, NOTES). Because the Exchange MTA is responsible for messaging connectors to non-Exchange messaging systems, such as Connector for Lotus Notes, the routing engine passes the message to the Exchange MTA.

Check the Connector for Lotus Notes message queue The Exchange MTA places the message into an internal message queue, which the MTA maintains separately from the Exchange store on the file system (\Program Files\Exchsrvr\Mtadata). You can only view this queue in Exchange System Manager when the Microsoft Exchange MTA Stacks service is running. In the Queues container, select Connector for Lotus Notes, and then click Find Messages. Note If you suspect that a corrupted message is blocking the Connector for Lotus Notes message queue, use the MTA Check tool to check the MTA message queues for consistency. You can also use the MTA Check tool to repair the MTA message queues, if necessary. To download this tool, visit http://go.microsoft.com/fwlink/?LinkId=25924. For more information about troubleshooting Exchange MTA problems, see the section "Troubleshooting X.400 Connectivity" later in this chapter

4.

Check the MTS-OUT folder of Connector for Lotus Notes The Exchange MTA wraps the message in a message transfer envelope (MTE) and places it in the MTS-OUT folder for delivery through Connector for Lotus Notes. Note that the Exchange MTA continues to deliver messages to the MTS-OUT folder even if the Connector for Lotus Notes service is paused or stopped. This can cause a backlog of messages to collect in the delivery queue. In the Queues container in Exchange System Manager, select MTSOUT, and then click Find Messages to examine the MTS-OUT message queue. If messages accumulate in the MTS-OUT folder, you might be experiencing a problem related to the LSMEXOUT process. Lsmexout.exe picks up messages from the MTS-OUT folder, accesses Active Directory to perform address translation for the target recipients, and then places the messages into the READYOUT folder. Note If Connector for Lotus Notes is unable to transfer messages from the MTS-OUT folder into the READYOUT folder, check the application event log and look for events for which the source is MSExchangeNOTES and the category information is Transport from Exchange. Also look for events with a Category of Notes Interface to verify that the LSMEXOUT process started successfully.

5.

Check the READYOUT folder The LSMEXNTS process (Lsmexnts.exe) obtains the message from the READYOUT folder, converts it into Lotus Notes format, and deposits it into the database of the Lotus Notes Mail Router (mail.box). In the Queues container, select READYOUT, and then click Find Messages. If messages are accumulating in the READYOUT folder, this might indicate an LSMEXNTS problem. Note If Connector for Lotus Notes is unable to transfer messages from the READYOUT folder to the mail.box database, check the application event log and look for events for which the source is MSExchangeNOTES and the category information is Notes Interface or Exchange to

170 Exchange Server 2003 Interoperability and Migration Guide

Notes Conversion. As mentioned earlier, problems at this stage often relate to the Lotus Notes client.

6.

Check the mail.box database Start the Lotus Notes client and open the mailbox for the Lotus Notes Mail Router, as explained earlier in this section. If messages are queuing up in this database, verify that your Mail Router is processing messages.

Troubleshooting Novell GroupWise Connectivity The following are typical causes of message transfer problems to and from Novell GroupWise: •

Incorrect configuration settings Ensure that you have installed and configured Connector for Novell GroupWise properly. The initial installation only copies the files to the correct locations on the hard disk drive. You must configure the connector after installation and prepare the Novell GroupWise environment for the connector. For step-by-step instructions for configuring Novell GroupWise connectivity, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

•

No network connection to the server running Novell GroupWise API Gateway Connector for Novell GroupWise uses a Novell GroupWise API gateway to communicate with the Novell GroupWise environment. Communication cannot take place if Connector for Novell GroupWise cannot access the API gateway directories on the Novell NetWare server. If you use Gateway and Client Services for NetWare (GSNW) to integrate Exchange 2003 into the Novell NetWare environment, verify the configuration of the NWLink IPX/SPX/NetBIOS Compatible Transport Protocol and ensure that the Exchange server is able to locate the Novell NetWare server through the Service Advertisement Protocol (SAP). If you use Novell NetWare Client for Windows instead of GSNW, verify that the client can connect to the server over TCP/IP and logs on to the correct context in the Novell Directory Service (NDS).

•

Incorrect access permissions to the Novell GroupWise API Gateway directory The Novell NetWare account that you specify for API Gateway access in the properties of the Connector for Novell GroupWise must be a member of a special group called NTGATEWAY, which you must create using Novell NetWare Administrator (see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality"). The connector's NetWare account requires permissions to create, read, write, and delete files in the API gateway directories. You can use Microsoft Windows Explorer to check whether access permissions are effective by creating, reading, writing, and deleting a text file in the API Gateway directory manually when you log on with the connector's NetWare account.

•

The Exchange domain in Novell GroupWise is corrupted or was set up as "External GroupWise" Ensure that the Exchange organization is created as an "External Foreign" domain in the GroupWise administrator program. If you do not designate the organization as an External Foreign domain, message flow from Novell GroupWise to Exchange will fail, although directory synchronization between Exchange 2003 and Novell GroupWise might work. If you suspect that the Exchange foreign domain is corrupted in Novell GroupWise, perform the following steps to delete and re-create the domain for the Exchange organization: a.

In the GroupWise administrator program (Link Configuration tool), unlink the existing External Foreign domain for the Exchange organization.

b.

Delete the existing External Foreign domain.

c.

Create a new External Foreign domain for the Exchange organization.

d.

In the Link Configuration utility, link the External Foreign domain to the API gateway.

Chapter 5: Troubleshooting Interoperability and Migration Issues 171

e.

Perform a full reload to synchronize Active Directory and the Novell GroupWise directory.

172 Exchange Server 2003 Interoperability and Migration Guide

•

An incorrect link configuration is specified for the Exchange domain If the link configuration for the Exchange domain is incorrect, the Novell GroupWise MTA will not route messages to the Novell GroupWise API Gateway and message flow from Novell GroupWise to Exchange will fail. Use the GroupWise administrator program (Link Configuration) to link the External Foreign domain for the Exchange organization to the correct API gateway.

•

Another program or process is concurrently accessing the files in the API Gateway directory If files are being locked because an antivirus program or another process is accessing the files in the API gateway directory at the same time as Connector for Novell GroupWise, access problems might be reported in the application event log although the messages are delivered correctly. Connector for Novell GroupWise moves messages from Exchange to the API_IN and ATT_IN folders in the API gateway and then renames the files by adding the extension ".api." Over a slow network connection or during periods of high usage, the GroupWise MTA might pick up the messages from the API_IN and ATT_IN folders before Connector for Novell GroupWise has a chance to rename the files.

Testing Messaging Connectivity The best way to test messaging connectivity between Novell GroupWise and Exchange 2003 is to send e-mail messages to an Exchange user from a Novell GroupWise client. To determine which GWISE proxy address to specify for an Exchange recipient, start Active Directory Users and Computers, display the properties of the user account, and then switch to the E-mail Addresses tab. Verify that a proxy e-mail address of type GWISE has been assigned to the user, such as Exchange.First Administrative Group.Administrator, and then use this address to specify the recipient in your Novell GroupWise client. Remember to ensure that the message routing works in both directions. The fact that messages are being delivered from Novell GroupWise to Exchange 2003 does not mean that messages are being transferred from Exchange 2003 to Novell GroupWise. To test message transfer in the other direction, reply to the test message in Outlook, and ensure that the message is received in Novell GroupWise. When you test messaging connectivity, it is a good idea to increase the level of event logging for the Connector for Novell GroupWise service in Exchange System Manager. To do this, display the properties of the bridgehead server, switch to the Diagnostics Logging tab, select LME-GWISE from the Services list, and then select Controller, GroupWise Interface, Transport to Exchange, Transport from Exchange, and Exchange to GroupWise Conversion, as well as GroupWise to Exchange Conversion and GroupWise Router from the Categories list. Set the logging level to Maximum to obtain the most detailed information. You might also want to set the logging level for categories of the MSExchangeGWRtr service (Connection, General, and Housekeeping) to obtain detailed information about these processes in the application event log. Note Setting the diagnostics logging level to Maximum can cause a large number of events to be written to the application event log. As a best practice, set the size of the application and system event log to 30 MB, and enable the option to overwrite events as needed. Remember to reapply the default setting of None after you finish testing your connector.

Chapter 5: Troubleshooting Interoperability and Migration Issues 173

Examining Message Flow Between Novell GroupWise and Exchange 2003 If messages are not transferred correctly, check the individual repositories and processes involved in transferring messages between Novell GroupWise and Exchange 2003. Figure 5.4 shows the individual stages in message transfer from Novell GroupWise to Exchange 2003.

Figure 5.4 Message flow from Novell GroupWise to Exchange 2003 Check the message flow from Novell GroupWise to Exchange 2003 in the following order: 1.

Check the \WPCSOUT folder in the Novell GroupWise API Gateway directory The \WPCSOUT folder is the Novell GroupWise MTA outbound queue where outgoing messages are placed when you send a message from Novell GroupWise to an Exchange 2003 recipient. The Novell GroupWise MTA

174 Exchange Server 2003 Interoperability and Migration Guide

transfers the message to the API gateway that is linked to your Exchange foreign domain. If messages are queuing up in the \WPCSOUT folder, verify the status of your API gateway instance running on the Novell NetWare server. 2.

Check the \API_OUT and \ATT_OUT folders in the Novell GroupWise API Gateway directory The API gateway converts outbound messages into keyword-based text files and places them in these folders, as follows: •

\API_OUT Message header with an .api file name extension

•

\ATT_OUT Message body and attachments with a .bdy file name extension

If files queue up in these folders, the Microsoft Exchange Router for Novell GroupWise (Gwrouter.exe) might not be running or might be having access problems. Check the application event log for events for which the source is MSExchangeGWRtr. For example, if the path to the API gateway directory is incorrect in the connector configuration, the following description is logged: The following directory could not be found: \server01\api\API_OUT\. In Exchange System Manager, display the properties of Connector for Novell GroupWise, and verify the path and account settings. 3.

Check the subdirectories under \Program Files\Exchsrvr\Conndata\GWRouter The Router for Novell GroupWise moves the header and body files into subdirectories in the connector store, as follows: •

\GW2MEX Message header with an .api file name extension

•

\GW2MEXA Message body and attachments with a .bdy file name extension The GW2MEX process picks up the files from the connector store. Gw2mex.exe converts header and body files to messages in Exchange format and places them into the READYIN folder. Note If you find .bdy files in the \GW2MEXA folder without corresponding header files in the \GW2MEX folder, check the \Badfiles folder in the same location. You can retry a failed transfer by moving the header files back into the \GW2MEX folder. However, remember that header files for messages from Exchange to Novell GroupWise are also placed into the \Badfiles folder if the Router for Novell GroupWise cannot transfer the messages into the API gateway. If such files are incorrectly moved to the \GW2MEX folder, Gw2mex.exe will move these files back to the \Badfiles folder, because the correct place for them is the \MEX2GW folder. There is more information about message transfer from Exchange to Novell GroupWise later in this section.

4.

Check the READYIN folder of Connector for Novell GroupWise To examine this folder, in Exchange System Manager, open the Queues container under the bridgehead server object in Exchange System Manager. Select READYIN in the details pane, click Find Messages, and then, in the Find Messages dialog box, click Find Now to list all messages in this folder under Search Results. If messages are stuck in this folder, you might be experiencing a problem related to the LSMEXIN process. Lsmexin.exe performs address translation and Active Directory lookup for the intended recipients of a message. The LSMEXIN process also moves the messages from the READYIN folder to the connector's MTS-IN folder. Note If Connector for Novell GroupWise is unable to transfer messages from the READYIN folder into the MTS-IN folder, check the application event log and look for events for which the source is MSExchangeGWISE and the Category information is Transport to Exchange. Also look for events for which the Category is GroupWise Interface to verify that the LSMEXIN process started successfully.

5.

Check the connector's MTS-IN folder To examine this folder, in Exchange System Manager, in the Queues container, select MTS-IN, and then click Find Messages. If you find messages in the MTS-IN folder, these messages are waiting for the store driver to move them to the Exchange MTA. Ensure that

Chapter 5: Troubleshooting Interoperability and Migration Issues 175

the Exchange MTA is started (in the Services tool, check the Microsoft Exchange MTA Stacks service). There is more information about message transfer through the Exchange MTA later in this chapter. 6.

Check the SMTP Mailbox Store queue The Exchange MTA puts the message to be transferred in its SMTP Mailbox Store queue. To view this queue, in Exchange System Manager, in the Queues container, select SMTP Mailbox Store, and then click Find Messages. The store driver picks up the message from this queue and transfers it to the SMTP service. The SMTP transport engine receives the message, categorizes it, and then routes it to the target recipients. There is more information about message transfer through the SMTP service later in this section.

The message queues and connector processes differ when messages are transferred in the opposite direction. Figure 5.5 shows these queues and processes for Exchange 2003 to Novell GroupWise message transfer.

Figure 5.5 Message flow from Exchange 2003 to Novell GroupWise Check the Exchange 2003 to Novell GroupWise message flow in the following order:

176 Exchange Server 2003 Interoperability and Migration Guide

1.

Check the Outbox folder in your Outlook client When you send a message to another user, the mailbox store receives the message from your client and then the store driver passes the message to the SMTP service for routing and transfer. If messages do not leave your Outbox, check that the SMTP service on your mailbox server is running.

2.

Check the internal message queues of the SMTP transport engine There are several SMTP message queues in the Queues container in Exchange System Manager. These queues contain messages at various stages in the routing process. For more information about SMTP message queues, see the section "Troubleshooting SMTP Connectivity" later in this chapter. For Novell GroupWise recipients, the routing proceeds as follows:

3.

a.

The message is passed to the Advanced Queuing component in the SMTP service, where it is placed in a pre-categorization queue.

b.

The categorizer resolves both recipient and sender addresses, and expands any mail-enabled groups. For Novell GroupWise recipients, the message is then placed in a post-categorization queue. The categorizer is also discussed in Chapter 4, "Interoperating with and Migrating from Other NonExchange Messaging Systems."

c.

Because the message is for a remote recipient, the advanced queuing engine moves the message to the pre-routing queue.

d.

The routing engine picks up the message from the pre-routing queue and determines the routes for delivering the message. It assigns the message to the Connector for Novell GroupWise instance that handles the address type of the recipient (that is, GWISE). Because the Exchange MTA is responsible for messaging connectors to non-Exchange messaging systems, such as Connector for Novell GroupWise, the routing engine passes the message to the Exchange MTA.

Check the Connector for Novell GroupWise message queue The Exchange MTA places the message into an internal message queue, which the MTA maintains separately from the Exchange store on the file system (\Program Files\Exchsrvr\Mtadata). You can only view this queue in Exchange System Manager when the Microsoft Exchange MTA Stacks service is running. In the Queues container, select Connector for Novell GroupWise, and then click Find Messages. Note If you suspect that a corrupted message is blocking the Connector for Novell GroupWise message queue, use the MTA Check tool to check the MTA message queues for consistency. You can also use the MTA Check tool to repair the MTA message queues, if necessary. To download this tool, visit http://go.microsoft.com/fwlink/?LinkId=25924 . For more information about troubleshooting Exchange MTA problems, see the section "Troubleshooting X.400 Connectivity" later in this chapter.

4.

Check the MTS-OUT folder of Connector for Novell GroupWise The Exchange MTA wraps the message in a message transfer envelope (MTE) and places it in the MTS-OUT folder for delivery through Connector for Novell GroupWise. Note that the Exchange MTA continues to deliver messages to the MTS-OUT folder even if the Connector for Novell GroupWise service is paused or stopped. This can cause a backlog of messages to collect in the delivery queue. In the Queues container in Exchange System Manager, select MTS-OUT, and then click Find Messages to examine this message queue. If messages accumulate in the MTS-OUT folder, you might be experiencing a problem related to the LSMEXOUT process. Lsmexout.exe picks up messages from the MTS-OUT folder, accesses Active Directory to perform address translation for the target recipients, and then places the messages into the READYOUT folder. Note If Connector for Novell GroupWise is unable to transfer messages from the MTS-OUT folder into the READYOUT folder, check the application event log and look for events for which the source is MSExchangeGWISE and the Category information is Transport from Exchange. Also

Chapter 5: Troubleshooting Interoperability and Migration Issues 177

look for events for which the Category is GroupWise Interface to verify that the LSMEXOUT process started successfully.

5.

Check the READYOUT folder Messages that have been placed in the READYOUT folder await processing through the MEX2GW process. Mex2gw.exe obtains the messages from the READYOUT folder, converts them into Novell GroupWise format, and places them into the connector store. If messages are accumulating in the READYOUT folder, this might indicate a MEX2GW problem. In the Queues container, select READYOUT, and then click Find Messages to list all messages that are currently in this queue.

6.

Check the subdirectories under \Program Files\Exchsrvr\Conndata\GWRouter The MEX2GW process places the converted header and body files into the following subdirectories in the connector store: •

\MEX2GW Message header with an .api file name extension

•

\ MEX2GWA Message body and attachments with a .bdy file name extension

The Router for Novell GroupWise process picks up these files from the connector store and places them into corresponding folders in the API Gateway directory. 7.

Check the \API_IN and \ATT_IN folders in the Novell GroupWise API Gateway directory The API gateway receives the inbound messages as keyword-based text files and places them in the following folders: •

\API_IN Message header with an .api file name extension

•

\ATT_IN Message body and attachments with a .bdy file name extension

If files are queuing up in these folders, the Novell GroupWise API Gateway might not be running on the Novell NetWare server. 8.

Check the \WPCSIN folder in the Novell GroupWise API Gateway directory The \WPCSIN folder in the Novell GroupWise API Gateway directory is the Novell GroupWise MTA inbound queue. The Novell GroupWise MTA transfers the message to the Novell GroupWise domain and post office where the Novell GroupWise user resides. If messages are queuing up in the \WPCSIN folder, verify that the Novell GroupWise MTA for your API gateway is running on the Novell NetWare 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 keywordbased 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).

178 Exchange Server 2003 Interoperability and Migration Guide

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. Warning 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: 1.

Start the Registry Editor (Regedt32.exe) and open the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LME-GWISE\Parameters

2.

On the Edit menu, click New, and then click DWORD Value to add the following value: Value Name: Archive Value:1

3.

Restart the Exchange Router for Novell GroupWise service to create the \Archive directory in the \Programfiles\Exchsrvr\Conndata\Gwrouter directory. The \Archive directory will have the following subdirectories: \Dirsync, \Freebusy, \Gw2mex, \Gw2mexa, \Mex2gw, \Mex2gwa, \Togwise. Note When you activate the archive feature, you must manually purge archives to avoid filling up the disk drive. It is recommended that you activate the archive feature only during troubleshooting sessions.

Chapter 5: Troubleshooting Interoperability and Migration Issues 179

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: •

Connection attempt is timing out If the Exchange MTA cannot establish a connection to the remote MTA, verify that the address information for the remote MTA is correct. When communicating over X.25, ensure that the EICON card can successfully establish a connection. When communicating over TCP/IP, make sure that name resolution works and use the Ping tool to probe the IP address of the remote host. If pinging the IP address of the remote MTA fails, you might need to resolve a general network issue. If pinging the IP address of the remote MTA succeeds, verify that the outgoing and incoming Open Systems Interconnect (OSI) address information (that is, T, S, and P Selector) is correct. You specify the OSI address information in the MTA transport stack or on the X.400 connector's Stack tab when you click the OSI Address button. The T-Selector (PSAP), S-Selector (SSAP), and P-Selector (PSAP) can be entered in either hexadecimal format or text. Verify that only the required fields are specified and that the fields are specified in the correct format. If multiple X.400 connectors use the same transport stack to connect to foreign X.400 MTAs, verify that each of the connectors has a unique value specified for the TSelector. The T-Selector specifies the entry point to the transport layer of the X.400 protocol and, as such, should be unique. Note The P-Selector is not supported in 1984 mode. The S-Selector is not supported in 1988 X.410 mode. The T-Selector is the most uniformly used throughout X.400 MTAs.

•

Connection attempt is refused X.400 systems refuse to communicate with other MTAs when security information is mismatched. The security information consists of the remote MTA name and password, as well as the local MTA name and password. The remote and the local password fields are case-sensitive and must be an exact match with the information submitted by the MTA that attempts to connect. You specify the remote MTA name and password on the connector's General tab. The Exchange MTA uses the name of the Exchange server for the local MTA name. If this name must be changed, or if you need to specify a password for the local MTA, switch to the connector's Override tab and click Modify.

•

Connection is dropped Sudden disconnects during message transfer suggest that X.400 protocol parameters on the local and the remote MTAs do not match. Verify the settings on the connector's Advanced tab. Ensure that the correct conformance year (1984 or 1988) is selected according to the capabilities of the remote MTA, and clear the Allow Exchange contents check box if the remote MTA is not an Exchange system. The Allow Exchange contents option causes the Exchange MTA to send nonX.400 body parts over the X.400 connector, which non-Exchange systems might identify as a protocol violation. Note You must configure the X.400 connector to match the conformance year of the remote MTA, and the option to allow Exchange contents should always be disabled when connecting to a non-Exchange MTA. Furthermore, the typical non-Exchange MTA requires that the Two-Way Alternate option be disabled. Allow BP-15 (in addition to BP-14) is available when sending to a 1984 X.410 or a 1988 X.400 MTA.

Also check the Reliable Transfer Service (RTS) values of your connector on the Override tab when you click the Additional Values button. Ensure that the Checkpoint size, Recovery timeout, and Window

180 Exchange Server 2003 Interoperability and Migration Guide

Size settings match the configuration of the remote MTA. For example, the window size determines how many data packets the local MTA can send unacknowledged. A window size that is too large for the remote MTA will cause the remote MTA to drop the connection as soon as the window of the remote MTA is overrun. If the window size is too small, the connection will time out when the local MTA has sent all allowed packets and is waiting for an acknowledgment from the remote MTA (which never arrives, because the remote MTA is expecting more data packets). Work with the system administrator of the remote MTA to determine which RTS values to use. •

Transport Protocol Data Unit (TPDU) size is too large Some X.400 systems, such as Lotus SoftSwitch EMX, require support for TPDU sizes of 2 kilobytes (KB). To configure the Exchange MTA to support this TPDU size, start the Windows Registry Editor and change the value for the REG_DWORD registry key named Supports 2K TPDU from 0 to 1. This registry key is found in the following location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Paramet ers

Warning 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.

•

Messages are not being transferred in one direction Message transfer in one direction can function correctly although messages in the other direction are not getting through. This can be caused by mismatched RTS values or by name resolution problems. For example, if the local and remote MTAs are configured with Fully Qualified Domain Names (FQDNs), rather than IP addresses or NetBIOS names, the local MTA might be unable to resolve the IP address of the incoming connection to a fully qualified domain name (FQDN) to identify the X.400 connector responsible for the connection. The local MTA attempts to resolve the IP address to a host name. It first searches the local HOSTS file. If unsuccessful, the MTA then queries Domain Name System (DNS) for the host name. If this reverse lookup also fails, the connection attempt is terminated. Note For the reverse lookup to be successful, the DNS server must have a Pointer (PTR) record in DNS for the remote MTA that maps its IP address to its FQDN.

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.

Chapter 5: Troubleshooting Interoperability and Migration Issues 181

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.

182 Exchange Server 2003 Interoperability and Migration Guide

Figure 5.8 Message flow to an X.400 remote MTA Check the Exchange 2003 to X.400 message flow in the following order: 1.

Check the Outbox folder in your Outlook client When you send a message to another user, the mailbox store receives the message from your client and then the store driver passes the message to the SMTP service for routing and transfer. If messages do not leave your Outbox, check that the SMTP service on your mailbox server is running.

2.

Check the internal message queues of the SMTP transport engine The Queues container in Exchange System Manager contains several SMTP message queues. These queues contain messages during various stages in the routing process. For more information about SMTP message queues, see the section "Troubleshooting SMTP Connectivity" later in this chapter. For X.400 recipients, the routing proceeds as follows: a.

The message is passed to the Advanced Queuing component in the SMTP service, where it is placed in a pre-categorization queue.

b.

The categorizer resolves both recipient and sender addresses, and expands any mail-enabled groups. For X.400 recipients, the message is then placed in a post-categorization queue. The categorizer is also discussed in Chapter 4, "Interoperating with and Migrating from Other Non-Exchange Messaging Systems."

c.

Because the message is for a remote recipient, the advanced queuing engine moves the message to the pre-routing queue.

d.

The routing engine picks up the message from the pre-routing queue and determines the routes for delivering the message. It assigns the message to the X.400 connector instance that handles the address type of the recipient (that is, X.400). Because the Exchange MTA is responsible for X.400 connectors, the routing engine passes the message to the Exchange MTA.

Chapter 5: Troubleshooting Interoperability and Migration Issues 183

3.

Check the Messages Waiting To Be Routed queue of the Exchange MTA This queue contains messages that are waiting to be routed by the Exchange MTA. If messages remain in this queue for an extended period, a problem with the Exchange MTA might be indicated.

4.

Check the message queue of the X.400 connector When the routing engine passes the message to the Exchange MTA, the MTA places the message in an internal message queue, which the MTA maintains separately from the Exchange store on the file system (\Program Files\Exchsrvr\Mtadata). You can only view the queue of the X.400 connector in Exchange System Manager when the Microsoft Exchange MTA Stacks service is running. The name of the queue in the Queues container corresponds to the name that you assigned the connector during its initial creation (in the Name text box on the General tab). Note If you suspect that a corrupted message is blocking the X.400 connector message queue, use the MTA Check tool to check the MTA message queues for consistency. You can also use the MTA Check tool to repair the MTA message queues, if necessary. To download this tool, visit http://go.microsoft.com/fwlink/?LinkId=25924

5.

Check the application event log and other protocol logs to examine the communication between the Exchange MTA and the remote MTA Exchange 2003 does not run separate connector services for X.400 connectors. Instead, the Exchange MTA uses the connector configuration objects to determine the protocol parameters to use for message transfer. It is the Exchange MTA itself that communicates with the remote MTA. There are four different logs that you can use to examine X.400 communication: a.

Application Event Log By default, the Exchange MTA only logs a minimum of information in the application event log. You can increase the level of event logging for the Exchange MTA in Exchange System Manager when you display the properties of the bridgehead server and switch to the Diagnostics Logging tab. Under Services, select MSExchangeMTA, and under Categories, select the various categories that belong to the MTA, such as X.400 Service. Set the logging level to Maximum to obtain the most detailed information. Remember that there is no service specific to an X.400 connector. All logging relates directly to Exchange MTA activities. Note Setting the diagnostics logging level to Maximum can cause a large number of events to be written to the application event log. As a best practice, set the size of the application and system event log to 30 MB, and enable the option to overwrite events as needed. Remember to reapply the default setting of None after you finish connector testing.

b.

EV0.log This is a text file that the Exchange MTA can write to in addition to the application event log. This log includes the information that is displayed in Event Viewer. It is in text file format so that you can view the events conveniently from a word processor. To enable this log file, you must set a registry parameter for the Exchange MTA. Change the value of the REG_DWORD parameter named Text Event Log from 0 (the default) to 1. You must restart the Microsoft Exchange MTA Stacks service for the change to take effect. The Exchange MTA creates the EV0.log file in the \Program Files\Exchsrvr\Mtadata directory. The Text Event Log parameter is found in the following location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \MSExchangeMTA\Parameters

Warning 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.

184 Exchange Server 2003 Interoperability and Migration Guide

c.

AP0.log The APO.log file is generated when you set the diagnostics logging level for the Interface and Interoperability categories to Maximum. This log file contains information about how the local MTA and the remote MTA are establishing connections and sending data. This information is useful if you must examine protocol data units exchanged between the MTAs. This file resides in the \Program Files\Exchsrvr\Mtadata directory.

d.

BF0.log The BF0.log file is generated when the X400 Service and APDU categories are set to a diagnostics logging level of Medium or Maximum. This log file contains a binary dump of messages that have been sent and received by the Exchange MTA.

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: 1.

Check the Messages Waiting To Be Routed queue of the Exchange MTA After the Exchange MTA receives a message from a remote MTA, it must communicate with Active Directory to determine the message's destination. Because the message is for an Exchange user, the Exchange MTA puts the message in its SMTP Mailbox Store queue. To view this queue in Exchange System Manager, in the Queues container, select Messages Waiting To Be Routed, and then click Find Messages.

2.

Check the SMTP Mailbox Store queue The Exchange store driver picks up the message from this queue and transfers it to the SMTP service. The SMTP transport engine receives the message, categorizes it, and then routes it to the target recipients. For more information about message transfer through the SMTP service, see the following section, "Troubleshooting SMTP Connectivity."

3.

Check the application event log and other protocol logs to examine the communication between the Exchange MTA and the remote MTA Information about how to check these logs was presented earlier in this section.

Chapter 5: Troubleshooting Interoperability and Migration Issues 185

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: a.

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.

b.

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 c.

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.

186 Exchange Server 2003 Interoperability and Migration Guide

•

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 [email protected], and fourthcoffee.com is not identified as an inbound address space, messages from the Internet addressed to [email protected] 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).

Chapter 5: Troubleshooting Interoperability and Migration Issues 187

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: •

SMTP protocol service Handles SMTP communication with remote SMTP hosts and clients. This service implements the SMTP protocol commands that Exchange 2003 supports.

•

Store driver Allows the SMTP service to communicate with the Exchange store to save messages that are passing through the SMTP service. The store driver also handles the delivery of messages to local recipients.

•

Advanced queuing engine Provides queue management and logic for message delivery, routing, and relay.

•

Categorizer Provides categorization services for inbound and outbound messages, such as distribution list expansion using Lightweight Directory Access Protocol (LDAP) and Active Directory.

•

Routing engine Provides the routing logic required to pass outbound messages to the correct messaging connector.

•

Queue manager Manages link queues, which are used to store messages that are waiting for transfer to the next remote destination.

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

188 Exchange Server 2003 Interoperability and Migration Guide

Figure 5.11 Message flow through the SMTP transport engine of an Exchange 2003 server Check the SMTP message flow in the following order: 1.

Check the SMTP log When you enable SMTP logging, as mentioned earlier in this chapter, verify that messages from a remote host are transferred successfully to the local SMTP protocol service, or that messages from the local SMTP protocol service are transferred successfully to a remote host. The following is a sample log listing that shows the results of the Telnet communication discussed earlier: #Software: Microsoft Internet Information Services 6.0 #Version: 1.0 #Date: 2003-11-30 22:33:03

Chapter 5: Troubleshooting Interoperability and Migration Issues 189

#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes csbytes time-taken cs-version cs-host cs(User-Agent) cs(Cookie) cs(Referer) 2003-11-30 22:33:03 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 HELO - - 250 0 50 4 10 SMTP - - - 2003-11-30 22:34:05 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 MAIL - +FROM:<[email protected]> 250 0 41 28 40 SMTP - - - 2003-11-30 22:35:03 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 RCPT - +TO: 250 0 38 35 10 SMTP - - - 2003-11-30 22:37:42 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 DATA - <[email protected]> 250 0 133 30 134223 SMTP - - - 2003-11-30 22:38:16 192.168.202.223 - SMTPSVC1 SERVER01 192.168.202.199 0 QUIT - - 240 331987 69 4 10 SMTP - - - -

2.

Check the Messages Pending Submission queue In Exchange System Manager, in the Queues container, select Messages Pending Submission, and then click Find Messages. When the SMTP protocol service accepts and acknowledges a message, it places the message in this queue. The Messages Pending Submission queue is also called the pre-submission queue, because messages in this queue have not been processed by the categorizer yet. The pre-submission queue is the entry point into the advanced queuing engine. Note If messages constantly accumulate in the pre-submission queue, this might indicate a performance problem. Occasional peaks in CPU performance can cause messages to appear in this queue intermittently. Frequently, problems with event sinks (for example, custom SMTP processing code for antivirus screening and for disclaimers) cause messages to accumulate in this queue.

3.

Check the Messages Awaiting Directory Lookup queue The advanced queuing engine places the message from the pre-submission queue into this queue so that the categorizer can process it. The Messages Awaiting Directory Lookup queue is also called the pre-categorization queue, because it is a throttling queue for the categorizer. The Messages Awaiting Directory Lookup queue contains messages while the categorizer resolves the sender and recipient information against Active Directory, expands distribution lists, checks restrictions, applies per sender and per recipient limits, and so on. Messages can accumulate in the pre-categorization queue if the categorizer cannot process the messages. The categorizer might not be able to access the global catalog to access recipient information, or the global catalog lookup might be performed slowly. On front-end servers, messages also remain in the Messages Awaiting Directory Lookup queue if you disable the Exchange store. It is recommended that you keep the Exchange Information Store service running on front-end servers to process messages successfully. If you want to obtain information about categorizer processing, increase the level of event logging for the MSExchangeDSAccess and MSExchangeTransport services. Set the logging level for all categories to Maximum to obtain most detailed information. Note Setting the diagnostics logging level to Maximum can cause a large number of events to be written to the application event log. As a best practice, set the size of the application and system event log to 30 MB, and enable the option to overwrite events as needed. Remember to reapply the default setting of None after you finish connector testing.

4.

Check the Local Delivery queue When the recipient's mailbox resides on the local Exchange 2003 server, the message categorizer marks the recipient as local by setting a per-recipient property that

190 Exchange Server 2003 Interoperability and Migration Guide

indicates the destination server according to the recipient's homeMDB attribute, which points to the private store where the recipient's mailbox resides. (At this point, the messages are in the postcategorization queue.) For local recipients, routing is skipped, and the advanced queuing engine transfers the messages to the Local Delivery queue, from which the Exchange store driver obtains them for local delivery to an Exchange mailbox. Messages accumulate in this queue if the Exchange Information Store service is not accepting messages or has a performance problem. To obtain detailed information in the application event log about why messages are accumulating in the Local Delivery queue, you can enable diagnostics logging for the MSExchangeIS service and for the MSExchangeTransport service. 5.

Check the Messages Waiting To Be Routed queue This queue holds messages for remote delivery. The advanced queuing engine transfers messages for non-local recipients from the post-categorization queue into this queue, which is also called the pre-routing queue. The advanced queuing engine then calls the routing engine to move the messages to their respective link queues. Messages might accumulate in the pre-routing queue if routing problems exist. If messages accumulate in the pre-routing queue, increase the diagnostics logging level for the MSExchangeTransport service for the Routing category to obtain additional information.

6.

Check the remote delivery (link) queues Link queues are dynamic in nature and are managed by the queue manager component. The name of the queue matches the remote delivery destination. If the queue is in a retry state (that is, failed connection attempts occurred), use Telnet.exe to try to connect to the destination host, as explained earlier in this section. To immediately retry sending the messages that are queued, restart the virtual SMTP server.

7.

Check the Messages With An Unreachable Destination queue Messages in this queue cannot reach their final destination server. For example, Exchange cannot determine a route or a connector to the final destination, or all available routes or connectors are labeled as down. Check the routing configuration in your Exchange 2003 organization to ensure that at least one connector to the destination is available. To retry sending the messages that are queued, restart the virtual SMTP server.

8.

Check the Messages Queued For Deferred Delivery queue This queue contains messages that are queued for later delivery. When this option is set, the Messages Queued for Deferred Delivery queue includes messages that were sent by older versions of Microsoft Outlook, such as Microsoft Outlook 2000. Newer versions of Outlook queue these types of messages in the Exchange store. Messages remain in the Messages Queued For Deferred Delivery queue until their scheduled delivery time. Other reasons why messages can end up in this queue include:

9.

•

A message is sent to a user's mailbox while the mailbox is being moved.

•

The user does not yet have a mailbox, and no master account security ID (SID) exists for the user. For further information, see Knowledge Base article 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316047).

•

SMTP message routing is configured in a way that causes a message to loop. SMTP moves looping messages to this queue, so you can correct the problem without messages immediately returning an NDR. Moving messages to the Messages Queued For Deferred Delivery queue also helps to prevent a performance impact to the server resources.

Check the DSN Messages Pending Submission queue This queue contains delivery status notifications (DSNs) that are waiting to be rendered by Exchange. For example, NDRs are delivery status notifications. Messages can accumulate in the DSN Messages Pending Submission queue under the following conditions: •

The Information Store service is unavailable or is not running.

•

A private store is not mounted.

•

Issues exist with the IMAIL Exchange store component. IMAIL is the component that performs message conversion.

Chapter 5: Troubleshooting Interoperability and Migration Issues 191

To obtain detailed information in the application event log about why messages are queuing up in the DSN Messages Pending Submission queue, increase diagnostics logging for all categories of the MSExchangeIS service. 10. Check the Failed Message Retry queue This queue contains messages that failed a queue submission. Messages can fail a queue submission for several reasons, and the failure can occur before any other processing has been done. If messages are corrupted or system resources are low, messages appear in this queue. If messages appear in the Failed Message Retry queue, review your server configuration to determine whether you have non-Microsoft programs or event sinks installed, such as virus scanners, that can interfere with message queuing. If the computer responds slowly, use Windows Task Manager to identify processes that use too many system resources. Restarting the Internet Information Services (IIS) Admin service might provide temporary relief until you can determine the root cause of the problem. By default, messages in the Failed Message Retry queue are reprocessed every 60 minutes.

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: •

The messaging connector is unable to read or write recipient information in Active Directory When you configure directory synchronization with Lotus Notes or Novell GroupWise, you must specify export and import containers for the recipient objects. The messaging connector requires the following access permissions: •

Import Container The computer account of the Exchange server that is running the messaging connector must be granted the Create All Child Objects and Delete All Child Objects permissions to create, modify, or delete recipients in this container. The computer account also requires the special permissions List Contents, Read All Properties, and Write All Properties.

•

Export Containers The computer account of the Exchange server that is running the messaging connector must be granted the Read permission to read the recipient objects in the selected container. The computer account also requires the special permissions List Contents, Read All Properties, and Read Permissions. Note When you configure Import and Export containers in Exchange System Manager, you will be prompted to assign the computer account the required permissions automatically. To verify how permissions are assigned, start Active Directory Users and Computers, rightclick the target container, select Properties, and then switch to the Security tab. Click Advanced, and then double-click the computer account (for example, SERVER01$ (CONTOSO\SERVER01$)).

•

The messaging connector is unable to communicate with the non-Exchange messaging system to export or import recipient information Directory synchronization requires a functioning connector configuration. In addition, you must ensure that the connector has the permissions required to access and update directory information in the non-Exchange messaging system. Check the following:

192 Exchange Server 2003 Interoperability and Migration Guide

•

Directory synchronization with Lotus Notes You must grant the connector ID that Connector for Lotus Notes uses to communicate with Lotus Domino editor access to the Lotus Domino directories that you want to synchronize. For step-by-step instructions for how to configure permissions for the directory of a Lotus Domino domain, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality."

•

Directory synchronization with Novell GroupWise When you configure the Novell GroupWise API Gateway using the GroupWise administrator program, you must specify the directory synchronization option in the optional gateway settings. Ensure that you set the Directory Sync/Exchange option to Exchange so that directory information can be exchanged between Novell GroupWise and Exchange 2003 through the API gateway. For step-by-step instructions for how to configure optional gateway settings, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

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.

Chapter 5: Troubleshooting Interoperability and Migration Issues 193

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.

194 Exchange Server 2003 Interoperability and Migration Guide

Table 5.4 MIF files for directory synchronization Directory synchronization

File name

Example

Active Directory to Lotus Notes

Dxanotes.txt

Load A FULLNAME:Administrator MAILDOMAIN:Exchange COMPANY: DEPARTMENT: FIRSTNAME: LASTNAME:Administrator LOCATION: SHORTNAME:Administrator UNID:DBC07527-91C1F649-8427525F-902428E2 DN:CN=Administrator,CN=Users,DC=contoso,DC=co m USNCreated:8194 Initials: Title: Phone: MobilePhn: Fax: Resource: CALDOM:Exchange MAILSRV: EndOfBuffer

Chapter 5: Troubleshooting Interoperability and Migration Issues 195

Directory synchronization

File name

Example

Active Directory to Novell GroupWise

Dxagwise.txt

Load A DOMAIN: POSTOFFICE: OBJECT: LASTNAME: FIRSTNAME:Administrator DESCRIP:Administrator ACCOUNTID: TITLE: DEPARTMENT: PHONE: FAX: GWADDR:Exchange.First Administrative Group.Administrator EXCHANGEID:Microsoft Exchange Connector for Novell GroupWise EndOfBuffer

Lotus Notes or Novell GroupWise to Active Directory

Dxamex.txt

Load U DN:admin TA:GWISE:CONTOSO_DOM.CONTOSO_PO.admin ALIAS:admin NAME:admin FULLNAME:admin FIRSTNAME: Initials: LASTNAME:admin GWISEADDR:CONTOSO_DOM.CONTOSO_PO.admin UNID:3d39133c-9085ae59-5a332abf-7ded4de3 COMPANY: DEPARTMENT: TITLE: OFFICE: PHONE: FAX: MOBILEPHN: USNCREATED: EndOfBuffer

Note If you want to examine the communication between the DXAMEX process and Active Directory,

196 Exchange Server 2003 Interoperability and Migration Guide

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=

Chapter 5: Troubleshooting Interoperability and Migration Issues 197

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.

198 Exchange Server 2003 Interoperability and Migration Guide

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 The users do not receive an indication that free/busy information might not include the most recent updates or that more up-to-date information could be obtained with a subsequent query.

Chapter 5: Troubleshooting Interoperability and Migration Issues 199

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: •

Recipient objects for non-Exchange users are not in Active Directory The requirements for Calendar Connector are similar to those for Connector for Lotus Notes and Connector for Novell GroupWise. These connectors must be installed in the same administrative group as Calendar Connector and should be configured before Calendar Connector. It is important that directory synchronization between Active Directory and the partner directory works. For detailed step-by-step procedures for configuring Calendar Connector in a Lotus Notes environment, see Appendix A, "Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality." For detailed step-by-step procedures for configuring Calendar Connector in a Novell GroupWise organization, see Appendix B, "Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality."

200 Exchange Server 2003 Interoperability and Migration Guide

•

Calendar Connector is unable to access the SCHEDULE+ FREE BUSY folder You must install Calendar Connector on an Exchange server that contains a replica of the free/busy system folder for the administrative group. To check whether an Exchange server contains a replica of the free/busy system folder for the administrative group, in Exchange System Manager, open the Folders container, rightclick Public Folders, and then select View System Folders. Free/busy folders are named according to their administrative group and reside in the SCHEDULE+ FREE BUSY container. Display the properties of the system folder for your local administrative group, and switch to the Replication tab. Ensure that the public store of the Exchange server that is running Calendar Connector is listed in the list of stores. Also ensure that Calendar Connector has permissions to read and create items in the free/busy system folder. To do this, switch to the Permissions tab and click Client Permissions. In the Client Permissions dialog box, verify that the Default account is assigned the Editor role. Note You can verify that Calendar Connector is able to access the free/busy system folder when you start Calendar Connector in console mode. Ensure that the Calendar Connector service is not running, and then double-click Calcon.exe, which resides in the \Program Files\Exchsrvr\Bin directory. If Calendar Connector is able to access the free/busy system folder in console mode, the following message will appear: The Calendar Connector has logged onto the "Schedule+ Free Busy Information - first administrative group" system folder on SERVER01 to submit calendar query responses. To stop Calendar Connector, press CTRL+BREAK.

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: 1.

NOTESCAL receives the free/busy query from MAPICAL and passes it to the Lotus Notes Schedule Manager task.

2.

The Schedule Manager task retrieves the information for local users from the busytime.nsf database. For users on downstream Lotus Domino servers, Schedule Manager communicates with the Lotus Notes Calendar Connector task that is also running on the Lotus Domino server to locate the free/busy information.

3.

The Lotus Notes Calendar Connector task determines the domain of the target user and reads the Calendar Server Name field from the domain document. Calendar Connector then communicates with the remote calendar server to perform the free/busy query.

4.

The Lotus Notes Calendar Connector task returns the information to the Schedule Manager task.

5.

The Schedule Manager task returns the information to NOTESCAL.

6.

NOTESCAL passes the information to MAPICAL, which updates the Lotus Notes user's free/busy record in the system folder.

7.

Exchange 2003 returns the information to the Outlook user.

Chapter 5: Troubleshooting Interoperability and Migration Issues 201

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

The Lotus Notes client passes the free/busy query to the Schedule Manager task.

2.

The Schedule Manager task determines that the request is for a non-local user and passes it to the Calendar Connector task.

3.

The Calendar Connector task reads the Person document for the Exchange user and determines that the user is in a foreign domain. The Calendar Connector task checks the Calendar System field in the Foreign Domain document for the Exchange 2003 organization. The Calendar System field identifies the name of the add-in program that handles the free/busy lookups on the Lotus Domino server, the Exchange Calendar Connector add-in (ExCalCon).

4.

The Calendar Connector task passes the free/busy request to ExCalCon.

5.

ExCalCon passes the request to the NOTESCAL component, which processes the request and communicates with MAPICAL to obtain the free/busy information for the Exchange user from the free/busy system folder.

6.

NOTESCAL passes the response back to ExCalCon, which in turn passes the information to the Calendar Connector task.

7.

The Calendar Connector task passes the data to Schedule Manager.

8.

Schedule Manager delivers the free/busy information to the Lotus Notes user. 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: •

Unable to connect to the target Lotus Domino server Calendar Connector only supports x86-based Lotus Domino servers running on Microsoft Windows NT® 4.0, Windows 2000, or Windows Server 2003. Also, you must ensure that the name of the Lotus Domino server is the same as the name of the server running Windows. The Lotus Notes client requirements are the same as for Connector for Lotus Notes. Ensure that you are using Lotus Notes release 4.6 or later and that the Lotus Notes client directory is in the system search path.

•

ExCalCon is not running You must install and run ExCalCon (Excalcon.exe) on the Lotus Domino server so that Lotus Notes users can query the free/busy information of Exchange users. By default, ExCalCon must be started manually using the load excalcon server01 exchange.box command each time the Lotus Domino server restarts. It is recommended that you automate the startup by updating the notes.ini file on the Lotus Domino server. To do this, edit the ServerTasks= line and append the command excalcon server01 exchange.box.

•

Foreign domain document for the Exchange organization is not updated It is important that you identify the Lotus Domino server that is running ExCalCon in the foreign domain document for your Exchange organization. In the foreign domain document, switch to the Calendar Information tab and specify the calendar server name as well as a calendar system name in the Calendar system text box (for example, exchange.box).

•

Calendar Connector cannot route requests to non-adjacent Lotus Notes domains In smaller Lotus Notes networks, or in hub and spoke topologies in which all domains are adjacent to the connected domain, a single Calendar Connector instance with a direct connection to one Lotus Domino server can handle all free/busy communication. The Lotus Notes Calendar Connector task handles this communication. Lotus Notes domains that are downstream from the domain that hosts the bridgehead

202 Exchange Server 2003 Interoperability and Migration Guide

server must have a foreign domain document that matches the bridgehead server domain. However, free/busy querying is not supported to Notes domains that are not adjacent to the domain connected to the Calendar Connector. To work around this limitation, install multiple instances of Calendar Connector.

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: 1.

Stop the Lotus Domino server.

2.

Edit the Notes.ini file for the Lotus Domino server. By default, this file resides in the \Lotus\Domino directory.

3.

Add the following line to the end of the Notes.ini file: debug_sched_all=1

4.

Save the Notes.ini file and restart the Lotus Domino server.

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: 1.

The MAPICAL component identifies a Novell GroupWise user in a free/busy query and passes the request to the GWISECAL component.

2.

The GWISECAL component translates the request into a SEARCH-type keyword-based text file and places it into the \Program Files\Exchsrvr\Conndata\GWRouter\ToGwise directory. Note that the message originator is the Microsoft Exchange System Attendant. The message is addressed to the Novell GroupWise user for whom Calendar Connector requests the free/busy information. The following is an example of a SEARCH-type request:

Chapter 5: Troubleshooting Interoperability and Migration Issues 203

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-

3.

The Router for Novell GroupWise obtains the message from the \ToGwise directory and places it into the API_IN directory of the API gateway.

4.

The API gateway processes the message according to the MSG-TYPE keyword and places it into the WPCSIN directory for the Novell GroupWise MTA.

5.

The Novell GroupWise MTA routes the message to the home post office of the GroupWise user and passes it to the appropriate Novell GroupWise Post Office Agent (POA).

6.

The Novell GroupWise POA processes the request and returns the resulting free/busy information to the GroupWise MTA in the form of a SEARCH message.

7.

The GroupWise MTA transfers the message into the WPCSOUT directory in the API Gateway directory and the API gateway transfers the message into the API_OUT directory.

204 Exchange Server 2003 Interoperability and Migration Guide

8.

The Router for Novell GroupWise picks up the SEARCH message from the API_OUT directory and places it according to the MSG-TYPE keyword into the \Program Files\Exchsrvr\Conndata\GWRouter\FreeBusy directory. The following is an example of a response to a free/busy query: 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-

9.

The GWISECAL component retrieves the message and translates it into Exchange format. GWISECAL then passes the data to the MAPICAL component.

10. MAPICAL updates the free/busy record for the Novell GroupWise user in the free/busy system folder, and Exchange 2003 returns the information to the requesting Outlook user. The following processes are involved when performing free/busy lookups from Novell GroupWise: 1.

A Novell GroupWise user performs a free/busy search for an Exchange user. The Novell GroupWise client generates a SEARCH message, which the Novell GroupWise system transfers to the API gateway.

2.

The API gateway transfers the SEARCH message from the WPCSOUT directory into the API_OUT directory, where the Router for Novell GroupWise picks it up and places it according to the MSG-TYPE keyword into the \Program Files\Exchsrvr\Conndata\GWRouter\FreeBusy directory. The message is addressed to the Exchange user for whom the Novell GroupWise user requests free/busy information. The structure of the message is similar to the one generated by the GWISECAL component for queries from Exchange users.

3.

The GWISECAL component obtains the SEARCH message from the \FreeBusy directory, translates it into Exchange format, and then passes the request to the MAPICAL component.

Chapter 5: Troubleshooting Interoperability and Migration Issues 205

4.

MAPICAL processes the free/busy query and returns the requested information to the GWISECAL component.

5.

The GWISECAL component translates the request into a SEARCH-type response and places it into the \Program Files\Exchsrvr\Conndata\GWRouter\ToGwise directory. The structure of the message is similar to the one generated by the Novell GroupWise system for a response to queries from Exchange users.

6.

The Router for Novell GroupWise obtains the message from the \ToGwise directory and places it into the API_IN directory of the API gateway. The Novell GroupWise system routes the response to the user who issued the free/busy query. 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: •

Free/busy request might cause the Novell NetWare server to stop responding If you send a free/busy request to a nonexistent Novell GroupWise domain or nonexistent post office through the Novell API gateway, the Novell NetWare server might stop responding. This is caused by a Novell GroupWise and Novell GroupWise API Gateway bug related to handling non-delivery reports. When the GroupWise MTA receives a free/busy request that is not valid through the API gateway, the GroupWise MTA responds with a mail-based NDR. The API gateway picks up the mail NDR and attempts to match it with the original free/busy request. The following error message is then displayed: Message does not contain Orig-Msg-ID property. The API gateway goes into an unstable state, and when the next free/busy request is received, the API gateway causes the server to stop responding.

•

Routing probe messages are not received When you start Calendar Connector, the GWISECAL component places a test message into the connector store to ensure that the Microsoft Exchange Router for Novell GroupWise service and the API gateway are running and can communicate with each other to transfer the free/busy requests between Novell GroupWise and Exchange 2003. You might have to troubleshoot Connector for Novell GroupWise and the API Gateway, as explained earlier in this chapter, to ensure that message transfer works. The following is a probe message request: 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;

206 Exchange Server 2003 Interoperability and Migration Guide

-END-

The Novell GroupWise system responds to this message with the following answer: 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-

When GWISECAL receives the answer, Calendar Connector has successfully verified connectivity. •

Unable to find requestor in the directory As illustrated earlier in this section, System Attendant is the originator of all free/busy SEARCH messages from Exchange 2003 to Novell GroupWise. Therefore, it is critical to assign System Attendant a proper proxy e-mail address. When connecting to Novell GroupWise, the type must be GWISE. Ensure that you enable the generation of proxy addresses for your Exchange users in the default recipient policy. The Recipient Update Service will then assign System Attendant the required addresses during the next update cycle.

Chapter 5: Troubleshooting Interoperability and Migration Issues 207

You can verify the proxy addresses of the System Attendant service using the ADSI Edit snap-in. Start ADSI Edit, connect to the configuration naming context of a domain controller, and then browse to the following object: CN=Microsoft System Attendant,CN=Your Server Name,CN=Servers,CN=Your Administrative Group,CN=Administrative Groups,CN=Your Organization Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Your Domain,DC=com

Warning Use ADSI Edit at your own risk and do not change any values. If you modify the attributes of Active Directory objects incorrectly, you can cause serious problems. These problems might require you to reinstall both Active Directory and the Exchange 2003 organization. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved.

Right-click System Attendant, click Properties, and then, in the Select which Properties to View box, select Both. In the Select a Property to view box, locate the proxyAddresses attribute, and then verify that the required proxy address is present.

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: 1.

Extracting messaging data and recipient information from the source messaging system into temporary migration files You can take a number of steps to increase your chances of a complete and successful migration. Reducing the amount of data to be migrated from the external system before beginning migration is an excellent strategy. Old files can be purged from the foreign system, and users can be asked to empty their mailboxes and calendars of outdated data. You can also configure the Exchange Migration Wizard to select only data from a more recent time period and only from active user accounts.

2.

Importing the messaging data from temporary migration files into an Exchange mailbox store and importing recipient information into Active Directory For optimum performance, move the migration files to the hard disk drive of the computer running the Exchange Migration Wizard. If errors occur during the import of migration files, the Exchange Migration Wizard logs errors to the application event log and import might stop. If import continues, the error is written to a recovery file in the Temp directory.

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:

208 Exchange Server 2003 Interoperability and Migration Guide

•

Insufficient access rights for the migration account For the Exchange Migration Wizard to successfully extract messaging data from user mailboxes, the migration account that you use to access the source system must be granted appropriate access rights. For example, GroupWise users must grant all appropriate proxy access rights to the GroupWise migration account and the account must be local to the post office that you are migrating. A similar requirement exists in Lotus Notes. Some messaging systems, such as Microsoft Mail for PC Networks, grant the post office administrator full access to all mailboxes.

•

The Exchange Migration Wizard stops responding during data extraction The Exchange Migration Wizard uses non-Microsoft software components to communicate with the source system. For example, you must have a Novell GroupWise client installed on the local computer when migrating Novell GroupWise users. When migrating from Lotus Notes, a Lotus Notes client must be installed. Ensure that you use the proper versions of the software, and include the client directory in the system search path.

•

Source mailboxes are corrupted Corrupted items in source mailboxes can cause the Exchange Migration Wizard to report problems during the extraction process. It is recommended that you check the source mailboxes using the database tools provided with the source messaging system prior to starting the Exchange Migration Wizard. For example, when you are migrating from Novell GroupWise, run the GroupWise messaging database repair tool, GroupWise Check (GWCheck), available from Novell. When migrating from Lotus Notes, run the Lotus Notes database fixup process on the Lotus Domino server.

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: •

Insufficient access permissions To successfully import messaging data and recipient information into an Exchange 2003 organization, 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.

•

The DLL Mmfmig32.dll cannot be found You might encounter this problem if you install Microsoft Office XP or Outlook 2002 on the computer that you use to run the Exchange Migration Wizard. Office XP or Outlook 2002 might delete the correct Mmfmig32.dll file and copy an earlier version to the computer. To work around this problem, use one of the following procedures:

•

•

Install Outlook before you install the Exchange Migration Wizard. This ensures that the Mmfmig32.dll file is placed in the Program Files\Exchsrvr\bin folder, which is required for the Exchange Migration Wizard to function correctly.

•

Before you install Outlook on the computer, copy or move the Mmfmig32.dll file from the Winnt\System32 folder to a temporary location on the server. After installation, copy or move the Mmfmig32.dll file that you moved from the temporary location back to the Winnt\System32 folder.

•

Copy the Mmfmig32.dll file from the Program Files\Common Files\System\Mapi\1033 folder to the Program Files\Exchsrvr\bin folder.

Data inconsistencies in migration files To import data into Exchange 2003, the Exchange Migration Wizard reads the packaging list file that is created during data extraction to determine which migration files to process. The following is an example of a packaging list file: ! CodePage 1252 ! HeaderLine Filename,Filetype Directory.PRI,Primary

Chapter 5: Troubleshooting Interoperability and Migration Issues 209

00000001.PRI,Primary 00000001.SEC,Secondary 00000002.PRI,Primary 00000002.SEC,Secondary

Every pair of primary (.pri) and secondary (.sec) files corresponds to a user who is being migrated. If a migration cycle fails because the Exchange Migration Wizard cannot process a user, you can edit the packaging list file to exclude the primary and secondary files for that user from the migration process. You can also edit the primary file to detect and correct any problems. Both the packing list and the primary files are comma-separated values (.csv) files. The following is an example of a primary file for a Novell GroupWise user: ! Migration Type MAILMESSAGE,GWise:CONTOSO_DOM.CONTOSO_PO.admin,admin ! HeaderLine Folder,Sender,To,Cc,Bcc,Subject,Send-Date,ReceivedDate,Priority,Unread,Unsent,Body,Level,Position Inbox,,,,,,,,,,,,0,0 Inbox,Exchange Test[GWISE:Exchange.First Administrative Group.Administrator],NGWAPI,,,API Gateway Test,20031119172100,20031119172100,0,FALSE,FALSE,#00000001.SEC(66),0,0 Inbox,Ted Bremer[GWISE:CONTOSO_DOM.CONTOSO_PO.Ted],admin[GWISE:CONTOSO_DOM.CONTOSO_P O.admin]; Administrator[GWISE:Exchange.First Administrative Group.Administrator],,,This is a message,20031119210624,20031119210624,0,TRUE,FALSE,#00000001.SEC(532),0,0 Inbox,,,,,,,,,,,,0,0 Inbox,,,,,,,,,,,,0,0 Documents,,,,,,,,,,,,0,0 Work In Progress,,,,,,,,,,,,0,0 Cabinet,,,,,,,,,,,,0,0 Sent Items,admin,Exchange.First Administrative Group.Administrator[GWISE:Exchange.First Administrative Group.Administrator],,,API Test Message,20031119172104,20031119172104,0,FALSE,FALSE,#00000001.SEC(717),0,0 Sent Items,admin,Ted Bremer[GWISE:CONTOSO_DOM.CONTOSO_PO.Ted]; Administrator[GWISE:Exchange.First Administrative Group.Administrator],,,Re: This is a message,20031119210701,20031119210701,0,FALSE,FALSE,#00000001.SEC(967),0,0 Sent Items,,,,,,,,,,,,0,0 Inbox,GroupWise,,,,Migrated Calendar Information,,,0,TRUE,FALSE,#00000001.SEC(1235),0,0

Note Do not edit secondary files. These files contain the raw data and checksums. Adding or removing even a single character from the secondary file can cause errors when you later import the data.

Appendixes

A P P E N D I X

A

Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality

This appendix contains detailed step-by-step instructions for the following: •

Connecting Microsoft® Exchange Server 2003 to a Lotus Notes release 5 environment.

•

Performing directory synchronization.

•

Integrating calendar information.

•

Migrating mailboxes from Lotus Notes to Exchange 2003. Note With the release of Microsoft Exchange Server 2003 Service Pack 1 (SP1), Microsoft Exchange Connector for Lotus Notes, Microsoft Exchange Calendar Connector, and the Exchange Migration Wizard support Lotus Domino release 6 or later. However, the procedures in this appendix are intended for Lotus Domino release 5.0.10, which is the recommended version for Exchange 2003 components.

Preparing the Lotus Domino Environment Before you connect Exchange 2003 to Lotus Notes, you must complete the following procedures on the server running Lotus Domino: 1.

Create a Lotus Notes user ID for Connector for Lotus Notes.

2.

Create the Lotus Domino databases for routing mail to Exchange. Note Although this step is optional (Connector for Lotus Notes can create these databases automatically for you), understanding the steps will help you check the configuration for accurate assignment of settings and permissions.

3.

Prevent the new user ID from being synchronized to the Active Directory® directory service.

4.

Grant Depositor access to the server mailbox.

5.

Grant Editor access to the Lotus Domino directory.

212 Exchange Server 2003 Interoperability and Migration Guide

6.

Grant Reader access to other Lotus Domino databases.

7.

Identify Exchange as a foreign domain in the Lotus Notes environment.

The following procedures outline how to accomplish these tasks.

Prerequisites Ensure that the server running Lotus Domino meets the following prerequisites: •

The server is running Lotus Domino release 4.6 or 5.x

•

The server is not configured as the inbound Simple Mail Transfer Protocol (SMTP) mail gateway to the Internet Important If a server running Lotus Domino is configured as the inbound SMTP mail gateway for your organization, the addresses for SMTP messages sent to Exchange users from the Internet will be corrupted because all messages sent to Exchange through Connector for Lotus Notes are appended with the Lotus Domino domain name. To avoid this problem, configure Exchange, not Lotus Domino, as the inbound SMTP mail gateway for messages inbound from the Internet. For more information about this issue, see Microsoft Knowledge Base article 255160, "XFOR: SMTP Messages from Lotus Notes SMTPMTA to Exchange 2000 Append @NotesDomain to the Sender's Address" (http://go.microsoft.com/fwlink/?LinkID=3052&kbid=255160).

To create a Lotus Notes release 5 user ID 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

Click People, point to People, and then click Register.

3.

If the Choose Certifier ID dialog box is displayed, select the certifier ID file cert.id, which is typically located in your Lotus Domino Data directory, and then click Open.

4.

In the Enter Password text box, type the password for the Lotus Domino certifier ID that you want to use to register this user ID, and then click OK.

5.

If a Domino Administrator dialog box displays a warning that the certifier ID contains no recovery information, click Yes to continue displaying this warning in the future.

6.

In the Register Person – New Entry dialog box: a.

Select the Advanced check box.

b.

In the First name text box, type Exchange.

c.

In the Last name text box, type Connector. Note You can use a different name if you want to.

7.

Leave the Password text box blank. Using a blank password allows Connector for Lotus Notes to run unattended when accessing its databases on the server running Lotus Domino. Note If you must specify a password, remember to add this password to the connector configuration. For more information about the configuration of Connector for Lotus Notes, see "Installing and Configuring Connector for Lotus Notes" later in this appendix.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 213

8.

In the left pane, click ID Info.

9.

In the ID Info dialog box: a.

Clear the In Domino directory check box. This is necessary because the password of this user ID is set to blank.

b.

Select the In file check box. This creates an ID file (filename.id) that Connector for Lotus Notes uses to connect to Lotus Domino.

c.

Click Set ID File, and then type the path and filename for the new ID file (for example, D:\lotus\notes\exchconn). You use this file later to configure Lotus Notes on the Exchange server that runs Connector for Lotus Notes. You might want to copy this file to a floppy disk or a shared folder on a file server so that you can access it later.

d.

Click Save.

Figure A.1

Configuring ID Info

10. In the left pane, click Mail, and then, from the Mail system list, select None. 11. Click Add person, and then click Register. 12. In the Domino Administrator dialog box that informs you that the user was registered successfully, click OK. 13. After the user is registered, click Done.

To create the connector mailbox 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

Click File, and then click Open Server.

214 Exchange Server 2003 Interoperability and Migration Guide

3.

In the Select a server to administer dialog box, in the Server text box, type the name of your Lotus Domino Server, including the certifier information (for example, server01/contoso). Click OK.

4.

On the Files tab, click File, point to Database, and then click New.

5.

In the New Database dialog box: a.

From the Server list, select the server running Lotus Domino.

b.

In the Title text box, type a name for the new database. For example, type Exchange Connector Database.

c.

In the File Name text box, type a name for the new database. For example, type exchange.box. You specify this name later when you configure the foreign domain document and Connector for Lotus Notes.

d.

Click the Template Server option, and then, from the Server list, select the server running Lotus Domino. Click OK.

e.

Select the Show advanced templates check box.

f.

From the scroll box, below the Template Server option, select Mail Router Mailbox (R5), and then click OK.

6.

The new mailbox is created. To close the About Mail Router Mailbox message, click File, and then click Close.

7.

Open the connector database: a.

Click File, point to database, and then click Open.

b.

From the Server list, select the server running Lotus Domino.

c.

In the File Name text box, type the name of your connector database, for example exchange.box.

d.

Click Open.

8.

Click File, point to Database, click Access Control, and then click Add.

9.

In the People, Servers, Groups text box, click the browse icon.

10. Select the user ID for Connector for Lotus Notes from the Lotus Domino address book, click Add, and then click OK. 11. From the Access list, select Manager, select the Delete documents check box, and then click OK.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 215

Figure A.2

Creating the connector mailbox

216 Exchange Server 2003 Interoperability and Migration Guide

To create the connector mailbox for badmail 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino administrator permissions.

2.

Click File, and then click Open Server.

3.

In the Select a server to administer dialog box, in the Server text box, type the name of your server running Lotus Domino, including the certifier information (for example, server01/contoso). Click OK.

4.

Open the connector database: a.

Select the Files tab.

b.

Click File, point to database, and then click Open.

c.

From the Server list, select the server running Lotus Domino.

d.

In the Filename text box, type the name of your connector database (for example, exchange.box).

e.

Click Open.

5.

Click File, point to Database, and then click New Copy.

6.

In the Copy Database dialog box: a.

From the Server list, select the server running Lotus Domino.

b.

Verify that the Title text box shows the name you entered for your connector database (for example, Exchange Connector Database). Add for badmail to the name (for example, Exchange Connector Database for badmail).

c.

In the File Name text box, change the extension of the existing file name to .bad. For example, if the existing file name is exchange.box, change the file name to exchange.bad.

d.

Select Database design only and ensure that the Access Control List check box is selected. Click OK.

Figure A.3

Creating the connector mailbox for badmail

To hide the new User ID from Exchange users or downstream Lotus Domino domains 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

Click the People and Groups tab.

3.

In the left pane, click People.

4.

In the right pane, select the user ID you created for Connector for Lotus Notes (for example, Connector, Exchange).

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 217

5.

Click Edit Person.

6.

On the Administration tab, in the Foreign directory sync allowed text box, type No.

7.

Click Save and Close.

To grant Connector for Lotus Notes Depositor access 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

Click File, point to Database, and then click Open.

3.

From the Server list, select the server running Lotus Domino.

4.

In the File Name text box, type mail.box, and then click Open. Note Mail.box is the default name of the mailbox file on a server running Lotus Domino. If your server running Lotus Domino uses a mailbox with a different file name, use that name instead.

5.

Click File, point to Database, click Access Control, and then click Add.

6.

In the People, Servers, Groups text box, click the browse icon.

7.

Select the user ID for Connector for Lotus Notes, click Add, and then click OK.

8.

From the Access list, select Depositor, and then click OK.

Figure A.4

Granting Depositor access

Note In the default configuration, Lotus Domino grants all users Depositor access to the mail.box database. However, it is recommended that you grant the connector ID Depositor access specifically to avoid message transfer problems in case the Lotus Domino configuration is changed.

To grant Connector for Lotus Notes Editor access to the Lotus Domino directory 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

On the People and Groups tab, select the directory for the Lotus Domino domain.

218 Exchange Server 2003 Interoperability and Migration Guide

3.

Click File, point to Database, click Access Control, and then click Add.

4.

In the People, Servers, Groups text box, click the browse icon.

5.

Select the user ID for Connector for Lotus Notes, click Add, and then click OK.

6.

From the Access list, select Editor.

7.

Ensure that the Delete documents check box is selected, and then click OK. Note If you are not permitted to grant the connector ID Editor access to the default names and address book, consider implementing a separate address book for the Exchange organization and granting the connector ID Editor access to this database. Consult your Lotus Domino product documentation for details about how to configure cascading address books.

To grant Reader access on a specific database Note Perform the following steps only for databases that Connector for Lotus Notes needs to access to convert document links to Rich Text Format (RTF) attachments.

1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

Click File, point to Database, and then click Open.

3.

In the Server list, select the server running Lotus Domino.

4.

Select the database to which you want to grant Reader access, and then click Open.

5.

Click File, point to Database, and then click Access Control.

6.

Click Add.

7.

In the People, Servers, Groups text box, click the browse icon.

8.

Select the user ID for Connector for Lotus Notes, click Add, and then click OK.

9.

From the Access list, select Reader, and then click OK.

10. Perform this procedure on each database that will contain document links.

To identify the Exchange organization as a foreign domain 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

Click View, point to Server, and then click Domains.

3.

Click Add Domain.

4.

In the Domain dialog box, on the Basics tab:

5.

a.

From the Domain type list, select Foreign Domain.

b.

In the Foreign domain name text box, type a name that represents the Exchange organization to Lotus Domino. For example, type Exchange. Exchange Recipient Update Service uses this name later.

On the Mail Information tab: a.

In the Gateway server name text box, type the name of the Lotus Domino server to which Connector for Lotus Notes will connect (the Lotus Domino bridgehead server). You must type the full name, including the certifier information (for example: server01/contoso).

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 219

b.

6.

In the Gateway mail file name text box, type the name of the mail file you created previously. For example, type exchange.box (exchange.box is the database that Connector for Lotus Notes uses to retrieve mail from the server running Lotus Domino that is directed to Exchange 2003 mailboxes). You specify this same mailbox later when you configure Connector for Lotus Notes.

Click Save and Close.

Installing and Configuring Connector for Lotus Notes After you configure your Lotus Domino environment, you can install and configure Connector for Lotus Notes on an Exchange 2003 server. This procedure includes installing the connector, either as part of the server setup or when running the Exchange Setup program on an already-installed Exchange 2003 server. Although you can set up the connector after you install Exchange 2003, it is assumed that you are performing the connector installation during the initial server setup. You also must install and configure Lotus Notes Client release 4.6 or later on the connector server before you can configure Connector for Lotus Notes.

Prerequisites Ensure that your environment meets the following requirements: •

You have a Windows-based network, including an Exchange organization, and Active Directory deployment.

•

You have Exchange Administrator permissions to install an Exchange 2003 server in the Exchange organization.

•

In Exchange System Manager, you have selected the Display routing groups and Display administrative groups options on the properties page for the organization object.

Ensure that the server on which you install Exchange 2003 meets the following requirements: •

It is running Microsoft Windows Server™ 2003.

•

It has network connectivity to the server running Lotus Domino.

•

It can resolve the name of the server running Lotus Domino.

•

It is not running Lotus Domino software.

•

You have a Lotus Notes Client access license for your server running Exchange 2003.

•

You are a member of the Administrators group on the server on which you install Exchange 2003.

To install Exchange 2003 with Connector for Lotus Notes 1.

Insert the Exchange 2003 CD into the CD-ROM drive of a computer running Windows Server 2003.

2.

At the command prompt, type cd e:\setup\i386 where e is the drive letter for the CD-ROM drive.

3.

Type setup.exe and press ENTER.

4.

On the Microsoft Exchange Installation Wizard Welcome page, click Next.

5.

On the License Agreement page, if you agree, select I agree, and then click Next.

6.

On the Product Identification page, enter your CD key and then click Next.

220 Exchange Server 2003 Interoperability and Migration Guide

7.

On the Component Selection page, in the Action menu next to Exchange 2003, select Custom.

8.

From the Microsoft Connector for Lotus Notes menu, select Install, and then click Next.

Figure A.5 9.

Installing Connector for Lotus Notes

If you are installing your first Exchange 2003 server, an Installation Type page appears. Ensure that Create a new Exchange Organization is selected and click Next.

10. If you are creating a new Exchange organization, on the Organization Name page, enter an Organization Name, such as Contoso, and click Next. 11. On the Licensing Agreement page, if you agree, select I agree that I have read and will be bound by the license agreements for this product, and then click Next. 12. On the Component Summary page, ensure Connector for Lotus Notes is selected, and then click Next. 13. If a Microsoft Exchange Installation Wizard dialog box appears informing you that your domain has been identified as an insecure domain, click OK. 14. After Setup completes successfully, click Finish.

To install Lotus Notes release 5 on a server running Exchange 2003 1.

Insert the Lotus Domino release 5 CD into the CD-ROM drive of the server running Exchange 2003.

2.

At the command prompt, type cd e:\clients\w32intel where e is the drive letter for the CD-ROM drive.

3.

Type setup.exe, and then press ENTER.

4.

On the Lotus Notes Installation Wizard Welcome page, click Next.

5.

On the License Agreement page, read the agreement. If you agree, click Yes.

6.

On the Name and Company page, fill out your name and the name of your company, and then click Next.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 221

7.

On the Installation Folders page, choose the installation path to the folder where you want to install Lotus Notes, and then click Next. Note Write down the location because you must have it to supply the location of the Notes.ini file.

8.

On the next page, select Domino Administrator, and then click Next. This installs the Lotus Domino Administrator tool, as well as the Lotus Notes Client software.

9.

On the Program Folder page, click Next.

10. After the Lotus Notes installation is complete, click Finish.

To configure Lotus Notes Client 1.

Click Start, point to All Programs, point to Lotus Applications, and then click Lotus Notes. Because this is the first time you are running Lotus Notes, Lotus Notes Client Configuration Wizard starts.

2.

On the Setting Up Connections page, click Next.

3.

On the Do You Want to Connect to a Domino Server page, select I want to connect to a Domino server, and then click Next.

4.

On the How Do You Want to Connect to a Domino Server page, select Set up a connection to a local area network (LAN), and then click Next.

5.

On the Domino Server Name page, in the Domino server name text box, type the name of the Lotus Domino server that will act as a bridgehead between Exchange 2003 and Lotus Domino, and then click Next. This should be the server that you configured earlier.

6.

On the Who Are You page, select My Notes User ID has been supplied to me in a file, and then type the path to the Connector for Lotus Notes user ID file in the File name text box. Note This path is the same one you created in the "To create a Lotus Notes release 5 user ID" procedure earlier in this appendix.

Figure A.6

Specifying the path to the User ID file

7.

When asked if you want the user ID file copied to your data directory, click Yes.

8.

On the Connecting to a Domino Server over a LAN page, click Next.

222 Exchange Server 2003 Interoperability and Migration Guide

9.

On the Set Up an Internet Mail Account page, click Next.

10. On the Connect to a News Server page, click Next. 11. On the Connect to an Internet Directory Server page, click Next. 12. On the Connect through a Proxy Server page, select I do not connect to the Internet through a proxy server, and then click Next. 13. On the Internet Connection Type page, select Connect over local network (or cable modem), and then click Next. 14. On the Congratulations page, click Finish. 15. Exit Lotus Notes.

To add the Lotus Notes installation path to the Windows system path 1.

On the server running Exchange 2003 on which you will run the Exchange Migration Wizard, click Start, point to Settings, and then click Control Panel.

2.

Double-click System.

3.

On the Advanced tab, click Environment Variables.

4.

In the System variables list, select Path, and then click Edit.

5.

On the Edit System Variable page, in the Variable Value text box, add a semi-colon (;) to the end of the existing path, and then type the path to the folder where Lotus Notes is installed. For example, type ;d:\lotus\notes. Click OK.

To enable and customize Lotus Notes proxy addresses 1.

On the Start menu, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2.

Expand Recipients, and then click Recipient Policies.

3.

In the details pane, right-click Default Policy, and then click Properties. You can also create a new recipient policy.

4.

On the policy's E-Mail Addresses (Policy) tab, select the NOTES check box (this enables the address), ensure that the Notes address entry is selected, and then click Edit.

5.

In the Address text box, modify the address format. Use placeholders, as discussed in Chapter 2, to represent various values in the format string. For example, you can set the address format to &g@Exchange. A user whose display name is Birgit Seidl receives a Lotus Notes address of: Birgit@Exchange. For more information about placeholders in NOTES address generation rules, see Chapter 2, "Migrating from Lotus Notes/Domino Messaging Infrastructures."

6.

After you configure the address formula, click OK.

7.

On the Default Policy Properties tab, click OK.

8.

You are asked if you want to update all corresponding recipient e-mail addresses to match the new addresses. To run Recipient Update Service immediately, click Yes. To update the addresses the next time Recipient Update Service runs, click No. Non-Exchange addresses are always updated, even if you made manual changes to specific addresses.

9.

Wait for Recipient Update Service to populate the Exchange address lists. The time required varies depending on the update interval set on the service.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 223

To configure Connector for Lotus Notes 1.

In Exchange System Manager, expand Administrative Groups, expand Routing Groups, and then expand the First Routing Group. Expand the Connectors container, right-click Connector for Lotus Notes, and then click Properties.

2.

On the General tab: a.

In the Notes Server text box, type the full name of your server running Lotus Domino, including the certifier information (for example, server01/contoso).

b.

Next to the Notes INI file location text box, click Modify. In the Notes INI file location text box, type the path to your Notes.ini file (including the file name). Typically, this is the path where you installed the Lotus Notes client (for example, d:\lotus\notes\notes.ini). Search for Notes.ini on your hard disk drive to ensure that you have the correct path. In the Password and Confirm password text boxes, enter the password for the Connector for Lotus Notes user ID for the server running Lotus Domino. Click OK.

c.

In the Connector mailbox text box, type the name of the gateway mailbox you configured earlier on your server running Lotus Domino (for example, exchange.box). If you specified a different name for the gateway mail file on the server running Lotus Domino, type that name now. Important If you type a name in this box other than the one you specified when you configured the server running Lotus Domino, you must reconfigure the gateway mail file name option in the foreign domain document on the server running Lotus Domino.

d.

In the Polling interval text box, type the interval (in seconds) that Connector for Lotus Notes uses to check for new messages delivered to Exchange. The default is 15 seconds.

e.

In the Notes Server language list, select the language of the server running Lotus Domino. Exchange uses this information for certain actions, such as determining which language nondelivery report (NDR) to use for a failed message.

f.

In the Convert Notes DocLinks to list, select one of the following formats for Connector for Lotus Notes to use to convert Lotus Notes document links: •

OLE Document Link This is represented by an icon in the Exchange message. When the user clicks the icon, Lotus Notes starts and the document link works as it should. (Lotus Notes must be installed on the client computer.)

•

RTF Attachment (default) The document is converted to an RTF attachment. Because this attachment is a copy of the data from the actual Notes document, users cannot edit the document.

•

URL Shortcut The document link is converted to a URL. When you click the URL, the default Web browser tries to access the computer running Lotus Notes to which the link points. This option is useful if the user can access the document on the Lotus Domino server through HTTP. The user still requires a Lotus Notes name, password, and license to access the document, unless anonymous authentication is allowed.

224 Exchange Server 2003 Interoperability and Migration Guide

Figure A.7 3.

Connector for Lotus Notes General tab settings

On the Address Space tab: a.

Click Add to add the address space for Lotus Domino.

b.

On the Add Address Space tab, select NOTES, and then click OK.

c.

On the Lotus Notes Address Space Properties tab, in the User Name text box, type an asterisk (*) to allow all users to connect to Lotus Domino using Connector for Lotus Notes. In the Domain text box, type the name of the Lotus Domino domain to which the connector will connect (for example, contoso), and then click OK.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 225

Figure A.8 4.

Configuring the NOTES address space

On the Advanced tab: a.

In the Notes letterhead text box, specify the Lotus Notes letterhead name that you want to append to the top of messages sent from Exchange 2003 users to Lotus Domino users. The letterhead name that you specify must match the letterhead name defined in the Lotus Notes mail database to which messages are sent. If the names do not match, no letterhead is used.

b.

In the Notes router mailbox text box, enter the name of the server mailbox on the Lotus Domino bridgehead server to which Connector for Lotus Notes connects. Change this setting only if you are using a mailbox other than the default mailbox specified on the server running Lotus Domino. The default mailbox is mail.box.

c.

From the Delivery order list, select the order in which messages are to be delivered from Exchange 2003 to Lotus Domino. This order specification controls the sequence in which Exchange messages are placed in the MTS-OUT queue by the Exchange message transfer agent (MTA), and the sequence in which messages are delivered to the server running Lotus Domino. The options are: •

Priority High priority messages, such as urgent messages, are delivered to the outbound queue first. This is the default setting.

•

FIFO Messages are delivered to the outbound queue on a first in, first out (FIFO) basis.

•

Size Smaller messages are delivered to the outbound queue before larger messages.

d.

To automatically compact database files, from the Notes database maintenance schedule list, select a schedule for Connector for Lotus Notes. Compacting database files keeps them from becoming too large and fragmented.

e.

To configure a custom schedule for automatic compacting, click Customize.

f.

To add a list of downstream Lotus Domino domains to which users can send messages, under Routable domains, click Add.

226 Exchange Server 2003 Interoperability and Migration Guide

g.

On the Add Routable Domain tab, in the Domain text box, type the name of a Lotus Domino domain to which Connector for Lotus Notes does not connect directly, and then click OK. Repeat for each downstream domain.

h.

If you want to limit the size of messages that Connector for Lotus Notes accepts from Lotus Domino users, under Message size, select Maximum (KB). Type a value (in kilobytes), and then click OK.

Figure A.9

Configuring the Advanced tab options

Configuring Directory Synchronization After you configure Connector for Lotus Notes, you can synchronize directories between Lotus Domino and Exchange 2003 (Active Directory). It is recommended that you test the directory synchronization process manually to ensure everything works as expected.

Prerequisites Ensure that your environment meets the following requirements: •

You have Exchange Administrator permissions.

•

You have network connectivity to the server running Lotus Domino.

•

You have can resolve the name of the server running Lotus Domino.

•

You have installed and configured Lotus Notes Client.

•

You have installed and configured Connector for Lotus Notes.

To configure directory synchronization with Lotus Notes 1.

In Exchange System Manager, right-click Connector for Lotus Notes, and then click Properties.

2.

On the Import Container tab:

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 227

a.

To select the Active Directory container (group or organizational unit) to which Lotus Domino users are imported, click Modify. It is recommended that you create a dedicated organizational unit for all your Lotus Domino users and select that organizational unit here.

b.

On the Choose a container tab, browse to the container to which you want to import Lotus Domino users. Select the container, and then click OK. Note If you receive a message that reads The machine account must be granted permission to create and modify recipients in the selected import container. Continue? click Yes. This is necessary for directory synchronization from Lotus Domino to Exchange 2003 to work. When you click Yes, you add the computer account with the permissions required to manipulate objects in the selected container.

Figure A.10 Selecting the Active Directory container to which to import Lotus Domino users c.

In the When replicating a mailbox whose primary Windows account does not exist in the domain list, select one of the following options for Active Directory to use when new users are imported: •

Create a disabled Windows user account

•

Create a new Windows user account

•

Create a Windows contact

This setting applies only to new users. If you change this setting later, it does not affect Lotus Domino users who are already replicated to Active Directory. If you are not sure which option to select, select Create a disabled Windows user account or Create a Windows contact. Select Create a new Windows user account only if Lotus Domino users are logging on to the Windows domain.

228 Exchange Server 2003 Interoperability and Migration Guide

Figure A.11 3.

Selecting the account option

On the Export Containers tab: a.

To select which groups or organizational units are exported from Active Directory to the Lotus Domino directory, click Add.

b.

In the Choose a container tab, select the organizational unit that you want to export to the Lotus Domino directory, and then click OK. Note If you receive a message that reads The machine account must be granted permission to read the deleted recipients in the selected domain. Continue? click Yes. This is necessary for directory synchronization from Lotus Domino to Exchange 2003 to work. When you click Yes, you add the computer account with the permissions required to manipulate objects in the selected container.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 229

Figure A.12 4.

Selecting an organizational unit to export

On the Dirsync Options tab: a.

From the Exchange-Notes directory update schedule list, select the schedule for directory synchronization. Do not schedule synchronization during peak traffic hours, because it can slow message throughput. If your directory information changes infrequently, schedule synchronization for once a day. If your directory information changes frequently, schedule synchronization for two or more times a day.

Figure A.13 b.

Selecting a synchronization schedule

Click Customize to schedule synchronization for a period other than those provided by default on the list.

230 Exchange Server 2003 Interoperability and Migration Guide

c.

If you want to customize how Connector for Lotus Notes interacts with the Lotus Domino directory, click Address Book Settings. Note Generally, you configure address book settings only if you choose not to use the default Lotus Domino directory file name (NAMES.NSF) or if you want to specify different address books for other Lotus Domino domains.

5.

Click OK to close each dialog box. Note For more information about configuring directory synchronization through attribute mapping tables, see Chapter 2, "Migrating from Lotus Notes/Domino Messaging Infrastructures."

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 231

To test directory synchronization manually 1.

Start Connector for Lotus Notes:

2.

Open the Services Microsoft Management Console (MMC) snap-in: Click Start, point to All Programs, point to Administrative Tools, and then click Services.

3.

In the details pane, right-click Microsoft Exchange Connector for Lotus Notes, and then click Start. This also starts the Microsoft Exchange Connectivity Controller service. •

The default startup type for Connector for Lotus Notes is manual. You should change the startup type to Automatic. To make this change, right-click Microsoft Exchange Connector for Lotus Notes, and then click Properties. On the Startup type list, select Automatic, and then click OK. The next time the server starts, the Microsoft Connector for Lotus Notes service starts automatically.

4.

In Exchange System Manager, right-click Connector for Lotus Notes, and then click Properties.

5.

On the Dirsync Options tab: a.

Under Exchange to Notes directory synchronization, click Immediate full reload. You receive a popup message that directory synchronization has begun. This process synchronizes directory objects from Active Directory to the Lotus Domino directory.

b.

Under Notes to Exchange directory synchronization, click Immediate full reload. Again, you receive a pop-up message that directory synchronization has begun. This process synchronizes directory objects from the Lotus Domino directory to Active Directory.

Installing and Configuring Calendar Connector in a Lotus Domino Environment Use the following procedures to configure Calendar Connector so that users using either Exchange or Lotus Domino can access each other's free/busy information. You install Calendar Connector on a server running Exchange. The most straightforward option is to install Calendar Connector on the server running Connector for Lotus Notes. Apart from installing and configuring Calendar Connector, you must ensure that the Exchange 2003 server holds a local replica of the SCHEDULE+ FREE BUSY public folder, and you must also prepare the server running Lotus Domino for the Exchange Calendar Connector add-in.

Prerequisites Ensure that the server on which you install Calendar Connector meets the following requirements: •

The server is running Exchange Server 2003.

•

The server is part of the same routing group as the server running Connector for Lotus Notes.

•

You have the permissions of a Schema Administrator and an Exchange Administrator, and are a member of the Administrators group on the computer on which you install Calendar Connector.

•

You have installed and configured the Lotus Notes client software.

•

You have network connectivity to the server running Lotus Domino.

In addition, the server running Lotus Domino to which Calendar Connector connects must meet the following prerequisites: •

The operating system must be either Windows NT® version 4.0 or Windows® 2000 Server.

232 Exchange Server 2003 Interoperability and Migration Guide

•

The name of the server running Lotus Domino must be the same as the name of the server running Windows.

•

The server must use an x86-based processor. Note It is recommended that you implement dedicated bridgehead servers for messaging and calendar connectivity. For more information, see Chapter 2, "Migrating from Lotus Notes/Domino Messaging Infrastructures."

To install Calendar Connector 1.

Insert the Exchange Server 2003 Service Pack 1 (SP1) or later CD into the CD-ROM drive of the server running Exchange 2003 SP1 or later.

2.

At a command prompt, type cd e:\setup\i386 where e is the drive letter for the CD-ROM drive.

3.

Type setup.exe, and then press ENTER.

4.

On the Microsoft Exchange 2003 Installation Wizard Welcome page, click Next.

5.

On the Component Selection page, in the Action menu next to Microsoft Exchange, select Change.

6.

In the Action menu next to Microsoft Exchange Messaging and Collaboration Services, select Change.

7.

From the Microsoft Exchange Calendar Connector menu, select Install, and then click Next.

Figure A.14

Installing Calendar Connector

8.

On the Installation Summary page, verify the installation choices, and then click Next.

9.

After Setup completes, click Finish.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 233

To add a local replica of the SCHEDULE+ FREE BUSY public folder 1.

In Exchange System Manager, expand Administrative Groups, expand the administrative group that contains the server running Exchange with Calendar Connector (for example, First Administrative Group), and then expand Folders.

2.

Expand Public Folders. If you do not see the SCHEDULE+ FREE BUSY public folder, right-click Public Folders, and then click View System Folders.

3.

Expand Public Folders, expand SCHEDULE+ FREE BUSY, right-click the public folder that refers to your administrative group that contains the Exchange server running Calendar Connector (for example, EX:/o=Contoso/ou=First Administrative Group), and then click Properties.

4.

On the Replication tab, click Add.

5.

On the Select a Public Store page, select the server running Exchange 2003 with Calendar Connector, and then click OK.

6.

On the Public folder replication interval list, select Always Run. This setting causes replication to occur whenever there is a change in free/busy information. Click OK.

Figure A.15

Configuring free/busy information replication

To install the Calendar Connector add-in in Lotus Domino 1.

Copy excalcon.exe from the \Program Files\Exchsrvr\BIN\ directory on the server running Exchange 2003 to the Lotus Domino installation directory on the server running Lotus Domino. By default, the installation directory on the server running Lotus Domino release 5 is d:\lotus\domino, where d is the drive letter on which Lotus Domino is installed.

2.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino administrator permissions.

3.

Switch to the server console: Click the Server tab, and then, on the Status tab, click Console.

234 Exchange Server 2003 Interoperability and Migration Guide

4.

At the console, type load excalcon <exchange-server-name> <mail-file-name>, where exchangeserver-name is the name of the server running Exchange 2003 with Calendar Connector installed, and mail-file-name is the name of the gateway mail file you configured earlier. For example, if your Exchange server name is server01 and you used the name exchange.box for the gateway file name, you type: load excalcon server01 exchange.box.

5.

Press ENTER and verify that Calendar Connector for Exchange has started.

6.

To verify that the Calendar Connector add-in loaded correctly, type show tasks at the console, and then ensure that there is an entry for Exchange Cal Conn. Using the previous example, it should look something like this: Exchange Cal Conn 0/0 0.

Figure A.16

Not Connected to ct-exch2 for exchange.box. Stats=0

Calendar Connector add-in status information

The Stats information can be understood according to the following syntax: Stats= , where: •

is the total number of calendar requests made from Lotus Domino to Exchange.

•

is the average number of invitees over the average response time, in seconds, for each Exchange calendar request made from Lotus Domino.

•

is the maximum response time, in seconds, for all calendar requests.

To automate startup of the Calendar Connector add-in 1.

On the server running Lotus Domino, open the server's Notes.ini file in a text editor, such as Notepad.

2.

Find the line in the file that starts with ServerTasks= and add ,excalcon <exchange-server-name> <mail-file-name> to the end of this line, where exchange-server-name is the name of the server running Exchange 2003 and mail-file-name is the name of the gateway mail file you configured earlier. For example, the original line in the file might look like this: ServerTasks=Router,Replica,Update,Amgr,AdminP,CalConn,Event,Sched,Stats,HT TP,DIIOP,IMAP,POP3,NNTP,maps

After you add the parameter for starting the Calendar Connector add-in, the line might look like this:

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 235

ServerTasks=Router,Replica,Update,Amgr,AdminP,CalConn,Event,Sched,Stats,HT TP,DIIOP,IMAP,POP3,NNTP,maps,excalcon server01 exchange.box

3.

Save the modified version of Notes.ini.

To update the foreign domain document for Exchange 1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

On the People & Groups tab, on the menu bar, click View, point to Server, and then click Domains.

3.

Expand Foreign Domain, select your Exchange domain, and then click Edit Domain.

4.

On the Calendar Information tab: a.

In the Calendar server name text box, type the name of the Lotus Domino server on which you installed the Calendar Connector add-in. You must type the full name, including the certifier information (for example, server01/contoso).

b.

In the Calendar system text box, type the name of the gateway mail file you configured earlier (for example exchange.box).

Figure A.17 c.

Updating calendar information for the Exchange foreign domain

Click Save and Close.

To edit an individual calendar profile 1.

Open the Lotus Notes client software.

2.

Click Calendar.

3.

On the menu bar, click Actions, point to Tools, and then click Preferences.

4.

On the Free Time tab, if the Allow only these people view my Free Time information text box is not empty, add the name of the Calendar Connector user ID to the list of users or groups. If the text box is

236 Exchange Server 2003 Interoperability and Migration Guide

empty, no further action is needed. The Calendar Connector user ID can access the user's free/busy information. Note This list is exclusive, so if it is not blank and does not contain the Calendar Connector's user name, Exchange users cannot view Lotus Notes users' free/busy information.

5.

Click OK.

Figure A.18 Allowing Exchange users to access Lotus Domino users' restricted free/busy information

Configure Calendar Connector 1.

In Exchange System Manager, expand Administrative Groups, expand the administrative group that contains the server running Exchange with Calendar Connector (for example, First Administrative Group), expand Routing Groups, expand the routing group in which you installed Calendar Connector (for example, First Routing Group), expand Connectors, right-click Calendar Connector, and then click Properties.

2.

On the General tab: a.

Next to the Connector used to import users into Active Directory text box, click Modify.

b.

On the Select Exchange Notes or Groupwise Connector tab, select the Connector for Lotus Notes instance that is used to connect to the bridgehead server running Lotus Domino, and then click OK.

c.

In the Number of days of free/busy information to request from foreign calendars text box, enter the number of days that users are able to see free/busy information for users on the foreign messaging server. Note Free/busy information beyond the number of days specified is not retrieved by Calendar Connector and appears as free, even if meetings are scheduled during this time.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 237

d.

In the Maximum age in minutes of foreign free/busy data in Exchange that can be used without querying the foreign calendar text box, enter the number of minutes of free/busy information that the Calendar Connector can accept. Note If the free/busy information is beyond the specified number of minutes, Calendar Connector requests updated data. If the free/busy information is within the specified number of minutes, Calendar Connector uses the current free/busy information.

e.

In the Maximum number of seconds to wait for response from foreign calendars text box, enter the number of seconds that you want Calendar Connector to wait for a response for an individual user's free/busy information. Enter a low number because each recipient on a meeting request is handled in turn, and a long response interval can cause the mail client to stop responding as it proceeds down the list of recipients.

Figure A.19 3.

Setting the General tab Calendar Connector options

On the Calendar Connections tab: a.

Click New.

b.

In the Calendar Type dialog box, select Lotus Notes, and then click OK.

c.

In the Notes Calendar Connection dialog box, in the NT Server Hosting the Notes Server text box, type the Windows name of the bridgehead server running Lotus Domino. Do not include the certifier information. For example, if your full Lotus Domino server name is listed as server01/contoso, you type server01.

d.

Click Modify.

e.

On the Notes.INI File and Password tab, in the Notes.INI file location text box, type the path to the Notes.ini file on the server running Exchange 2003 with the connector, or click Browse to browse to the file. For example, type d:\lotus\notes\notes.ini. In the Password and Confirm password text boxes, enter the password (if any) for the Lotus Domino user ID used by Connector for Lotus Notes. Click OK.

238 Exchange Server 2003 Interoperability and Migration Guide

Figure A.20 4.

Configuring the calendar connection to Lotus Domino

On the Schedule tab, select Always. Selecting Always causes Calendar Connector to create a free/busy record for Lotus Domino recipients in the Exchange public folder. Creation of records happens every fifteen minutes for new recipients. Alternatively, select Selected times to specify a custom time for the connector to create new records in the server's public folder. Click OK.

To start the Calendar Connector service 1.

Open the Services MMC snap-in: Click Start, point to All Programs, point to Administrative Tools, and then click Services.

2.

In the details pane, right-click Microsoft Exchange Calendar Connector, and then click Start.

3.

The default startup type for Calendar Connector is manual. You should change the startup type to Automatic. To make this change, right-click Microsoft Exchange Calendar Connector, and then click Properties. On the Startup type list, select Automatic, and then click OK. The next time the server starts, the Calendar Connector service starts automatically.

Figure A.21

Setting the Calendar Connector schedule

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 239

Migrating from Lotus Domino to Exchange 2003 The following procedures explain how to migrate a group of users from Lotus Domino to Exchange 2003. The guidelines are recommended for most migrations, and consist of extracting data from the server running Lotus Domino and immediately importing it into Exchange 2003. To migrate data from Lotus Domino to Exchange 2003, the Exchange Migration Wizard requires access to the mailbox for each user who is to be migrated. There are two ways for the user ID used by the Exchange Migration Wizard to gain access to users' mailboxes. You can ask your users to grant access to their mailboxes using Lotus Notes, or you can create a link from the local database to the Lotus Domino database.

Prerequisites Ensure that the server on which you run the Exchange Migration Wizard meets the following requirements: •

The server is running Exchange Server 2003.

•

If you have configured Connector for Lotus Notes and directory synchronization, stop the Connector for Lotus Notes service. Stopping this service is necessary to prevent directory synchronization from deleting Lotus Domino mailboxes before you verify that migration is successful. If you want to run the Exchange Migration Wizard directly on the server running Connector for Lotus Notes, ensure that all connector services are stopped. Otherwise, the connector might lock Notes.ini, in which case the Exchange Migration Wizard is unable to extract data from the Lotus Domino server.

•

You have installed and configured Lotus Notes Client.

•

You have network connectivity to the server running Lotus Domino.

•

You have administrative permissions in Exchange 2003, as well as in Lotus Domino.

To have the individual user grant access to a mailbox using Lotus Notes Client 1.

Click Start, point to All Programs, point to Lotus Applications, and then click Lotus Notes.

2.

To open the mailbox, click Mail.

240 Exchange Server 2003 Interoperability and Migration Guide

3.

On the menu bar, click File, point to Database, and then click Access Control.

Figure A.22

Opening Access Control in Lotus Notes

4.

In the Access Control List dialog box, click Add.

5.

In the Add User dialog box, click the browse icon.

6.

In the Names dialog box, select the user to whom you want to grant access (for example, the user ID for Connector for Lotus Notes), click Add, and then click OK.

7.

From the User type list, select Person.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 241

8.

From the Access list, select Reader, and then click OK.

Figure A.23

Granting Reader access to Connector for Lotus Notes

To grant access to a user mailbox by creating a link from the local database Note Administrators can use the following procedure to grant the required access rights on behalf of the users. This approach might be better than asking each user to perform the previous procedure individually.

1.

On a computer with Lotus Domino Administrator installed, start Lotus Domino Administrator and log on as a user who has Lotus Domino Administrator permissions.

2.

On the menu bar, click File, and then click Open Server.

3.

From the Server list, select Local, and then click OK.

242 Exchange Server 2003 Interoperability and Migration Guide

4.

On the Files tab, in the right pane, expand Tools, expand Folder, and then click New Link.

Figure A.24 5.

Creating a new link

In the Create New Link dialog box: a.

In the Link name text box, type Migration.

b.

Next to Link to a, select Folder.

c.

In the Path and filename to that folder or database text box, type the path to the Lotus Domino mail database on the server running Lotus Domino. For example, to connect to the default mail database on a server named server01 with Lotus Domino installed on drive D, type: \server01\d$\lotus\domino\data\mail.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 243

d.

In the Who should be able to access this link list box, click the browse icon, and then add the Lotus Domino Administrator account. Click OK.

Figure A.25

Configuring the link to the Lotus Domino database

6.

Press F9 to refresh the list of folders. You can now see the Migration folder you created in the left pane. Click Migration. You can now see a list of users' mailboxes in the right pane.

7.

Press CTRL+A to select all the users at once.

8.

In the right pane, right-click the list of users, point to Access Control, and then click Manage.

9.

In the Multi ACL Management dialog box, click Add.

10. In the Add ACL Entry dialog box, click the browse icon. 11. In the Names dialog box, select the user to whom you want to grant access (for example, the user ID for Connector for Lotus Notes), click Add, and then click OK. 12. From the User type list, select Person.

244 Exchange Server 2003 Interoperability and Migration Guide

13. From the Access list, select Reader, and then click OK. The user ID you specified now has access to the selected users' mailboxes.

Figure A.26 Granting Reader access to Connector for Lotus Notes on multiple user mailboxes 14. For security reasons, delete the folder link after you update the access control lists on the users' mailboxes. To delete the folder link, right-click the Migration folder link, and then click Delete.

To migrate users and mailboxes from Lotus Domino to Exchange 1.

2.

On the server running Exchange 2003 with Connector for Lotus Notes, stop the Connector for Lotus Notes service. Stopping the service is necessary to prevent directory synchronization from deleting Lotus Domino mailboxes before you verify that migration is successful. a.

Click Start, point to All Programs, point to Administrative Tools, and then click Services.

b.

In the details pane, right-click Microsoft Exchange Connector for Lotus Notes, and then click Stop.

Start the Exchange Migration Wizard: Click Start, point to All Programs, point to Microsoft Exchange, point to Deployment, and then click Migration Wizard. Note It is assumed that you are using the server running Exchange that you configured as described in the preceding procedures. This server is already configured to access Lotus Domino. For example, it is running the Lotus Notes client and has an existing user ID for accessing the Lotus Domino server.

3.

On the Exchange Server Migration Wizard Welcome page, click Next.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 245

4.

On the Migration page, select Migrate from Lotus Notes, and then click Next.

Figure A.27

Specifying the type of migration

5.

On the Lotus Notes Migration page, click Next.

6.

On the Migration Procedure page: a.

Under Select the migration method, select One step migration (recommended).

b.

In the Path to migration files text box, type the path to which the migration files are to be temporarily copied. Ensure the hard disk drive has sufficient space to copy the mailboxes for all the users you migrate. You must specify a valid folder path. Click Next.

Figure A.28

Selecting the migration procedure

246 Exchange Server 2003 Interoperability and Migration Guide

7.

On the Migration Destination page, select Migrate to a computer running Exchange Server. The Server list should now show the name of the server running Exchange 2003. From the Information store list, select the Exchange store to which to migrate the Lotus Domino data, and then click Next.

Figure A.29 8.

Selecting the migration destination

On the Access Information page: a.

In the Notes.ini file text box, type the path to the Notes.ini file on the local hard disk drive. Typically, this path is d:\lotus\notes\notes.ini, where d is the drive letter for your hard disk drive on which Lotus Notes is installed.

b.

In the User.ID file text box, type the name of the user ID file the Exchange Migration Wizard uses to access the server running Lotus Domino. The user ID you specify must have access to each user's Lotus Domino mailbox. It is recommended that you use the user ID already used by Connector for Lotus Notes.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 247

c.

In the Password text box, type the password (if there is one) for the Lotus Domino user ID used by Connector for Lotus Notes. Click Next.

Figure A.30 9.

Specifying the access information

On the Hierarchical Name page, select the name of the server running Lotus Domino (with certifier information) from which you will migrate users. This information is populated from the Notes.ini file that you specified during the previous step. Click Next.

Figure A.31 users

Selecting the server running Lotus Domino from which to migrate

10. On the Migration Information page, you should accept the defaults. If you do not want to accept the defaults, you can change the following options: a.

The Information to create mailboxes check box. When selected, this option creates a new mailbox for users migrated from Lotus Domino to Exchange.

248 Exchange Server 2003 Interoperability and Migration Guide

b.

The Personal e-mail messages check box. When selected, this option migrates the user's mail that is stored on the server running Lotus Domino to Exchange. You can either select All to migrate all of the user's mail, or select Dated from to specify a date range of messages to migrate.

c.

The Schedule information check box. When selected, this option migrates the user's schedule information to Exchange. You can either select All to migrate all of the user's schedule information, or select Dated from to specify a date range of schedule information to migrate. Note Any meeting requests in users' inboxes that have not been accepted are migrated as text messages. Users must manually add these meetings to their calendars. Before you complete the migration, ensure that users accept any outstanding meeting requests.

d.

Under Specify how to convert Notes DocLinks, select the format that the Exchange Migration Wizard uses to convert Lotus Notes document links: •

OLE This format is represented by an icon in the Exchange message. When the user clicks the icon, Lotus Notes starts and the document link works as usual, provided the ID file that is being used has access to the document (Lotus Notes must be installed on the client).

•

RTF The document is converted to an RTF attachment. Because this attachment is a copy of the data from the actual Lotus Notes document, users are not able to edit the document.

•

URL This format converts the link to a URL. Clicking the URL starts the default Web browser, which tries to access the server running Lotus Notes to which the link points. (The user still requires a Lotus Notes name, password, and license to access the document, unless anonymous authentication is allowed.) Click Next.

Figure A.32

Specifying the migration information

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 249

11. On the Account Migration page, select the Lotus Domino users you want to migrate to Exchange 2003. The user ID used by the Exchange Migration Wizard must have access to the mailbox of each user you select. You can click Select All to select all users, or press CTRL and select users individually. Click Next.

Figure A.33

Selecting the users to migrate to Exchange 2003

12. On the Container For New Windows Accounts page, select the Active Directory container to which users will be migrated. The Exchange Migration Wizard creates a new Active Directory account for each user in the specified container. Click Options.

Figure A.34

Selecting the container to which to migrate accounts

13. On the Account Options page, select Generate random password, and then select the User must change password at next logon check box. This option generates a random strong password for each user, which is stored in the Accounts.Password file in the \Program Files\Exchsrvr\Bin directory on

250 Exchange Server 2003 Interoperability and Migration Guide

the server running Exchange 2003. Alternatively, you can select other advanced options on this page, such as whether to create disabled user accounts that point to actual accounts in a different domain. For the purposes of this procedure, it is assumed that you are not selecting these other options. Click OK, and then click Next.

Figure A.35

Setting the account password options for the new user accounts

14. On the Windows Account Creation And Association page, you see a list of all the user accounts that will be created. In some instances, these are new accounts, but they might also be updates to existing accounts. For example, when you configured coexistence with Lotus Domino, you might have decided to create disabled Windows accounts for each Lotus Domino user. These disabled accounts appear for each corresponding user migrating from Lotus Domino. Lotus Domino users are matched with Exchange accounts based on their e-mail addresses.

Appendix A: Configuration Procedures for Migrating from Lotus Notes/Domino Messaging Functionality 251

Verify that the accounts are matched correctly. If they are not, you can find the correct account using the Find Existing Account option. You can also choose to create a new account, using the Create New Account option. After you finalize the account list, click Next.

Figure A.36 accounts

Matching Lotus Domino accounts to new or existing Windows

Note This figure shows an example of Lotus Domino users who had enabled Windows accounts resulting from Exchange 2003 and Lotus Domino coexistence. When these users are migrated, the accounts are matched to the users' e-mail addresses, and then the users' Lotus Domino messaging data is imported to the users' mailboxes. If you created disabled Windows accounts through directory synchronization, you must enable the user accounts in Active Directory Users and Computers after migration occurs to enable users to log on to the Windows domain.

15. The Exchange Migration Wizard extracts the data from the server running Lotus Domino and then imports it into Exchange and Active Directory. Migration can take some time, depending on the number of users and messages that are migrated, speed of the server, network latency, and other factors. On the Migration Process page, verify that the migration process proceeds normally, and when the process completes, click Finish. 16. In the Exchange Server Migration Wizard dialog box that informs you that the migration is complete, click OK.

To check the application event log for migration information 1.

On the server running Exchange 2003 that performed the migration, click Start, point to All Programs, point to Administrative Tools, and then click Event Viewer.

2.

Click Application.

3.

Look for event log messages with the source MSExchangeMig. Double-click the message to view it. Use the up and down arrows to scroll through the message.

To migrate calendar information 1.

Verify that you have received the Migrated Calendar Information import file with an .sc2 file attachment, which the Exchange Migration Wizard generates and sends to each user.

252 Exchange Server 2003 Interoperability and Migration Guide

2.

In Microsoft Office Outlook®, from the File menu, choose Save Attachments.

3.

Type the location and file name for the attached file, and then click Save.

4.

From the File menu, click Import and Export.

5.

Click Import from another program or file, and then click Next.

6.

Click Schedule Plus Interchange, and then type the path and file name of the file you want to import.

7.

Under Options, select Do not import duplicate items to ensure that any previously imported items are not duplicated, and then click Next.

8.

On the Import a file tab, verify the import actions that will be performed. You can click the Map Custom Fields button to customize the mapping of information from the imported file to Outlook contacts, appointments, or tasks, and you can click Change Destination, to specify a destination folder. By default, Outlook imports the information into the standard Contacts, Calendar, and Tasks folders.

9.

Click Finish to complete the calendar migration.

10. In the Microsoft Office Outlook dialog box informing you that you have Schedule+ data stored on the server, click Yes to delete the server copy of this data.

A P P E N D I X

B

Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality

This appendix contains detailed step-by-step instructions for the following: •

Connecting Microsoft® Exchange Server 2003 to a Novell GroupWise 5.5 environment

•

Performing directory synchronization

•

Integrating calendar information

•

Migrating mailboxes from Novell GroupWise to Exchange 2003 Note Microsoft does not officially support interoperability with or migration from Novell GroupWise 6.0 or later. However, because the underlying technologies that are used for interoperability and migration remain the same as in earlier versions, Microsoft Product Support Services (PSS) offers "commercially reasonable effort" support.

Preparing the Novell GroupWise Environment In the following procedures, it is assumed that you are running a Novell NetWare 6.0 server in a TCP/IPbased environment and Novell GroupWise 5.5. To prepare the Novell GroupWise environment, you must install and configure Novell NetWare client and Novell GroupWise client (version 4.6 or later) software on the future Exchange 2003 server, and deploy the Novell GroupWise API Gateway version 4.1. You also must create an external foreign domain for your Exchange 2003 organization, and you must configure the link table of the Novell GroupWise domain to connect the external foreign domain to your GroupWise domain using the API Gateway, so that GroupWise can route messages to Exchange users.

Prerequisites Ensure that the connector server meets the following requirements: •

Is running Microsoft Windows Server™ 2003

•

Has network connectivity to the server running Novell GroupWise

•

Can resolve the name of the server running Novell NetWare

254 Exchange Server 2003 Interoperability and Migration Guide

Ensure that the server running Novell NetWare and Novell GroupWise has the following software installed: •

Novell NetWare 3.x or later

•

Novell NetWare Administrator

•

Novell GroupWise 4.1 or later

To install Novell NetWare Client for Windows 1.

On your Novell NetWare Client CD, open the \Winnt\i386 directory and double-click the SetupNW.exe file.

2.

In the Software License Agreement dialog box, read the license agreement carefully, and if you agree with the terms of the license agreement, click Yes.

3.

In the Novell Client Installation dialog box, click Typical Installation, and then click Install.

4.

When the installation is complete, click Reboot to restart your server.

Figure B.1

Installing Novell NetWare Client for Windows

To test Novell NetWare Client for Windows 1.

After the server restarts, press CTRL+ALT+DEL. When the Novell Login dialog box appears, enter the name of your Novell NetWare administrator account in User Name and the corresponding password in Password, and then click Advanced.

2.

On the NDS tab, click Trees, select your Novell Directory Service (NDS) tree from the Tree dialog box, and then click OK. Click Contexts, and then select the appropriate context for your NetWare administrator account. Click Servers, and then select the Novell NetWare server that you want to use to authenticate your Novell NetWare account.

3.

Click the Windows tab and, under Local username, type Administrator. In the From list, select the name of your Windows domain. In the following procedures, the Windows domain name is CONTOSO.

4.

Click OK.

5.

If a Windows Workstation dialog box appears, enter the password for your Windows administrator account in Password, and then click OK.

6.

Start Windows Explorer, open My Network Places, open Novell Connections, and verify that your preferred NetWare server is listed as a node.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 255

7.

Open the NetWare server (for example, NWServer01), open the SYS volume, open \PUBLIC, open \Win32, and then start Novell NetWare Administrator by double-clicking NWAdmn32.exe. If a File Download dialog box appears warning you that some files can harm your computer, click Open.

8.

If a Welcome to NetWare Administrator message appears, click Close. Verify that NetWare Administrator starts and displays information from the NDS context of the Novell NetWare server.

Figure B.2 9.

Verifying Novell NetWare connectivity

Close the NetWare Administrator program.

To install Novell GroupWise Windows Client 1.

Start Windows Explorer and start d:\client\Win32\Setup.exe from your Novell GroupWise CD (where d: is the drive letter for your CD drive).

2.

In the GroupWise 5.x message box informing you that the Windows Messaging System must be installed, click Continue.

3.

In the Windows Messaging System dialog box, select Leave Windows Messaging System as it is, and then click Next.

4.

On the Welcome page, click Next.

5.

On the Setup Options page, click Standard Install, and then click Next.

6.

On the Destination Directory page, accept the default path of c:\Novell\GroupWise, and click Next. If you would like to change the installation path, click Browse, and select the target directory in the Choose Directory dialog box.

256 Exchange Server 2003 Interoperability and Migration Guide

7.

On the Select Optional Components page, accept the default selections, and click Next.

Figure B.3

Installing Novell GroupWise 5.5 Client

8.

On the Select Program Folder page, accept the default program group, GroupWise 5, and click Next.

9.

On the Select Startup Folder Software page, ensure that no tools are selected, and then click Next.

10. On the Language Selection page, select English, and click Next. 11. On the Start Copying Files page, click Next.

To install the Novell GroupWise API Gateway on a Novell NetWare server 1.

At the System Console, type NWConfig, and then press ENTER.

2.

On the Configuration Options page, select Product Options, and press ENTER.

3.

Select Install A Product Not Listed, and press ENTER again.

4.

Ensure that the floppy disk containing the API Gateway files is inserted in drive A: on the NetWare server, and then, in the NetWare Configuration program, press ENTER.

5.

The API Gateway Installation screen appears. Change the Domain Path and the Gateway Directory if required, and then select Install and press ENTER to continue.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 257

Figure B.4

Installing the Novell GroupWise API Gateway

6.

In the NetWare Configuration screen that appears after the installation is complete, press ESC twice, and then press ENTER to exit the NetWare Configuration program.

7.

Insert the floppy disk with the files for Patch 2 for the GroupWise version 4.1 API for Netware Loadable Module (NLM) into drive A, and then, on the NetWare System Console, type load A:\PINSTALL.NLM and press ENTER.

8.

In the API Gateway Installation screen, ensure that the settings Domain Path, Gateway Directory, Gateway NLMs, Shared NLMs, and Load Script match your API Gateway configuration. Select Install and press ENTER. A message box appears notifying you that NGWAPI.PRM already exists and will be moved to the \SAVE directory. Press ENTER to continue and install the gateway files. The installation completes automatically.

9.

At the System Console, type edit and press ENTER, and then, in the NetWare Text Editor, specify the path and file name for the gateway's NGWAPI.PRM file (for example, SYS:\API41\NGWAPI.PRM), and then press ENTER again.

10. Scroll down to the line beginning with /Home- and ensure that it points to the gateway directory (for example, /Home-SYS:\Public\Grpwise\Domain\Wpgate\API41). In an installation without Patch 2 for API NLM, you must correct the default /Home- line manually. 11. Find the line beginning with ;/Group and remove the semicolon in front of it to activate the inbound group expansion. 12. Press ESC. When you are prompted to save the changes, select Yes, and then press ENTER. 13. Press ESC and ENTER to exit the text editor.

To configure the API Gateway for Exchange 2003 1.

Log on to your future Exchange 2003 server, and start the Novell NetWare Administrator program (SYS:\Public\Win32\NWAdmn32.exe). If a File Download dialog box appears warning you that some files can harm your computer, click Open.

2.

If a Welcome to NetWare Administrator dialog box appears, click Close. In NetWare Administrator, on the View menu, click Set Context.

3.

In the Set Context dialog box, under Tree, select your NDS tree (for example, CONTOSO) and under Context, select [Root]. Click OK.

4.

Double-click the GroupWise node and then select the GroupWise domain object where you want to install the gateway (for example, CONTOSO_DOM).

258 Exchange Server 2003 Interoperability and Migration Guide

5.

Right-click the domain object (for example, CONTOSO_DOM) and then click Create.

6.

In the New Object dialog box, double-click GroupWise Gateway/Internet Agent.

7.

In the Create GroupWise Gateway/Internet Agent dialog box, specify the following information (leave the remaining settings at their defaults), and then click Create: •

Gateway Name - Use a descriptive, unique name within the domain (for example, Exchange Gateway) that identifies the gateway. NetWare Administrator prevents the creation of gateway objects with duplicate names.

•

Gateway Home Directory - Select the directory that you specified during the installation of the API Gateway (for example, API41).

•

Gateway Type - API

•

Version - 4.x (Note that an API Gateway for GroupWise 5 or later does not exist.)

•

Platform - NetWare Loadable Module (It is recommended that you use the NLM version of the API Gateway with Microsoft Exchange Connector for Novell GroupWise.)

•

Define Additional Properties - Select the corresponding check box to define further settings.

Figure B.5

Creating the Novell GroupWise API Gateway

8.

The GroupWise Gateway/Internet Agent:Exchange Gateway dialog box appears next. Click Optional Gateway Settings, and then, under Directory Sync/Exchange, select Exchange to enable directory synchronization with Exchange 2003. Connector for Novell GroupWise controls the synchronization process.

9.

To support delivery reports and other status messages, click Yes under Convert Status To Messages.

10. In the Outbound Status Level list, click Full, and then click Required Parameters to switch to the Required Parameters tab.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 259

11. Correct the information displayed under Gateway File Paths to match your API Gateway installation. You must specify absolute NetWare paths in the form <Server Name>/:\<Path> (for example, NWSERVER01/SYS:\PUBLIC\GRPWISE\DOMAIN\WPGATE\API41). 12. In the Addressing Format list, click Component, and then click OK to complete the configuration. The Exchange Gateway configuration object should now be listed in the NetWare Administrator view beneath the GroupWise domain object.

Figure B.6

Setting required parameters for the Novell GroupWise API Gateway

Note In the gateway properties, under Gateway Time Settings, you can decrease the value for Idle Sleep Duration to one second to avoid delays in manual directory synchronization. The API Gateway checks its API_IN directory for inbound messages in intervals according to the Idle Sleep Duration setting. The default value is 30 seconds.

To create an external foreign domain for Exchange 2003 1.

In NetWare Administrator, open the Tools menu, and then select GroupWise View. Expand the GroupWise domain where the API Gateway for Exchange 2003 is installed (for example, CONTOSO_DOM).

260 Exchange Server 2003 Interoperability and Migration Guide

2.

Right-click the gateway object (for example, Exchange Gateway), select Create, and then, in the Create External Object dialog box, select External Domain.

Figure B.7

Creating an external domain for an Exchange 2003 organization

3.

Under External Domain Name, type Exchange. This is the default domain name assigned to Exchange users. You must change the proxy address generation rules if you choose a different name.

4.

Under Domain Type, select External Foreign.

5.

Ensure that Version is set to 4.x (because the API Gateway is version 4.1), and set Time Zone to the time zone of the Exchange 2003 server that runs Connector for Novell GroupWise. Under Link To Domain, list the API Gateway's GroupWise domain (for example, CONTOSO_DOM).

6.

Click Create and then verify that a foreign domain object is created in the GroupWise tree.

7.

Right-click the API Gateway's GroupWise domain (for example, CONTOSO_DOM), and then select Link Configuration.

8.

In the link configuration tool, right-click the newly created external domain (for example, Exchange), and then select Edit.

9.

In the Link Type list, select Gateway.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 261

10. In the Gateway Link list, ensure that the API Gateway that connects the GroupWise domain to Exchange 2003 is listed (for example, Exchange Gateway), and then click OK.

Figure B.8 Creating a link to the external domain for an Exchange 2003 organization 11. Close the link configuration tool. In the Links Have Changed dialog box, click Yes to save the link changes for the GroupWise domain.

To set connector permissions in Novell NetWare 1.

In the NetWare Administrator View, right-click the organizational unit in which you want to create the gateway account, and then select the Create command.

2.

In the New Object dialog box, double-click User. In the Create User dialog box, under Login Name, type Exchange, under Last Name, type Server, and then select the Define Additional Properties check box.

3.

Click Create, and then, in the User : Exchange dialog box, click Password Restrictions.

4.

Clear the Allow User To Change Password check box, select Require A Password, verify that the displayed Minimum Password Length matches your company's security policies, and then click Change Password.

262 Exchange Server 2003 Interoperability and Migration Guide

5.

In the Change Password dialog box, under New Password and Retype New Password, type a password, and then click OK.

Figure B.9 Creating a Novell NetWare account for Connector for Novell GroupWise 6.

Click Rights To Files And Directories, and then, under Volumes, click Show. In the Select Object dialog box, select the NetWare volume where you installed the API Gateway (for example, NWSERVER01_SYS)—you might need to navigate through the NDS tree to find the server—and then click OK.

7.

If a NetWare Administrator dialog box appears informing you that there are a large number of directory entries on this volume, click Yes.

8.

Under Files And Directories, click Add, and then navigate through the directories to select the API Gateway's root directory (for example, NWSERVER01/SYS:\mail\gwdom\wpgate\API41). Grant the Exchange account all rights to this directory (except Supervisor and Access Control), and then click OK.

9.

To create the NTGATEWAY group, right-click the organizational unit, and select Create.

10. In the New Object dialog box, double-click Group. In the Create Group dialog box, type NTGATEWAY. 11. Select the Define Additional Properties check box, and then click Create.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 263

12. Click Members, click Add to select the connector account (for example, Exchange) in the Select Object dialog box, and then click OK.

Figure B.10

Creating the NTGATEWAY group for Connector for Novell GroupWise

13. Click OK to close the Group : NTGATEWAY dialog box. Note It is a good idea to log on to Novell NetWare manually using the connector's NetWare account to test access to the API Gateway directory. You must be able to create, read, write, and delete files. If Connector for Novell GroupWise cannot connect to NetWare, the Router for Novell GroupWise service reports the following error in the application event log (Event ID 5017): "Error occurred when logging on NetWare server. The system error code is 1317. The specified user does not exist."

To start and test the API Gateway 1.

At the System Console of your NetWare server, type API, and press ENTER to start the API Gateway's NLM. Note The API.ncf file is written during the installation of Patch 2 for API NLM. Without the patch, you cannot use the API command to start the gateway. If you do not have the patch, start the API's Gateway NLM using the following command: load \NGWAPI.NLM (for example, load SYS:\API41\NGWAPI.NLM).

2.

On your workstation, start the Novell GroupWise client and log on to your Novell GroupWise mailbox. Compose a new message, address it to Exchange.First Administrative Group.Administrator, and then send it. Note You cannot perform this step directly on the Exchange server because the MAPI subsystem has not been prepared yet. The Novell GroupWise client requires MAPI, and the MAPI subsystem is installed during the installation of Exchange Server 2003. If you are performing these steps in a

264 Exchange Server 2003 Interoperability and Migration Guide

test environment without a separate workstation, perform the API Gateway test after you install Exchange 2003.

3.

The API Gateway should place the message body in form of a .bdy file in the \ATT_OUT directory, and the message header should be in an .api file in the \API_OUT directory.

4.

Copy the .bdy file into the \ATT_IN directory. (It is important to copy the message body before you copy the header.)

5.

Open the .api file in Notepad and change the mail header information, as shown in the following sample listing (your sender and recipient information might be different): WPC-API= 1.2; Header-Char= T50; Msg-Type= MAIL; From-Text= Exchange Test; From= WPD= Exchange; WPPO= First Administrative Group; WPU= Administrator; LN= admin; S= admin; ; To= WPD= CONTOSO_DOM; WPPO= CONTOSO_PO; WPU= admin; WPPONUM= 1; WPUNUM= 1; CDBA= 0001:0001; ; All-To= WPD= CONTOSO_DOM; WPPO= CONTOSO_PO; WPU= admin; WPPONUM= 1; WPUNUM= 1; ; Msg-Id= 39B424B2.CFE6.0001.000; To-Text= NGWAPI; Subject= API Gateway Test; <… further text …>

6.

Save the .api file in \API_IN. It is convenient to use the original file name, although the file name and extension actually do not need to be retained.

7.

On the Novell GroupWise client, verify that you have received the test message. For subsequent tests, you must copy the .bdy file into the \ATT_IN directory again before you save the .api file in \API_IN.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 265

8.

After you have finished your tests, delete the .bdy and .api files from the API Gateway directory.

Figure B.11

Testing the Novell GroupWise API Gateway

Installing and Configuring Connector for Novell GroupWise After you configure your Novell GroupWise environment, you can install and configure Connector for Novell GroupWise on an Exchange 2003 server. This includes installing the connector, which you can do as part of the server setup or afterwards, when you start the Exchange Setup program on a server where Exchange 2003 is already installed. For the purposes of these instructions, it is assumed that you are performing the connector installation during the initial server setup.

Prerequisites Ensure that your environment meets the following requirements: •

You already have an existing Microsoft Windows® network, including an Exchange organization, and the Active Directory® directory service is deployed.

•

You have Exchange Administrator permissions to install an Exchange 2003 server in the Exchange organization.

•

In Exchange System Manager, you have selected the Display routing groups and Display administrative groups options on the properties page for the organization object.

Ensure that the server on which you install Exchange 2003: •

Is running Windows Server 2003.

•

Has network connectivity to the Novell NetWare server running the Novell GroupWise API Gateway.

•

Can resolve the name of the Novell NetWare server.

266 Exchange Server 2003 Interoperability and Migration Guide

•

Has Novell NetWare Client for Windows installed.

•

Lists you as a member of the Administrators group on the server on which you install Exchange 2003.

To install Exchange 2003 with Connector for Novell GroupWise 1.

Insert the Exchange 2003 CD into the CD-ROM drive of a computer running Windows Server 2003.

2.

At a command prompt, type cd e:\setup\i386, where e is the drive letter for the CD-ROM drive.

3.

Type setup.exe and press ENTER.

4.

On the Microsoft Exchange Installation Wizard Welcome page, click Next.

5.

On the License Agreement page, if you agree with the terms of the license agreement, click I agree, and then click Next.

6.

On the Product Identification page, enter your CD key and then click Next.

7.

On the Component Selection page, in the Action drop-down list next to Exchange 2003, click Custom.

8.

In the Microsoft Connector for Novell GroupWise drop-down list, click Install, and then click Next.

Figure B.12 9.

Installing Connector for Novell GroupWise

If you are installing your first Exchange 2003 server, an Installation Type page appears. Ensure that Create a new Exchange Organization is selected, and click Next.

10. If you are creating a new Exchange organization, on the Organization Name page, enter an organization name, such as Contoso, and click Next. 11. On the Licensing Agreement page, if you agree, click I agree that I have read and will be bound by the license agreements for this product, and then click Next. 12. On the Component Summary page, ensure that Connector for Novell GroupWise is selected, and then click Next.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 267

13. If a Microsoft Exchange Installation Wizard message box appears informing you that your domain has been identified as an insecure domain for mail-enabled groups with hidden distribution list membership, click OK. 14. After Setup completes successfully, click Finish.

To enable and customize Novell GroupWise proxy addresses 1.

Start Exchange System Manager: On the Start menu, point to All Programs, point to Microsoft Exchange, and then click System Manager.

2.

Expand Recipients, and then click Recipient Policies.

3.

In the details pane, right-click Default Policy, and then click Properties. You can also create a new recipient policy.

4.

On the policy's E-Mail Addresses (Policy) tab, select the GWISE check box (this enables the address), ensure that the GWISE address entry is selected, and then click Edit.

5.

In the Address box, modify the address format. For example, you can set the address format to Exchange.First Administrative Group.&d. A user whose display name is Birgit Seidl receives a Novell GroupWise address of: Exchange.First Administrative Group.Birgit Seidl. For more information about placeholders in GWISE address generation rules, see Chapter 3, "Interoperating with and Migrating from Novell GroupWise Messaging Infrastructures."

6.

After you configure the address formula, click OK.

Figure B.13

Customizing GWISE proxy address generation

7.

In the Default Policy Properties dialog box, click OK.

8.

A message box appears asking whether you want to update all corresponding recipient e-mail addresses to match the new addresses. To run the Recipient Update Service immediately, click Yes. To update the addresses the next time the Recipient Update Service runs, click No. Non-Exchange addresses are always updated, even if you made manual changes to specific addresses.

268 Exchange Server 2003 Interoperability and Migration Guide

9.

Wait for the Recipient Update Service to populate the Exchange address lists. The time required to populate the lists varies depending on the update interval set on the service.

To configure Connector for Novell GroupWise 1.

In Exchange System Manager, expand Administrative Groups, expand Routing Groups, and expand the First Routing Group. Expand the Connectors container, right-click Connector for Novell GroupWise, and then click Properties.

2.

On the General tab: a.

In the API Gateway Path box, type the full path to your Novell GroupWise API Gateway directory in Universal Naming Convention (UNC), including the server name. For example: \NWSERVER01\SYS\Mail\GWDom\WPGate\API41.

b.

Under Netware Account, click Modify. Type the account name in the NetWare Account box (for example, Exchange). Under Password and Confirm Password, enter the password that was defined in NetWare Administrator.

c.

Under Message Size specify a maximum size for messages that are allowed to pass this Connector for Novell GroupWise instance, or accept the default setting of No Limit.

d.

In the Delivery Order list, choose the order in which messages are to be delivered from Exchange 2003 to Novell GroupWise. The order you specify controls the sequence in which Exchange messages are placed in the MTS-OUT queue by the Exchange message transfer agent (MTA), and hence the sequence in which messages are delivered to the API Gateway. The options are: •

Priority High priority messages, such as urgent messages, are delivered to the outbound queue first. This is the default setting.

•

FIFO Messages are delivered to the outbound queue on a first in, first out (FIFO) basis.

•

Size Smaller messages are delivered to the outbound queue before larger messages.

Figure B.14

Connector for Novell GroupWise General tab settings

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 269

3.

On the Address Space tab: a.

Click Add to add the address space for Novell GroupWise.

b.

On the Add Address Space tab, click GWISE, and then click OK.

c.

On the Novell GroupWise Address Space Properties tab, in the Address box, type * to allow all users to connect to Novell GroupWise using Connector for Novell GroupWise, and then click OK.

Figure B.15 4.

Configuring the GWISE address space

Click OK to close the Connector for Novell GroupWise Properties dialog box and apply the settings.

To start Connector for Novell GroupWise 1.

Start the Services tool: Click Start, point to All Programs, point to Administrative Tools, and then click Services.

2.

Right-click Microsoft Exchange Connector for Novell GroupWise, and then click Start.

270 Exchange Server 2003 Interoperability and Migration Guide

3.

Verify that Connector for Novell GroupWise starts successfully, and then close the Services tool.

Figure B.16

Starting Connector for Novell GroupWise

Configuring Directory Synchronization After you configure Connector for Novell GroupWise, you can synchronize directories between Novell GroupWise and Exchange 2003 (Active Directory). It is recommended that you test the directory synchronization process manually to ensure that everything works as expected.

Prerequisites Ensure that your environment meets the following requirements: •

You have Exchange Administrator permissions.

•

You have network connectivity to the Novell NetWare server running Novell GroupWise.

•

You can resolve the name of the Novell NetWare server running Novell GroupWise.

•

You have installed and configured the Novell GroupWise client software.

•

You have installed and configured Connector for Novell GroupWise.

To configure directory synchronization with Novell GroupWise 1.

In Exchange System Manager, right-click Connector for Novell GroupWise, and then click Properties.

2.

On the Import Container tab:

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 271

a.

To specify the Active Directory container (or organizational unit) to which Novell GroupWise users are imported, click Modify. It is recommended that you create a special organizational unit for all of your Novell GroupWise users and select that organizational unit here.

b.

On the Choose a container tab, browse to the container to which you want to import Novell GroupWise users. Click the container, and then click OK. Note You might receive an error message that reads, "The machine account must be granted permission to create and modify recipients in the selected import container. Continue?" If you receive this error message, click Yes. This is necessary for directory synchronization from Novell GroupWise to Exchange 2003 to work. When you click Yes, you add the computer account with the permissions required to manipulate objects in the selected container.

c.

In the When replicating a mailbox whose primary Windows account does not exist in the domain list, choose one of the following options for Active Directory to use when new users are imported: •

Create a disabled Windows user account

•

Create a new Windows user account

•

Create a Windows contact

This setting applies only to new users. If you change this setting later, it does not affect Novell GroupWise users who are already replicated to Active Directory. If you are not sure which option to choose, click Create a disabled Windows user account or Create a Windows contact. Click Create a new Windows user account only if Novell GroupWise users are logging on to the Windows domain. d.

Under Filtering, choose one of the following options to determine which GroupWise directory entries to replicate to Active Directory: •

Import all directory entries

•

Only import directory entries of these formats

•

Do not import directory entries of these formats

The default setting, Import all directory entries, imports all GroupWise directory objects with a visibility set to System in GroupWise without applying any filters. The remaining two options allow you to define a filter when you click the New button to display the Import Filter dialog box. In the Import Filter dialog box, you can use wildcard characters (asterisk (*) and question mark (?)) to create your filter, where an asterisk denotes any number of characters of any value, and a question mark denotes one character of any value. For example, the following filter affects only the recipients at CONTOSO_PO in the CONTOSO_DOM domain: CONTOSO_DOM.CONTOSO_PO.*

272 Exchange Server 2003 Interoperability and Migration Guide

Figure B.17 3.

Configuring inbound directory synchronization

On the Export Containers tab: a.

To specify which groups or organizational units to export from Active Directory to the Novell GroupWise directory, click Add.

b.

On the Choose a container tab, click the organizational unit that you want to export to the Novell GroupWise directory, and then click OK. Note You might receive an error message that reads, "The machine account must be granted permission to read the deleted recipients in the selected domain. Continue?" If you receive this error message, click Yes. This is necessary for directory synchronization from Novell GroupWise to Exchange 2003 to work. When you click Yes, you add the computer account with the permissions required to manipulate objects in the selected container.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 273

c.

Repeat the preceding two steps for each organizational unit that you want to export. Nested organizational units are not selected for export if you select the parent organizational unit. You must select each organizational unit individually.

Figure B.18 4.

Selecting organizational units to export

On the Dirsync Schedule tab: a.

In the Exchange-GroupWise directory update schedule list, select the schedule for directory synchronization. Connector for Novell GroupWise performs the directory synchronization. Do not schedule synchronization during peak traffic hours, because it can slow message throughput. If your directory information changes infrequently, schedule synchronization for once a day. If your directory information changes frequently, schedule synchronization for two or more times a day.

274 Exchange Server 2003 Interoperability and Migration Guide

b.

Click Customize to schedule synchronization for a period other than those provided by default in the Exchange-GroupWise directory update schedule list.

Figure B.19 5.

Selecting a synchronization schedule

Click OK to close each dialog box.

To test directory synchronization manually 1.

In Exchange System Manager, right-click Connector for Novell GroupWise, and then click Properties.

2.

On the Dirsync Schedule tab: a.

Under Exchange to GroupWise directory synchronization, click Immediate full reload. In the Exchange System Manager message box informing you that a process has been started to synchronize the directories, click OK. This process synchronizes directory objects from Active Directory to the Novell GroupWise directory.

b.

Under GroupWise to Exchange directory synchronization, click Immediate full reload. Again, a message box appears informing you that directory synchronization has begun. This process synchronizes directory objects from the Novell GroupWise directory to Active Directory. Click OK.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 275

Installing and Configuring Calendar Connector in a Novell GroupWise Environment Use the following procedures to configure Microsoft Exchange Calendar Connector so that users using either Exchange or Novell GroupWise can access each other's free/busy information. You install Calendar Connector on a server running Exchange. The most straightforward option is to install Calendar Connector on the server running Connector for Novell GroupWise.

Prerequisites Ensure that the server on which you install Calendar Connector meets the following requirements: •

The server is running Exchange Server 2003.

•

The server running Exchange 2003 has a local replica of the SCHEDULE+ FREE BUSY public folder.

•

The server is part of the same routing group as the server running Connector for Novell GroupWise.

•

You have Exchange Administrator permissions, and you are a member of the Administrators group on the computer on which you install Calendar Connector.

•

You have network connectivity to the Novell NetWare server running the Novell GroupWise API Gateway.

To install Calendar Connector 1.

Insert the Exchange Server 2003 CD into the CD-ROM drive of the server running Exchange 2003.

2.

At a command prompt, type cd e:\setup\i386, where e is the drive letter for the CD-ROM drive.

3.

Type setup.exe, and then press ENTER.

4.

On the Microsoft Exchange 2003 Installation Wizard Welcome page, click Next.

5.

On the Component Selection page, in the Action list next to Microsoft Exchange, click Change.

6.

In the Action list next to Microsoft Exchange Messaging and Collaboration Services, click Change.

276 Exchange Server 2003 Interoperability and Migration Guide

7.

In the Microsoft Exchange Calendar Connector list, click Install, and then click Next.

Figure B.20

Installing Calendar Connector

8.

On the Installation Summary page, verify your installation choices, and then click Next.

9.

After the installation is complete, click Finish.

To add a local replica of the SCHEDULE+ FREE BUSY public folder 1.

In Exchange System Manager, expand Administrative Groups, expand the administrative group that contains the server running Exchange with Calendar Connector (for example, First Administrative Group), and then expand Folders.

2.

Expand Public Folders. If you do not see the SCHEDULE+ FREE BUSY public folder, right-click Public Folders, and then click View System Folders.

3.

Expand Public Folders, expand SCHEDULE+ FREE BUSY, right-click the public folder that refers to your administrative group that contains the Exchange server running Calendar Connector (for example, EX:/o=Contoso/ou=First Administrative Group), and then click Properties.

4.

On the Replication tab, click Add.

5.

On the Select a Public Store page, select the server running Exchange 2003 with Calendar Connector, and then click OK.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 277

6.

In the Public folder replication interval list, click Always Run. This causes replication to occur whenever there is a change in free/busy information. Click OK.

Figure B.21

Configuring free/busy information replication

To configure Calendar Connector 1.

In Exchange System Manager, expand Administrative Groups, expand the administrative group that contains the server running Exchange with Calendar Connector (for example, First Administrative Group), expand Routing Groups, expand the routing group in which you installed Calendar Connector (for example, First Routing Group), expand Connectors, right-click Calendar Connector, and then click Properties.

2.

On the General tab: a.

Next to the Connector used to import users into Active Directory box, click Modify.

b.

In the Select Exchange Notes or Groupwise Connector dialog box, select the Connector for Novell GroupWise instance that is used to connect to the Novell GroupWise API Gateway, and then click OK.

c.

In the Number of days of free/busy information to request from foreign calendars box, enter the number of days that users are able to see free/busy information for users on the foreign messaging server. Free/busy information beyond the number of days specified is not retrieved by Calendar Connector and appears as free, even if meetings are scheduled during this time. Remember that the maximum value for GroupWise is 389 days.

d.

In the Maximum age in minutes of foreign free/busy data in Exchange that can be used without querying the foreign calendar box, enter the age limit for free/busy information in minutes. If the free/busy information is beyond the specified number of minutes and a user requests the information, Calendar Connector queries the non-Exchange messaging system for updated data. If the free/busy information is within the specified number of minutes, Calendar Connector uses the current free/busy information.

278 Exchange Server 2003 Interoperability and Migration Guide

e.

In the Maximum number of seconds to wait for response from foreign calendars box, enter the number of seconds that you want Calendar Connector to wait for a response after it requests an individual user's free/busy information. Set this to a low number, because each recipient on a meeting request is handled in turn, and a long response interval can cause the mail client to stop responding as it proceeds down the list of recipients.

Figure B.22 3.

Setting the General tab Calendar Connector options

On the Calendar Connections tab: a.

Click New.

b.

In the Calendar Type dialog box, click Novell GroupWise, and then click OK.

c.

In the GroupWise Calendar Connection dialog box, in the GroupWise API Gateway box, type the domain and gateway name of the Connector for Novell GroupWise that interfaces with the API Gateway. Do not include the certifier information. For example, if your Novell GroupWise domain name is CONTOSO_DOM, and the API gateway name is Exchange Gateway, then type CONTOSO_DOM.Exchange Gateway.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 279

d.

Click OK.

Figure B.23 4.

Configuring the calendar connection to Novell GroupWise

On the Schedule tab, click Always. This causes Calendar Connector to create a free/busy record for Novell GroupWise recipients in the Exchange public folder. This happens every 15 minutes for new recipients. Alternatively, click Selected times to specify a custom time for the connector to create new records in the server's public folder. Click OK.

To start the Calendar Connector service 1.

Open the Services Microsoft Management Console (MMC) snap-in: Click Start, point to All Programs, point to Administrative Tools, and then click Services.

2.

In the details pane, right-click Microsoft Exchange Calendar Connector, and then click Start.

280 Exchange Server 2003 Interoperability and Migration Guide

3.

The default startup type for Calendar Connector is manual. You should change the startup type to Automatic. To do this, right-click Microsoft Exchange Calendar Connector, and then click Properties. In the Startup type list, click Automatic, and then click OK. The next time the server starts, the Calendar Connector service starts automatically.

Figure B.24

Starting Calendar Connector

Migrating from Novell GroupWise to Exchange Server 2003 The following procedures explain how to migrate a group of users from Novell GroupWise to Exchange 2003. The guidelines are recommended for most migrations, and consist of extracting data from the server running Novell GroupWise and immediately importing it into Exchange 2003. To migrate data from Novell GroupWise to Exchange 2003, the Exchange Migration Wizard requires access to the mailbox for each user who is to be migrated. Your users must grant full proxy access to their mailboxes using the Novell GroupWise client.

Prerequisites Ensure that the server on which you run the Exchange Migration Wizard meets the following requirements: •

The server is running Exchange Server 2003.

•

If you have configured Connector for Novell GroupWise and directory synchronization, stop the Connector for Novell GroupWise service. This is necessary to prevent directory synchronization from propagating address list changes before you verify that the migration is successful.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 281

•

You have installed and configured the Novell GroupWise client software. It is recommended that you install Novell GroupWise 5.2.5 on the migration server.

•

You have network connectivity to the Novell NetWare server running Novell GroupWise. It is recommended that you install Novell NetWare 4.8 on the migration server.

•

You have administrative permissions in Exchange 2003, Novell NetWare, and Novell GroupWise.

To grant full proxy access to a user mailbox using the Novell GroupWise client 1.

Start Novell GroupWise: Click Start, point to All Programs, point to GroupWise 5, and then click Novell GroupWise.

2.

On the Tools menu, click Options, and then double-click Security.

3.

On the Proxy Access tab, add the account that is being used to migrate the mailbox into the Access list. For example, in Name, type admin and then click Add User.

4.

Highlight the account that you added, and select all of the Access Rights listed below. Click OK.

Figure B.25 5.

Setting full proxy access to a GroupWise mailbox

Ask each Novell GroupWise user who is being migrated to perform these same steps.

To migrate users and mailboxes from Novell GroupWise to Exchange 1.

On the server running Exchange 2003 with Connector for Novell GroupWise, stop the Connector for Novell GroupWise service. a.

Click Start, point to All Programs, point to Administrative Tools, and then click Services.

b.

In the details pane, right-click Microsoft Exchange Connector for Novell GroupWise, and then click Stop.

282 Exchange Server 2003 Interoperability and Migration Guide

2.

Start the Exchange Migration Wizard: Click Start, point to All Programs, point to Microsoft Exchange, point to Deployment, and then click Migration Wizard. Note It is assumed that you are using the Exchange server that you configured as described in the procedures earlier in this appendix. If so, this Exchange server is already configured to access Novell GroupWise. It is running the Novell GroupWise client and has network access to the Novell NetWare server running Novell GroupWise.

3.

On the Exchange Server Migration Wizard Welcome page, click Next.

4.

On the Migration page, click Migrate from Novell GroupWise 5.x, and then click Next.

Figure B.26

Specifying the migration type

5.

On the Novell GroupWise 5.x Migration page, click Next.

6.

On the Migration Procedure page: a.

Under Select the migration method, click One step migration (recommended).

b.

In the Path to migration files box, type the path to which the migration files are to be temporarily copied. Ensure that the hard disk drive has sufficient space to copy the mailboxes for all of the users you plan to migrate. You must specify a valid folder path. Click Next.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 283

Figure B.27 7.

On the Migration Destination page, click Migrate to a computer running Exchange Server. The Server list should now show the name of the Exchange 2003 server. In the Information store list, select the information store (now known as the Exchange store) to which to migrate the Novell GroupWise data, and then click Next.

Figure B.28 8.

Selecting the migration procedure

Selecting the migration destination

On the GroupWise Domain page: a.

In the Path box, type the UNC path to the Novell GroupWise domain on the Novell NetWare server. Typically, this is \NWSERVER01\SYS\Mail\GWDom, where NWSERVER01 is the Novell NetWare server on which Novell GroupWise is installed.

b.

In the Account Name box, type the name of the account that the Exchange Migration Wizard uses to access the Novell NetWare server that runs Novell GroupWise. The account you specify must have

284 Exchange Server 2003 Interoperability and Migration Guide

access to each user's Novell GroupWise mailbox. It is recommended that you use the account that is already used by Connector for Novell GroupWise or a Novell NetWare admin account. c.

In the Password box, type a Novell GroupWise password (if there is one) for the account used by Connector for Novell GroupWise. Click Next. Note You must specify a password only if the migration account has a GroupWise password. This is not the same password as the password for Novell NDS. To verify whether a GroupWise password must be specified, start the Novell GroupWise client for this account, and determine whether this user is being prompted for a password.

Figure B.29 9.

Specifying Novell GroupWise domain information

On the GroupWise Postoffice page, click the name of the Novell GroupWise post office from which you to migrate users. For example, if your post office is named CONTOSO_PO, click this entry, and then click Next.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 285

Figure B.30 users

Selecting the Novell GroupWise post office from which to migrate

10. It is recommended that you accept the defaults on the Migration Information page. To do so, click Next. If you do not want to accept the defaults, you can change the following options: a.

The Information to create mailboxes check box. When selected, this creates a new mailbox for users whom you migrated from Novell GroupWise to Exchange.

b.

The Mail and Phone Messages check boxes in the Message Types section. When these check boxes are selected, the user's mail and phone messages that are stored on the Novell GroupWise post office are migrated to Exchange. You can click either All to migrate all of the user's data, or Dated from to specify a date range of messages to migrate.

c.

The Appointments, Notes, and Tasks check boxes in the Calendar Items section. When these check boxes are selected, the user's calendar information is migrated to Exchange. You can select either All to migrate all of the user's calendar information, or Dated from to specify a date range of calendar information to migrate. Note Any meeting requests in users' inboxes that have not been accepted are migrated as text messages. Users must add these meetings to their calendars manually. Before you complete the migration, ensure that users accept any outstanding meeting requests.

286 Exchange Server 2003 Interoperability and Migration Guide

Figure B.31

Specifying the migration information

11. On the Account Migration page, select the Novell GroupWise users whom you want to migrate to Exchange 2003. The user ID that the Exchange Migration Wizard uses must have full proxy access to the mailbox of each user that you select. You can click Select All to select all users, or hold down the CTRL key and select users individually. Click Next.

Figure B.32

Selecting users to migrate to Exchange 2003

12. On the Container for New Windows Accounts page, click the Active Directory container or organizational unit to which users will be migrated. The Exchange Migration Wizard creates a new Active Directory account for each user in the specified container. Click Options.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 287

Figure B.33

Selecting the container to which to migrate accounts

13. On the Account Options page, click Generate random password, and then select the User must change password at next logon check box. This generates a random strong password for each user, which is stored in the Accounts.Password file in the \Program Files\Exchsrvr\Bin directory on the Exchange 2003 server. Alternatively, you can select other advanced options on this page, such as whether to create disabled user accounts that point to actual accounts in a different domain. For the purposes of this procedure, it is assumed that you are not selecting these advanced options. Click OK, and then click Next.

Figure B.34

Setting the account password options for the new user accounts

14. On the Windows Account Creation and Association page, you see a list of all the user accounts that will be created. In some instances, these are new accounts, but they might also be updates to existing

288 Exchange Server 2003 Interoperability and Migration Guide

accounts. For example, when you configured interoperability with Novell GroupWise, you might have decided to create disabled Windows accounts for each Novell GroupWise user. These disabled accounts appear for each corresponding user migrating from Novell GroupWise. Novell GroupWise users are matched with Exchange accounts based on their e-mail addresses. Verify that the accounts are matched correctly. If they are not, you can find the correct account using the Find Existing Account option. You can also choose to create a new account, using the Create New Account option, if the Exchange Migration Wizard matched an account incorrectly. After you finalize the account list, click Next.

Figure B.35 accounts

Matching Novell GroupWise accounts to new or existing Windows

Note This figure shows an example of Novell GroupWise users with disabled Windows accounts resulting from Exchange 2003 and Novell GroupWise directory synchronization. When these users are migrated, the accounts are matched to the users' e-mail addresses, and then the users' Novell GroupWise messaging data is imported to the users' mailboxes. You must enable the user accounts in Active Directory Users and Computers after migration, so that your users can log on to the Windows domain.

15. The Exchange Migration Wizard extracts the data from the server running Novell GroupWise and then imports it into Exchange and Active Directory. Migration can take some time, depending on the number of users and messages that are migrated, the speed of the server, network latency, and other factors. On the Migration Process page, verify that the migration process proceeds normally, and when the process completes, click Finish.

Appendix B: Configuration Procedures for Migrating from Novell GroupWise Messaging Functionality 289

Figure B.36

Finishing the Novell GroupWise migration

16. In the Exchange Server Migration Wizard message box informing you that the migration is complete, click OK.

To check the application event log for migration information 1.

On the Exchange 2003 server that performed the migration, click Start, point to All Programs, point to Administrative Tools, and then click Event Viewer.

2.

Click Application.

3.

Look for event log messages for which the source is MSExchangeMig. Double-click the message to view it. Then use the up and down arrows to scroll through the message.

To migrate Novell GroupWise Contacts, Appointments, and Tasks items 1.

Verify that you have received the Migrated Calendar Information import file with an .sc2 file attachment, which the Exchange Migration Wizard generates and sends to each individual user.

2.

In Microsoft Office Outlook®, on the File menu, click Save Attachments.

3.

Type the location and file name for the attached file, and then click Save.

4.

On the File menu, click Import and Export.

5.

Click Import from another program or file, and then click Next.

6.

Click Schedule Plus Interchange and then type the path and file name of the file that you want to import.

7.

Under Options, click Do not import duplicate items to ensure that any previously imported items are not duplicated, and then click Next.

290 Exchange Server 2003 Interoperability and Migration Guide

8.

On the next tab, verify the import actions that will be performed. You can click Map Custom Fields to customize the mapping of information from the import file to Outlook contacts, appointments, or tasks, and you can click Change Destination, to specify a destination folder. By default, Outlook imports the information into the standard Contacts, Calendar, and Tasks folders.

Figure B.37 Importing Novell GroupWise Contacts, Appointments, and Tasks items into Outlook 9.

Click Finish to complete the calendar migration.

10. In the Microsoft Office Outlook message box informing you that you have Schedule+ data stored on the server, click Yes to delete the server copy of this data.

A P P E N D I X

C

Configuration Procedures for Migrating from a Non-Exchange Messaging System

This appendix contains detailed step-by-step instructions for the following: •

Connecting Exchange 2003 to a non-Exchange messaging system that supports Lightweight Directory Access Protocol (LDAP) and Internet Message Access Protocol version 4 (IMAP4)

•

Performing semi-automated directory synchronization

•

Migrating mailboxes from the legacy non-Exchange messaging system to Exchange 2003 Note In the following procedures, it is assumed that you are running a messaging system that supports Simple Mail Transfer Protocol (SMTP) or X.400 for message transfer. Because no further assumptions can be made about your non-Exchange messaging system, specific details about how to configure your non-Exchange messaging environment cannot be provided. For configuration details, consult the administrator documentation for the non-Exchange messaging system that you want to connect to. For information about how to verify that messages can be transferred to a non-Exchange messaging system through SMTP, see Chapter 4, "Interoperating with and Migrating from Other Non-Exchange Messaging Systems."

Configuring an SMTP Connector in Exchange 2003 Because SMTP is the native transport mechanism for Exchange Server 2003, you do not need to install a separate connector component to configure an SMTP connector. In addition to configuring the SMTP connector to a non-Exchange messaging system, you might also want to specify the message formats that the non-Exchange messaging system supports.

Prerequisites Ensure that your environment meets the following requirements: •

You have an existing Windows network, including an Exchange organization and Active Directory deployment.

•

You can connect to TCP port 25 on the remote SMTP host. Use telnet.exe to verify that the remote SMTP host is responding with a welcome message when you connect. For details about how to test SMTP

292 Exchange Server 2003 Interoperability and Migration Guide

connectivity using telnet.exe, see Chapter 4, "Interoperating with and Migrating from Other NonExchange Messaging Systems." •

You have Exchange Administrator permissions to configure connector components in the Exchange organization.

•

In Exchange System Manager, you have selected the Display routing groups and Display administrative groups options on the properties page for the organization object.

To configure an SMTP connector to a non-Exchange messaging system 1.

Start Exchange System Manager from the Microsoft Exchange program group.

2.

In Exchange System Manager, expand Administrative Groups, expand the First Administrative Group container, expand Routing Groups, and then expand the First Routing Group container.

3.

Right-click the Connectors container, point to New, and then click SMTP Connector.

4.

On the General tab: a.

In the Name text box, type the name that you want to assign to this connector instance, for example, Connector to non-Exchange messaging system. (You can use a more descriptive name that clearly identifies the messaging system that you connect to.)

b.

Select the option Forward all mail through this connector to the following smart hosts and, in the corresponding text box that becomes available, type the name or IP address of the server to which all outgoing mail is routed for DNS resolution and mail delivery. If you enter an IP address, it must be enclosed in brackets, [ ], for example [192.168.202.101]. Brackets are not necessary if you specify the smart host by name. However, if you use DNS to route outgoing SMTP messages to their destinations, select the option Use DNS to route to each address space on this connector. In this case, you must ensure that all remote SMTP hosts are registered in mail exchanger (MX) records in DNS.

c.

Under Local bridgeheads, click Add, and then in the Add Bridgehead dialog box, select the Exchange server and SMTP virtual server that you want to use for this connector, and click OK. You can specify multiple bridgehead servers per SMTP connector.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 293

d.

Make sure the Do not allow public folder referrals check box is not selected. This setting only applies to SMTP connector instances that connect to another routing group in the same Exchange 2003 organization.

Figure C.1 5.

SMTP connector General tab settings

On the Address Space tab: a.

Click Add to add an address space for the remote SMTP system.

b.

In the Add Address Space dialog box, select SMTP, and then click OK.

c.

In the Internet Address Space Properties dialog box, in the E-mail domain text box, type the domain name that corresponds to your legacy system. For example, if non-Exchange users have an e-mail address of <user>@legacy.fabrikam.com, type legacy.fabrikam.com. Click OK. Important You must specify detailed SMTP domain information to route only those SMTP messages for recipients that exist in the non-Exchange messaging system over this connector instance. If you accept the default setting of (*), all SMTP messages, including all outbound Internet messages, will be routed over this connector instance.

d.

Under Connector scope, verify that Entire organization is selected, allowing all Exchange users to communicate with the users in the non-Exchange messaging system. If you select the Routing group option instead, each connector is restricted to the local routing group.

294 Exchange Server 2003 Interoperability and Migration Guide

e.

Verify that the option Allow messages to be relayed to these domains is not selected. This option enables Exchange to relay incoming messages through the SMTP connector to the domains that have their address spaces listed on this tab. The default is to block relays, except from those users and computers that are able to authenticate. If your SMTP virtual server is on the Internet, you should leave relaying disabled to prevent your server from being used to propagate unsolicited commercial e-mail.

Figure C.2

Configuring the SMTP address space

6.

On the Connected Routing Groups tab, ensure that no routing groups are specified, because this connector instance is not used to connect to another Exchange server in the organization.

7.

On the Delivery Restrictions tab, the default is that no restrictions are applied to this connector. Alternatively, you can restrict the connector to specific users or reject messages from specific users.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 295

8.

On the Content Restrictions tab, verify that messages with High, Normal, and Low priority are allowed to be delivered through the connector. Also verify that the options for allowing System messages and Non-system messages are enabled. System messages are delivery reports and non-delivery reports; nonsystem messages are regular messages from users, groups, and contacts.

Figure C.3 9.

Content restrictions for an SMTP connector instance

On the Delivery Options tab: a.

Under Connection time, the default is that the connector is configured to Always run. You can use this option to specify times when messages are sent through the connector by either selecting one of the standard values in the list or clicking Customize to create your own schedule.

b.

Select the Use different delivery times for oversize messages check box if you want to specify delivery times based on message size. In Oversize messages are greater than (KB), type the size, in kilobytes (KB), of messages you want to designate as oversized. The default is 2000 KB. Under Connection time, specify times when oversize messages are sent. In the current test environment, it is not necessary to enable this feature.

296 Exchange Server 2003 Interoperability and Migration Guide

c.

By default, the Queue mail for remote triggered delivery option is not selected. You can use this option to hold mail for clients that connect periodically to download messages. Click Add or Remove as necessary to select Windows 2000 or Windows Server 2003 accounts that will be allowed to trigger delivery in this domain. In this case, the client issues an ATRN or TURN command. The SMTP service then starts sending messages to the client domain. In the current test environment, it is not necessary to enable this feature.

Figure C.4

Delivery options for an SMTP connector instance

10. On the Advanced tab: a.

If the remote SMTP host does not support Extended SMTP (ESMTP), select the Send HELO instead of EHLO check box. By default, Exchange uses the EHLO command to start the SMTP session, which is an ESMTP command. Use this option to send the standard SMTP HELO start message instead.

b.

If the remote SMTP host requires authentication, click the Outbound Security button to configure outbound security and provide the authentication credentials required by the remote domain.

c.

If the remote SMTP host sends e-mail messages to Exchange 2003 without queuing the mail for remote triggered delivery, verify that the Do not send ETRN/TURN option is selected. The ETRN and TURN commands allow the local SMTP service to request that the remote server starts processing its mail queues for SMTP messages to the Exchange 2003 organization that are waiting at the remote SMTP host. If the remote SMTP host queues the mail for remote triggered delivery, select the Request ETRN/TURN when sending messages option, and configure the corresponding properties, such as connection times. You can also request dequeuing from a server other than the one to which the message is being sent with the Request ETRN/TURN from different server option.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 297

Figure C.5

Advanced options for an SMTP connector instance

11. Click OK to close the Properties dialog box and apply the settings. The newly configured connector is immediately available. Test the connector by sending e-mail messages to a user in the non-Exchange messaging system, and let the user reply to those test messages. To enable message transfer to Exchange users, you may have to specify your Exchange 2003 bridgehead server as an MX record for the SMTP domain of the Exchange 2003 organization in DNS, or as a smart host. Consult your administrator documentation for information about how to configure the non-Exchange messaging system.

To configure Internet message formats for a non-Exchange messaging system 1.

In Exchange System Manager, expand Global Settings and then select the Internet Message Formats container.

2.

Right-click the Internet Message Formats container, point to New, and then select Domain.

3.

In the Properties dialog box, on the General tab: a.

In the Name text box, type the name that you want to assign to this SMTP policy, for example, SMTP Policy for non-Exchange messaging system. (You can use a more descriptive name that clearly identifies the messaging system that you connect to.)

298 Exchange Server 2003 Interoperability and Migration Guide

b.

In the SMTP domain text box, type the SMTP domain name that refers to your non-Exchange messaging system, such as legacy.fabrikam.com.

Figure C.6 4.

General options for an SMTP policy

On the Message Format tab: a.

Under Message encoding, select the encoding option that the messaging clients of your nonExchange users support, either MIME or UUEncode. If the messaging client supports both encoding methods, select MIME.

b.

If your non-Exchange users work with Microsoft Office Outlook® in an IMAP4 configuration, select Provide message body as plain text. You will enable Exchange rich-text information in e-mail messages in a subsequent step. If the messaging clients of your non-Exchange users do not support MAPI but support HTML-formatted messages, select the Provide message body as HTML option or the Both option to provide the message body both as plain text and as HTML.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 299

c.

Under Character sets, verify that US ASCII is selected for MIME and Non-MIME.

Figure C.7 5.

Message format options for an SMTP policy

On the Advanced tab: a.

Under Exchange rich-text format, select Always use if the messaging clients of your nonExchange users support MAPI (such as Microsoft Outlook in an IMAP4 configuration). If users work with non-MAPI clients, select Never use. The default, Determined by individual user settings, allows the user to decide whether to send Exchange rich-text information.

b.

Under Message text word wrap, Never use is selected by default. If the messaging clients of your non-Exchange users impose a maximum number of characters per line in SMTP messages, select Use at column and specify the number of characters per line in the corresponding text box.

300 Exchange Server 2003 Interoperability and Migration Guide

c.

Verify that the check boxes for Allow out of office responses, Allow automatic replies, Allow automatic forward, Allow delivery reports, Allow non-delivery reports, and Preserve sender's display name on message are selected. When connecting to an internal SMTP messaging system, enable all of these features for maximum interoperability. When connecting to the Internet, you might want to disable certain features, such as out of office responses.

Figure C.8 6.

Advanced options for an SMTP policy

Click OK to close the Properties dialog box and apply the settings.

Configuring X.400 Connectivity in Exchange 2003 Because X.400 is supported as a transport mechanism in Exchange Server 2003, you do not need to install a separate connector to configure an X.400 connector. When connecting to a non-Exchange X.400 system, you must specify all configuration settings carefully and ensure that they match the configuration of the remote system. Otherwise, the message transfer agents (MTAs) will refuse to communicate with each other, and messages will not be transferred. It is vital that you test the connector configuration not by only sending messages from Exchange to a user in the X.400 system, but also by sending messages in the other direction, because message transfer in one direction does not indicate that message transfer in the other direction works as well. You must work closely with the remote administrator when you implement X.400 connectivity.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 301

Prerequisites Ensure that your environment meets the following requirements: •

You have an existing Windows network, including an Exchange organization, and Active Directory deployment.

•

You can connect to the remote MTA through TCP/IP. It is assumed that you are working in a TCP/IPbased environment. For information about how to configure an X.400 connector over X.25, see the Exchange 2003 product documentation.

•

You have Exchange Administrator permissions to configure connector components in the Exchange organization.

•

You have enabled the options to display routing groups and administrative groups in Exchange System Manager.

To configure an MTA transport stack for an X.400 connector 1.

In Exchange System Manager, expand Administrative Groups, expand the First Administrative Group container, expand Servers, and then expand the server object that corresponds to your bridgehead server (for example, SERVER01). Expand the Protocols container and then select X.400.

2.

Right-click the X.400 container, point to New, and then select TCP/IP X.400 Service Transport Stack.

3.

In the TCP (SERVER01) Properties dialog box, on the General tab: a.

In the Name text box, accept the suggested name TCP (SERVER01) or change the name according to your preferences.

b.

Under OSI address information do not define any connector address unless the remote X.400 administrator informs you that you must specify such information for your local MTA.

Figure C.9 4.

General options for an MTA transport stack

Click OK to close the Properties dialog box and apply the settings.

302 Exchange Server 2003 Interoperability and Migration Guide

To configure an X.400 connector to a non-Exchange messaging system 1.

In Exchange System Manager, expand Administrative Groups, expand the First Administrative Group container, expand Routing Groups, and then expand the First Routing Group container.

2.

Right-click the Connectors container, point to New, and then click TCP X.400 Connector.

3.

On the General tab: a.

In the Name text box, type the name that you want to assign to this connector instance, for example, Connector to an X.400 system. (You can use a more descriptive name that clearly identifies the messaging system that you connect to.)

b.

Under Remote X.400 name, click the Modify button, and then in the Remote Connection Credentials dialog box, specify the Remote X.400 name and Password. Type the password one more time under Confirm Password. Click OK. Note The MTA password is case-sensitive. If it is misspelled, connections cannot be established.

c.

Under X.400 transport stack, verify that the correct TCP transport stack is selected.

d.

Under Message text word-wrap, you can specify a maximum line length for the message body in characters. By default, text is not wrapped.

e.

If your non-Exchange users work with a MAPI-compliant messaging client, select the option Remote clients support MAPI. If you clear this check box, rich-text information, icons and their rendering positions, and OLE attachments and their rendering positions are discarded before message transfer.

f.

Verify that the option Do not allow public folder referrals is not selected. This option applies only to configurations in which an X.400 connector instance is used to connect to an Exchange routing group.

Figure C.10

General options for an X.400 connector

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 303

4.

On the Schedule tab, verify that the schedule is set to Always.

5.

On the Stack tab, specify transport address information about the remote X.400 system to which you want to connect. a.

Using the Remote host name option, specify the DNS name of the remote X.400 server to which you want to connect in the Address text box (for example: MTA1.FABRIKAM.COM). Alternatively, you can select the IP address option to specify the IP address of the remote X.400 MTA to which you want to connect (for example, 192.168.202.101).

304 Exchange Server 2003 Interoperability and Migration Guide

b.

Click the OSI Address button to further define the connection information in the OSI Address dialog box. Select Hexadecimal or Text for the display of the address information. Enter hexadecimal characters or alphanumeric characters for the T selector (transport service access point), for the S selector (session service access point), and for the P selector (presentation service access point) in the corresponding boxes according to the information obtained from the remote X.400 administrator. Click OK.

Figure C.11 6.

Stack options for an X.400 connector

On the Override tab, you can change the default X.400 transport stack attributes that the local Exchange MTA is using for a specific X.400 connector: a.

Under Local X.400 Service name, click the Modify button to override the local X.400 name and password in the server X.400 protocol properties.

b.

Under Connection retry values, you can specify connection retry parameters. In Maximum open retries, type a value for the maximum number of times that the system tries to open a connection before it sends a non-delivery report (NDR). The default is 144. In Maximum transfer retries, type a value for the maximum number of times that the system tries to transfer a message across an open connection. The default is 2. In Open interval (sec), type a value for the number of seconds the system waits after an error before attempting to reopen a connection. The default is 600. In Transfer interval (sec), type a value for the number of seconds the system waits after a message transfer fails before resending a message across an open connection. The default is 120. To restore the Exchange default values, click the Reset Default Value button.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 305

c.

Click the Additional Values button to set further options, including Reliable Transfer Service (RTS) values, association parameters, and transfer timeouts. RTS values determine message reliability parameters, such as the checkpoints to include in data and the amount of unacknowledged data that can be sent. Association parameters determine the number and duration of connections to the remote system. Transfer timeouts specify the amount of time to wait before issuing a non-delivery report (NDR) for different priority messages.

Figure C.12 7.

Override options for an X.400 connector

On the Address Space tab: Click Add to add an address space for the remote X.400 system. a.

In the Add Address Space dialog box, select X400, and then click OK.

b.

In the X.400 Address Space Properties dialog box, from the Country/Region (c) list box, select the country for the remote X.400 system, for example: US (United States). You should specify additional information, such as Administrative management domain name (a), Private management domain name (p), and Organization (o). Note It is important to specify detailed X.400 address information to route over this connector instance only those X.400 messages that are for recipients that exist in the X.400 messaging system.

306 Exchange Server 2003 Interoperability and Migration Guide

c.

Under Connector scope, verify that the connector is for the Entire organization so that all Exchange users can communicate with the users in the non-Exchange messaging system. Selecting the Routing group option restricts the connector to the local routing group.

Figure C.13 8.

Address Space information for an X.400 connector

On the Content Restrictions tab, verify that messages with High, Normal, and Low priority are allowed to be delivered through the connector. Leave the options for System messages and Non-system messages enabled. System messages are delivery reports and non-delivery reports; non-system messages are regular messages from users, groups, and contacts.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 307

Figure C.14 9.

Content restrictions for an X.400 connector

On the Connected Routing Group tab, ensure that no routing groups are specified, because this connector instance is not used to connect to another Exchange server in the organization.

10. On the Delivery Restrictions tab, the default is that no restrictions are applied to this connector. Alternatively, you can restrict the connector to specific users or reject messages from specific users. 11. On the Advanced tab: a.

When communicating with a remote X.400-88 MTA, ensure that the Allow BP-15 (in addition to BP-14) check box is selected to send BP-15 attachments formatted as file transfer body part (FTBP), which includes file name, size, and properties. Clear the check box when connecting to an X.400-84 MTA to send all attachments as BP-14 attachments (simple binary attachments).

b.

Clear the Allow Exchange contents check box to convert message format to standard P2/P22 X.400 format. If this option is enabled, Exchange 2003 sends message content formatted in the internal format for the Exchange Server, Message Database Encapsulated Format (MDBEF), which does not conform to X.400. You should keep this option enabled only when communicating with another Exchange MTA in the same Exchange 2003 organization, such as an Exchange server in another routing group.

c.

If the remote X.400 MTA supports sending and receiving messages over the same connection, enable the Two-way alternate check box.

d.

In the X.400 body part for message text list box, select the body part type for the text of the message. The body part type must be supported by the foreign system and primarily affects outbound messages. When you choose a body part type, you are choosing the alphabet used in the text. For example, body part type IA5 includes international alphabet number five (suitable for Swedish, Norwegian, German, and western European characters), whereas body part type ISO 6937 includes a set of 333 characters made up of Latin script plus non-spacing diacritical marks.

e.

Under X.400 conformance, specify the X.400 conformance of the X.400 connector according to the capabilities of the remote X.400 MTA (1984, 1988 X.410 mode, or 1988 normal mode). Consult the

308 Exchange Server 2003 Interoperability and Migration Guide

remote X.400 administrator to determine the correct setting. When communicating with an X.40092 MTA, select 1988 normal mode. f.

If you select the 1984 conformance, you must click the Global Domain Identifier button to configure Global Domain Identifier (GDI) information.

g.

In the Global Domain Identifier dialog box, specify the private management domain name (PRMD), the administrative management domain name (ADMD), and the Country Region. By default, the GDI is constructed from the local X.400 address space. You can view the default GDI for the connector in Exchange System Manager under Recipient Policies in the properties of the Default Policy for X.400 e-mail addresses. Click OK.

Figure C.15

Advanced settings for an X.400 connector

12. Click OK to close the Properties dialog box and apply the settings. 13. In the Exchange System Manager dialog box that informs you that you must configure both sides of the X.400 connection for message transfer to work, click OK.

Figure C.16

Completing the X.400 connector configuration

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 309

Performing Semi-Automated Directory Synchronization After you verify that message transfer works between Exchange 2003 and the non-Exchange messaging system, you can implement a semi-automated solution for directory synchronization to provide all users in the company with consistent and complete address lists in their messaging systems. It is assumed that you are using Exchange System Manager to extract directory information from the legacy messaging system and Active Directory and to import recipient information into Active Directory using Ldifde.exe. Warning Do not use Ldifde.exe on a production server without thorough testing on a reference system. Improper usage can cause serious problems. These problems may require you to reinstall Active Directory, Exchange Server 2003, or both. Microsoft cannot guarantee that problems that occur when creating, modifying, or deleting Active Directory objects using Ldifde.exe can be solved.

Prerequisites Ensure that your environment meets the following requirements: •

You have Exchange Administrator permissions.

•

You have permissions to read and create organizational units and user accounts in Active Directory.

•

The non-Exchange messaging system supports LDAP, and you have the required permissions to access the non-Exchange directory information.

To configure the Exchange Migration Wizard for an LDAP directory 1.

Start Windows Explorer and open the C:\Program Files\Exchsrvr\Bin directory.

2.

Open the mlmigad.ini file in Notepad.

3.

In the mlmigad.ini file, find the line ADSI_ObjectClass=inetOrgPerson. Edit this line to specify the object class that is used in your LDAP directory for user objects. The object class name inetOrgPerson applies to Sun One Directory Server (formerly known as Netscape LDAP Server). Other LDAP directory systems might use different class names. For example, the LDAP server for AltN MDaemon uses the object class name MDaemonUser. In this case, you must change the ADSI_ObjectClass to ADSI_ObjectClass=MDaemonUser. Consult the production documentation for your LDAP directory to determine the correct object class name. Note To export Exchange 2003 user information from Active Directory for import into the legacy messaging system, change the ADSI_ObjectClass to the following: ADSI_ObjectClass= organizationalPerson.

4.

Find the line ADSI_UserID=uid. If your LDAP directory uses different information for the user ID, edit this field accordingly. In the most general case, you can use the common name attribute to specify the user ID: ADSI_UserID=cn.

5.

Find the line ADSI_EmailAddress=mail. If your LDAP directory uses a different attribute name for the e-mail address, edit this field accordingly.

6.

Find the line ADSI_FullName=. Specify the full name attribute or the common name attribute so that the Exchange Migration Wizard can extract a proper display name; otherwise, the Exchange Migration

310 Exchange Server 2003 Interoperability and Migration Guide

Wizard uses the user's e-mail address to create the display name. Change this line to ADSI_FullName=cn.

Figure C.17 7.

Editing the mlmigad.ini file

Save the changes and close Notepad.

To extract directory information from an LDAP directory 1.

Start the Exchange Migration Wizard from the Deployment program group that you can find in the Microsoft Exchange program group.

2.

On the Exchange Migration Wizard Welcome page, click Next.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 311

3.

On the Migration page, select Migrate from Internet Directory (LDAP via ADSI), and then click Next.

Figure C.18

Migrating from an Internet directory

4.

On the Internet Directory Migration page, click Next.

5.

On the Migration Procedure page, select Extract migration files only. In the Path to migration files text box, specify the path to the directory where you want Exchange Migration Wizard to place the directory export files. For example, you can specify d:\ if your server has a drive D. Click Next.

Figure C.19 6.

Extracting migration files only

On the Access Information page, specify the following information, and then click Next: a.

In the Internet directory server name text box, specify the fully qualified domain name (FQDN) or IP address of the LDAP server that you want to connect to. If your LDAP directory requires you to

312 Exchange Server 2003 Interoperability and Migration Guide

specify a search base, you can add this information to the name, separated by a forward slash. For example, to access an LDAP directory on Server01 with a search base for an organization named Fabrikam, use the following information for the directory server name: server01/o=fabrikam, c=us. You can also specify organizational units, such as server01/ou=finance, o=fabrikam, c=us. b.

Verify that the Port number is correct. The default is 389, but your LDAP server might use a custom port number.

c.

Specify an Account name and Password if anonymous access to directory information is not enabled. The user account must have rights to bind to the LDAP directory, as well the rights to access, search, and read the directory.

d.

Select the Use secure authentication option if you must use Secure Sockets Layer (SSL) encryption to authenticate your logon credentials with the LDAP directory.

e.

Select the Use encryption option to encrypt all data transmission between the Exchange Migration Wizard and the LDAP directory using SSL.

Figure C.20 7.

Specifying account information to access the LDAP directory

On the Containers page, select the container from which to export recipient information, and then click Next.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 313

Figure C.21 8.

Specifying an export container

On the Account Migration page, select the users to export, and then click Next. You can use the Select All button to include all users. To select or clear multiple users, hold down the CTRL key while clicking the entry.

Figure C.22

Specifying users to export

314 Exchange Server 2003 Interoperability and Migration Guide

9.

On the Migration Progress page, verify that the operation completes successfully, and then click Finish.

Figure C.23

Completing the directory export

10. In the Exchange Server Migration Wizard dialog box informing you that the migration is complete and that you should check the application event log for further information, click OK.

To import directory information into Active Directory using Ldifde.exe 1.

Start Active Directory Users and Computers, right-click the domain object, such as Fabrikam.com, and then point to New and select Organizational Unit.

2.

In the New Object – Organizational Unit dialog box, type Remote SMTP Recipients in the Name text box, and then click OK.

Figure C.24 3.

A dedicated organizational unit for SMTP recipients

Start Windows Explorer and open the directory where the Exchange Migration Wizard placed the migration files (for example, D:\ADSI.001).

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 315

4.

Open the directory.pri file in Notepad and verify that it contains valid data.

Figure C.25 5.

A sample directory.pri file

Use the information from the directory.pri file to create a local data file (LDF) file for Ldifde.exe. The following is a sample LDF file: dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add objectClass: contact cn: Ted Bremer sn: Bremer givenName: Ted displayName: Ted Bremer mailNickname: Ted targetAddress: SMTP: [email protected] mail: [email protected] dn: CN=Hao Chen,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add objectClass: contact cn: Hao Chen sn: Chen givenName: Hao displayName: Hao Chen mailNickname: Hao targetAddress: SMTP: [email protected] mail: [email protected] dn: CN=Pilar Ackerman,OU=Remote SMTP Recipients,DC=fabrikam,DC=com changetype: add objectClass: contact cn: Pilar Ackerman sn: Ackerman givenName: Pilar

316 Exchange Server 2003 Interoperability and Migration Guide

displayName: Pilar Ackerman mailNickname: Pilar targetAddress: SMTP: [email protected] mail: [email protected]

Tip You can automate the conversion of .csv-based files, such as directory.pri, into LDF format by using a Microsoft Excel macro, as discussed in Chapter 1, "Understanding Interoperability and Migration."

6.

Save the file in the current directory as Importfile.ldf and then use the following command to import the data into Active Directory: ldifde -i -f c:\importfile.ldf -s Server01.

7.

Switch back to Active Directory Users and Computers, refresh the view, and verify that the recipient objects exist.

Figure C.26

Mail-enabled user accounts for non-Exchange users

Note For full directory synchronization, you must also export directory information about Exchange users from Active Directory and import this data into the legacy messaging system. You must perform this step manually or in a semi-automated way using tools that are included with your legacy messaging system. Administering or programming a non-Exchange messaging system is beyond the scope of this book.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 317

Migrating from an Internet Messaging System to Exchange Server 2003 The following procedures explain how to migrate a group of users from an Internet messaging system to Exchange 2003. These guidelines consist of extracting data from an IMAP4 server and immediately importing the data into Exchange 2003. To migrate data from an Internet messaging system to Exchange 2003, the Exchange Migration Wizard requires mailbox access for each user who is migrated. To provide this access, including information about the user accounts and passwords, you must create an imapusr.csv file. If you have performed an LDAP export using the Exchange Migration Wizard, as explained earlier in this appendix, you can find a basic imapusr.csv file in the resulting migration folder.

Prerequisites Ensure that the server on which you run the Exchange Migration Wizard meets the following requirements: •

The server is running Exchange Server 2003.

•

You have network connectivity to the Internet messaging system.

•

You have administrative permissions in Exchange 2003.

•

Using the Exchange Migration Wizard, you have exported recipient information from the Internet messaging system through LDAP.

To prepare the Exchange Migration Wizard for an Internet messaging system migration 1.

On the server running Exchange 2003, start Windows Explorer and open the D:\MAPI.001 folder, which is the folder that the Exchange Migration Wizard created earlier for the migration files.

2.

Open the file called imapusr.csv in Notepad. This file contains the following header fields: IMAP_Mailbox,SMTP_Address,IMAP_Password,IMAP_Server

3.

For each IMAP4 user that you want to migrate, you must specify the mailbox name, SMTP address, password, and the IMAP server on which the mailbox resides. You can specify the fully qualified server name or the IP address for the server. The values must be separated by commas. Warning Because the imapusr.csv file contains passwords in clear text, you must protect it from unauthorized disclosure. You should restrict access to this file to authorized users through NTFS permissions.

318 Exchange Server 2003 Interoperability and Migration Guide

Figure C.27 4.

Editing an imapusr.csv file for the Exchange Migration Wizard

Save the changes and close Notepad.

To migrate users and mailboxes from an Internet messaging system to Exchange 2003 1.

On the previously configured server running Exchange 2003, start the Exchange Migration Wizard from the Deployment program group that you can find in the Microsoft Exchange program group.

2.

On the Exchange Server Migration Wizard Welcome page, click Next.

3.

On the Migration page, select Migrate from Internet Mail (IMAP4), and then click Next.

Figure C.28

Specifying the migration type

4.

On the IMAP4 Migration page, click Next.

5.

On the Migration Procedure page: a.

Under Select the migration method, select One step migration (recommended).

b.

On the Migration Procedure page, in the Path to migration files text box, type a valid folder path to which the migration files are temporarily copied. Ensure that the hard disk drive has sufficient space to copy the mailboxes for all the users you migrate. Click Next.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 319

Figure C.29 6.

Selecting the migration procedure

On the Migration Destination page, select Migrate to a computer running Exchange Server. The Server list box should contain the name of the server running Exchange 2003. In the Information store list box, select the information store to migrate the mailbox data to, and then click Next.

Figure C.30

Selecting the migration destination

320 Exchange Server 2003 Interoperability and Migration Guide

7.

On the File Location page, in the User list file text box, type the UNC path to the imapusr.csv file that you edited earlier (for example, D:\ADSI.001\imapusr.csv). You can use the Browse button to select the file. Click Next.

Figure C.31 8.

Specifying the imapusr.csv file

On the Migration Information page, click Next. You can accept the defaults or change the following options: a.

The Information to create mailboxes check box. When selected, this creates a new mailbox for users migrated from the Internet messaging system to Exchange 2003.

b.

The Personal e-mail messages section. You can either select All to migrate all the user's data, or Dated from to specify a date range of messages to migrate.

Figure C.32

Specifying the migration information

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 321

9.

On the Account Migration page, select the users you want to migrate to Exchange 2003. You can click Select All to select all users, or hold down the CTRL key and select multiple users. Click Next.

Figure C.33

Selecting the users to migrate to Exchange 2003

10. On the Container for New Windows Accounts page, select the Active Directory container or organizational unit to which users will be migrated. The Exchange Migration Wizard creates a new Active Directory account in the specified container for each user who does not yet have an account in Active Directory. Click Options.

Figure C.34

Selecting the container to which to migrate accounts

11. On the Account Options page, select Generate random password, and then select the User must change password at next logon check box. This generates a random strong password for each user, which is stored in the Accounts.Password file in the \Program Files\Exchsrvr\Bin directory on the server running Exchange 2003. You can select other advanced options on this page, such as whether to

322 Exchange Server 2003 Interoperability and Migration Guide

create disabled user accounts that point to actual accounts in a different domain. For the purposes of this procedure, it is assumed that you are not selecting these other options. Click OK, and then click Next.

Figure C.35

Setting the account password options for the new user accounts

12. On the Windows Account Creation and Association page, there is a list of all the user accounts that will be created. In some instances, these are new accounts, but they can also be updates to existing accounts. For example, when you performed semi-automated directory synchronization, you might have created a mail-enabled Windows account or contact for each user. These accounts appear for each corresponding user migrating from the Internet messaging system. Internet mail users are matched with Exchange accounts based on their e-mail addresses. Verify that the accounts are matched correctly. If they are not, you can find the correct account using the Find Existing Account option. You can also choose to create a new account, using the Create New Account option, if the Exchange Migration Wizard matched an account incorrectly. After you finalize the account list, click Next.

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 323

Figure C.36 accounts

Matching Internet mail accounts to new or existing Windows

Note This figure shows an example of Internet mail users who had existing disabled mail-enabled Windows accounts resulting from semi-automated directory synchronization. When these users are migrated, the accounts are matched to the e-mail addresses for these users, and then the users' Internet messaging data is imported to the users' mailboxes. The user accounts in Active Directory Users and Computers must be enabled after migration occurs so that the users can log on to the Windows domain.

13. Migration Wizard extracts the data from the Internet messaging server and then imports it into Exchange and Active Directory. Migration can take some time, depending on the number of users and messages that are migrated, the speed of the server, network latency, and other such factors. On the Migration Process page, verify that the migration process proceeds normally, and when the process completes, click Finish.

324 Exchange Server 2003 Interoperability and Migration Guide

Figure C.37

Finishing the Internet mail migration

14. In the Exchange Server Migration Wizard dialog box informing you that the migration is complete, click OK.

To view the application event log for migration information 1.

On the server running Exchange 2003 that performed the migration, click Start, point to All Programs, point to Administrative Tools, and then click Event Viewer.

2.

Click Application.

3.

Look for event log messages with the source MSExchangeMig. Double-click the message to view it. Use the up and down arrow buttons to scroll through the message.

Figure C.38

An Exchange Migration Wizard event log entry

Appendix C: Configuration Procedures for Migrating from a Non-Exchange Messaging System 325

A P P E N D I X

D

Batch File and Command Line Migrations

Because the Exchange Migration Wizard is a single-threaded application, to increase the performance and speed of your migration, you can run your migration using a batch file process to migrate your data. This option is available only if you run the Exchange Migration Wizard from the command line. You can use the command line reference and the batch files (with examples provided later in this appendix) to increase the performance of your migration.

Command Line Reference Use the following switches, available in the Exchange Migration Wizard, to run your migration from the command line.

Syntax Mailmig [/C:File [/A:Account] [/P:Password] [/S] [/M] [/?/h/help]

Switches Table D.1 lists the command line switches. Table D.1 Command line switches Switch

Description

/C:File

The location of the control file. The control file is a text file containing parameters and their values, which are separated by commas.

/A:Account

The administrator account name for a Microsoft Mail for PC Networks or Novell GroupWise post office, or for a Lightweight Directory Access Protocol (LDAP) or IMAP server. For a Lotus Notes migration, Account is the path to the Notes ID file used for migration. This switch is not necessary for migration file import or for Lotus cc:Mail. For Exchange migration, type the name of an account that has administrative privileges for the mailboxes that you are migrating.

Appendix D: Batch File and Command Line Migrations 327

Switch

Description

/P:Password

The password for the administrator account on the Microsoft Mail for PC Networks, Lotus cc:Mail, or Lotus Notes post office; the LDAP or IMAP server; or the Novell GroupWise migration ID. The password is not necessary for migration file import.

/S:Silent mode

Silent mode. No error messages are displayed. All errors are written to the event log.

/M:Clone mode

Clone mode. Used for migrating from Exchange.

/?/h/help

Displays Help text.

Examples mailmig /M /C:d:\migrate\po72195.txt mailmig /C:salespo.txt /A:admin /P:katmanduKatmandu Note Running the Exchange Migration Wizard with /m only (for example, ..\mailmig /m) starts the migration wizard in clone mode.

Result Codes Depending on the success, the command line returns the following result codes: •

0 = Success. No errors or warnings

•

1 = Warnings. No errors

•

2 = Errors. Possible warnings

Control File Parameters Table D.2 lists the parameters used to set values in the control file. Table D.2 Parameters used to set values in the control file Parameter

Use

Description

Mode

Required when using the control file.

The mode for this migration. It must be the first line in the control file.

No default

Valid settings: FILE, MSMAILPC, CCMAIL, NOTES, GRPWISE, GRPWISE5, ADSI, and IMAP.

Note Set Mode to FILE when importing migration files.

328 Exchange Server 2003 Interoperability and Migration Guide

Parameter

Use

Description

Exchange 5.5

Required when Mode is set to EXCHANGE.

Whether the source server is running Exchange 5.5, or Exchange 2000 or Exchange 2003.

Default: TRUE

Valid settings: TRUE means the migration is from an Exchange 5.5 server. FALSE means the migration is from an Exchange 2000 or Exchange 2003 server. RestrictSearchtoSid Default: FALSE

Optional when Mode is set to EXCHANGE or IMPORT ONLY FROM PST.

Whether to match user objects based only on the object SID.

Valid settings: TRUE means to search for matching user objects based only on the object SID during the import phase of migration. FALSE means to accept all matches. SubjectFile No default

Optional when Mode is set to EXCHANGE. Valid setting is the path and file name of a file that consists of lists of subjects (in Unicode format).

ForcePwdChange

Optional

Default: FALSE

Valid settings: TRUE means that users must change their passwords. FALSE means that users do not have to change their passwords.

Normalized subject text is checked for a prefix match against any of the input subjects. If a match is found, the message is not copied to the destination. The file must end with a carriage return character and a line feed character. Whether to force users whose accounts were migrated to change their passwords.

Appendix D: Batch File and Command Line Migrations 329

Parameter

Use

Description

Function

Optional

Default: FULL

Used when Mode is set to MSMAILPC, CCMAIL, NOTES, GRPWISE, GRPWISE5, ADSI, or IMAP.

The migration function to perform.

Valid settings: FULL to perform a full migration (extract and import). EXTRACT to extract a user list file (Microsoft Mail) or to extract migration files (Lotus cc:Mail, Lotus Notes, Novell GroupWise release 4.x, Novell GroupWise release 5.x, LDAP, and IMAP). IMPORT to perform a Microsoft Mail import from a user list file. File No default

Required when Mode is set to FILE, CCMAIL, NOTES, GRPWISE, GRPWISE5, ADSI, or IMAP. Function is set to EXTRACT, IMPORT, or FULL. Valid settings: For IMPORT, specify the path and file name of the packing list or user list file. For EXTRACT or FULL, specify the path to the temporary directory to which migration files should be written (for CCMAIL, NOTES, GRPWISE, GRPWISE5, ADSI, or IMAP). For MSMAILPC EXTRACT, specify the path and filename of the new user list file to be created.

The path and file name of the packing list or user list file, or the path to the temporary directory to which migration files should be written.

330 Exchange Server 2003 Interoperability and Migration Guide

Parameter

Use

Description

Accounts

Required when Mode is set to CCMAIL, NOTES, ADSI, IMAP, or MSMAILPC (when a user list file is not specified by File). If the Accounts keyword is not used, the Exchange Migration Wizard will migrate all accounts from the specified post office.

A user list file with a listing of accounts to be migrated. Users may be listed by alias, X.500 address, or SMTP address. For an alias list, the format of each entry must match the name format as it appears in the Full Name column of the Exchange Migration Wizard Account Migration page. Each name is on one line and is followed by a carriage return and line feed. For X.500 or SMTP address lists, each entry should start with X500: or SMTP:, then the address, followed by a carriage return and line feed.

No default

Valid setting is a user list file.

Mailbox

Optional

Default: TRUE

Valid settings:

Whether to extract mailbox creation information and create the mailbox on Exchange.

TRUE means mailboxes are created and messages are imported. FALSE means messages are imported to existing mailboxes but new mailboxes are not created. Email

Optional

Default: TRUE

Ignored unless Mode is set to MSMAILPC, CCMAIL, NOTES, GRPWISE, GRPWISE5, or IMAP.

Whether to extract personal e-mail messages.

TRUE | FALSE Public Default: TRUE

Required when Mode is set to FILE, MSMAILPC or CCMAIL. TRUE | FALSE

Whether to extract shared folders, bulletin board, or forum information. Note When you import from a file, if you are not migrating public folders, you must set this attribute to FALSE or an error will result.

PAB

Optional

Default: TRUE

Ignored unless Mailbox is set to MSMAILPC or CCMAIL. TRUE | FALSE

Whether to extract personal address book (PAB) entries and PAB distribution lists.

Appendix D: Batch File and Command Line Migrations 331

Parameter

Use

Description

Schedule

Optional

Default: TRUE

Ignored unless Mode is set to MSMAILPC, NOTES, GRPWISE, or GRPWISE5.

Whether to extract schedule (calendar) information.

TRUE | FALSE EmailStart Default: Jan 01, 1601

EmailEnd No default

ExchStoreDN No default

Optional

The start date of the date range that specifies which messages Ignored unless Mode is set to should be included in the MSMAILPC, CCMAIL, NOTES, migration. Messages without dates ADSI, GRPWISE, or GRPWISE5. are always included. The Valid Setting: Exchange Migration Wizard cannot determine whether Must be in the following date and messages without dates are within time format: the specified date range, and YYYYMMDDHHMMSS. therefore assumes that they are within the specified date range. Optional

The end date of the date range that specifies which messages Ignored unless Mode is set to should be included in the MSMAILPC, CCMAIL, NOTES, migration. Messages without dates ADSI, GRPWISE, or GRPWISE5. are always included. The Valid Setting: Exchange Migration Wizard cannot determine whether or not Must be in the following date and messages without dates are within time format: the specified date range, and YYYYMMDDHHMMSS. therefore assumes that they are within the specified date range. Required when Function is not set The distinguished name of the to EXTRACT. Exchange mailbox store in which user mailbox stores are to be Valid setting is a distinguished created. name. Example: CN=New Mailbox Store,CN=My Storage Group,CN=InformationStore,CN= MYSERVER,CN=Servers,CN=Fir st Administrative Group,CN=Administrative Groups,CN=FirstAdminGroup,CN =Microsoft Exchange,CN=Services,CN=Confi guration,DC=MyDomain,DC=mic rosoft,DC=com

332 Exchange Server 2003 Interoperability and Migration Guide

Parameter

Use

Container

Required when Function is not set The distinguished name of the to EXTRACT. organizational unit (container) in which new Microsoft Windows® Valid Setting: accounts are to be created. You Must be formatted as follows: can get the full distinguished OU=New Users,DC=MyDomain, name from an LDAP viewer such DC=microsoft,DC=com New as Ldp.exe or Adsivw.exe. Users is a subcontainer of MyDomain.

No default

NTAccounts

Optional

Default: RANDOM

Ignored unless Mailbox is set to TRUE.

Description

Whether to create Windows user accounts for new users, and which value to use as the user account password.

Valid settings: RANDOM creates Windows accounts and generate random passwords. ALIAS creates Windows accounts and uses the Exchange e-mail alias as the initial password. Postoffice No default

Required if Mode is set to MSMAILPC, CCMAIL, GRPWISE, ADSI, or IMAP.

The full path to the post office.

Valid setting is a universal naming convention (UNC) path or a mapped drive location. However, if you are migrating Exchange mailboxes, the valid setting is the name of the Exchange server. GWDomain No default

Required if Mode is set to GRPWISE5.

The path to the GroupWise release 5.x domain.

Valid setting is either a UNC path or a mapped drive location. POName

Required if Mode is set to CCMAIL, NOTES, or GRPWISE5.

The full name of a cc:Mail, Lotus Notes, or a GroupWise release 5.x post office. The Lotus Notes post office should be in the form Notes Server/Domain. The GroupWise post office is in the domain stated in the GWDomain value.

DefFldPerms

Optional if Public is set to TRUE.

Default: NONE

Valid options are None, Author, and PubEditor.

Used to assign default access permissions to all users for migrated shared information.

No default

Ignored when Mode is set to NOTES, GRPWISE, GRPWISE5, IMAP, or LDAP.

Appendix D: Batch File and Command Line Migrations 333

Parameter

Use

FldOwner

Required if Public is set to TRUE. Distinguished name of the account that will own the public folder. You should use the Exchange 5.5 version distinguished name rather than the Microsoft Active Directory® directory service distinguished name.

No default

Description

Example: /o=Microsoft/ou=London/cn=Reci pients/cn=TheOwner ImportDestination

Optional

Default: SERVER

Ignored unless Mode is set to FILE, MSMAILPC, CCMAIL, NOTES, GRPWISE, GRPWISE5, or IMAP.

Specifies the destination store for migrated data. Note Public folder data does not migrate to .pst files.

Valid settings: SERVER migrates information to the Microsoft Exchange Information Store service. PST migrates information to personal folder (.pst) files and personal address book (.pab) files. PSTPath Note If you use the keyword ImportDestination, you can select the location where the .pst file will be placed. If you don't specify the location, the .pst file will be placed in the root directory of the drive where Exchange is installed.

GWUserGRPName

Required if ImportDestination is set to PST. Valid setting is path name.

The fully qualified path to the directory where personal folder (.pst) files are created.

Required if Mode is set to GRPWISE.

The name of the Novell GroupWise group whose members are to be migrated.

SchdStart

Optional

Default: Jan 01, 1601

Ignored unless Mode is set to NOTES, GRPWISE, or GRPWISE5.

The earliest (start) date for filtering which calendar data is moved. Information without dates is always migrated.

No default

Valid settings are in the following date and time format: YYYYMMDDHHMMSS.

334 Exchange Server 2003 Interoperability and Migration Guide

Parameter

Use

Description

SchdEnd

Optional

Default: Current date

Ignored unless Mode is set to NOTES, GRPWISE, or GRPWISE5.

The end date of the date range that specifies which messages should be included in the migration. Messages without dates are always included. The Exchange Migration Wizard cannot determine whether or not messages without dates are within the specified date range, and therefore assumes that they are within the specified date range.

Valid settings are in the following date and time format: YYYYMMDDHHMMSS.

Phone

Optional

Default: TRUE

Ignored unless Mode is set to GRPWISE or GRPWISE5.

Whether to migrate phone messages.

TRUE | FALSE Appointments

Optional

Default: TRUE

Ignored unless Mode is set to NOTES, GRPWISE, or GRPWISE5.

Whether to migrate appointments.

TRUE | FALSE Notes

Optional

Default: TRUE

Ignored unless Mode is set to GRPWISE or GRPWISE5.

Whether to migrate notes.

TRUE | FALSE Tasks

Optional

Default: TRUE

Ignored unless Mode is set to GRPWISE or GRPWISE5.

Whether to migrate tasks.

TRUE | FALSE GWRTF

Optional

Default: TRUE

Ignored unless Mode is set to GRPWISE. Valid settings: TRUE means messages are migrated in Rich Text Format (RTF). FALSE means messages are migrated in American National Standards Institute (ANSI) format.

Whether messages are migrated in RTF.

Appendix D: Batch File and Command Line Migrations 335

Parameter

Use

Description

IniFile

Optional

The path to the Notes.ini file.

Default: The default installation directory that the installed Lotus Notes client version suggests during setup.

Ignored unless Mode is set to NOTES.

DocLinkConversion

Optional

Default: RTF

Ignored unless Mode is set to NOTES.

How Lotus Notes document links are converted within the messages being migrated.

Valid settings: URL to convert document links to URL shortcuts within the message. OLE to convert document links to OLE attachments within the message. RTF to convert document links to RTF attachments within the message. Secure

Optional

Default: FALSE

Ignored unless Mode is set to ADSI.

Encryption

Optional

Default: FALSE

Ignored unless Mode is set to ADSI or IMAP.

Port

Optional

Default: 389 for Mode ADSI 143 for Mode IMAP

Ignored unless Mode is set to ADSI or IMAP or EXCHANGE.

!

Optional

A comment delimiter. Must be the first value in the line.

TargetDC

Optional

Common name (CN) or fully qualified domain name (FQDN) of the target domain controller acting as global catalog server to which the Exchange Migration Wizard should bind.

Ignored if mode is not Exchange

SourceDomain

Optional Ignored if Mode is EXCHANGE and Exch55 equal True and if Mode is not EXCHANGE.

Whether to use Secure authentication.

Whether messages are encrypted. If set to TRUE, Secure Sockets Layer (SSL) is used to migrate the contents of the mailboxes. In this case, ensure that you select the correct value for Port. The port number.

CN or FQDN of the source Active Directory domain to which the Exchange Migration Wizard should bind.

336 Exchange Server 2003 Interoperability and Migration Guide

Parameter

Use

Description

InetOrgPerson

Optional

Default: FALSE

If InetOrgPerson equals TRUE, Migration Wizard creates an Active Directory object with an object class that equals InetOrgPerson.

By default, object class is OrganizationalPerson.

ExchStore

Required if ExchStoreDN is not specified.

No default

The common name of the Exchange mailbox database that will contain the new migrated Valid setting is a mailbox database mailboxes. name.

Sample Control Files You can use the following sample control files with the /C switch of the migration command-line utility.

Microsoft Mail for PC Networks: importing data with a user list Note This is a sample control file for MS Mail migrations.

Mode,MSMAILPC Function,import File,\Server1\MSMail\CompanyPO.csv Public,False PostOffice,\Server1\MSMail\CompanyPO\MailData Container,OU=MailMig,DC=London,DC=Domain,DC=com ExchStoreDN,CN=MyPrivateInfoStore,CN=InformationStore,CN=Server1,CN=Servers,CN =First Administrative Group,CN=Administrative Groups,CN=MyVeryFirstOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=com NTAccounts,Alias Email,true

Appendix D: Batch File and Command Line Migrations 337

Schedule,true PAB,true

Exchange: using the command line to migrate from Exchange 5.5 Note This is a sample control file for Exchange 5.5 mailbox migrations.

Mode,exchange Accounts,c:\ntstemp\accounts.txt PostOffice,mig55 Exch55,True ExchStoreDN,CN=Mailbox Store (MIG-SOURCE-EN),CN=First Storage Group,CN=InformationStore,CN=MIG-SOURCE-EN,CN=Servers,CN=First Administrative Group, CN=Administrative Groups, CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=migsource,DC=extest,DC=contoso,DC=com Container,OU=Test,DC=mig-source,DC=extest,DC=contoso,DC=com TargetDC,migDC

Exchange: using the command line to migrate from Exchange 2000 or Exchange 2003 Note This is a sample control file for Exchange 2000 or Exchange 2003 mailbox migrations.

Mode,exchange Exch55,False SourceDomain,migSourceDomain PostOffice,mig2000 Accounts,c:\ntstemp\accounts.txt ExchStoreDN,CN=Mailbox Store (MIG-SOURCE-EN),CN=First Storage Group,CN=InformationStore,CN=MIG-SOURCE-EN,CN=Servers,CN=First Administrative Group, CN=Administrative Groups, CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=migsource,DC=extest,DC=contoso,DC=com Container,OU=Test,DC=mig-source,DC=extest,DC=contoso,DC=com TargetDC,migDC.mig-source.extest.contoso.com

Lotus:cc:Mail: importing migration files to .pst files Note This is a sample control file for cc:Mail migrations.

Mode,ccmail Function, FULL ImportDestination,Server

338 Exchange Server 2003 Interoperability and Migration Guide

ExchStoreDN,CN=Mailbox Store (AMA),CN=First Storage Group,CN=InformationStore,CN=AMA,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=AMA,DC=extest,DC=contoso,DC=com Container,OU=mig (AMA),DC=AMA,DC=extest,DC=contoso,DC=com File,d:\temp PostOffice,w:\ccmailpo POName,smtpPO Public,True FldOwner,/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=Administrator DefFldPerms,author

Novell GroupWise 4.x: extracting data to migration files Note This is a sample control file for GroupWise migrations.

Mode,grpwise Function,extract Postoffice,E:\large\mainpo File,E:\temp\ GWUsergrpname,testers Email,True Phone,True Appointments,True Notes,True Tasks,True SchdStart,19950101000000 SchdEnd,20000101000000 EmailStart,19950101000000 EmailEnd,20000101000000

Novell GroupWise 5.x: one-step migration to a server Note This is a sample control file for GroupWise migrations.

Mode,grpwise5 Function,Full Mailbox,True ImportDestination,Server File,e:\temp\ GWDomain,k:\SYS\GrpWise\NYCDomain POName,Manhattan ExchStoreDN,CN=Mailbox Store (FIRST),CN=First Storage Group,CN=InformationStore,CN=FIRST,CN=Servers,CN=First Administrative

Appendix D: Batch File and Command Line Migrations 339

Group,CN=Administrative Groups,CN=ThirtyTwoLettersThirtyTwoLetters,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=London,DC=extest,DC=contoso,DC=com Container,OU=Finance,DC=London,DC=contoso,DC=com NTAccounts,Alias ForcePwdChange,True Email,true Appointments,true Notes,false Tasks,true SchdStart,19950101000000 SchdEnd,20000101000000 EmailStart,19950101000000 EmailEnd,20000101000000

Novell GroupWise 5.x: one-step migration to .pst files Note This is a sample control file for GroupWise migrations.

Mode,GrpWise5 GWDomain,k:\SYS\GrpWise\NYCDomain POName,Manhattan ImportDestination,PST PSTPath,c:\psts File,c:\temp Schedule,False Notes,False Tasks,True

Lotus Notes: one-step migration to a server (all users in a post office) Note This is a sample control file for Lotus Notes migrations.

Mode,Notes File,c:\temp ExchStoreDN,CN=NotesUsers,CN=First Storage Group,CN=InformationStore,CN=Exchange6,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainXYZ,DC=CompanyXYZ,DC=com Container,OU=NotesFolks,DC=DomainXYZ,DC=CompanyXYZ,DC=com INIFile,C:\Lotus\Notes\notes.ini POName,LocalPostOffice/Topeka/US SchdStart,19980101000000 EmailStart,19980101000000 DocLinkConversion,OLE

340 Exchange Server 2003 Interoperability and Migration Guide

NTAccounts,Random

Internet directory (LDAP by means of Active Directory Service Interfaces [ADSI]): one-step migration to a server (all users in an ADSI container) Note This is a sample control file for LDAP migrations.

Mode,ADSI Function,Full File,e:\temp Accounts,e:\test\accounts.txt Mailbox,True ExchStoreDN,CN=Mail,CN=Mail Sack,CN=InformationStore,CN=Store,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=City01,DC=City02,DC=contoso,DC=com Container,ou=users2,dc=City01,dc=City02,dc=contoso,dc=com PostOffice,web3/o=contoso.com NTAccounts,Alias ForcePwdChange,False Secure,False Encryption,False Port,389

IMAP4: extract only (all users in the imapusr.csv file) Note This is a sample control file for IMAP4 migrations.

Mode,IMAP Function,Full File,e:\temp Accounts,e:\temp\ADSI.001\imapusr.csv Mailbox,True ImportDestination,Server Home-Server,Mig-Source-En2 ExchStore,Mailbox Store (Mig-Source-En2) Container,OU=new,OU=test,DC=mig-source,DC=extest,DC=contoso,DC=com NTAccounts,Alias ForcePwdChange,False Email,True

A P P E N D I X

E

Terminology

advanced queuing engine A core component of the SMTP transport subsystem in Microsoft® Exchange Server 2003. It passes the messages from message queue to message queue, invoking event sinks, such as categorizer and routing engine, as needed to transfer the messages to their destinations. body part Defines the content type of an X.400 message. A single message can include multiple body parts for the actual message and message attachments. Body parts are identified by an object identifier. bridgehead server A computer that connects servers using a connector so that information can be passed from one server to another. In Exchange 2003 and Exchange 2000 Server, a bridgehead server is a connection point from a routing group to another routing group, remote system, or other external system. categorizer An internal component of the SMTP transport subsystem in Exchange 2003 that processes all messages that pass through the server. The categorizer resolves sender and recipient information against Active Directory, expands distribution lists, checks restrictions, applies per-sender and per-recipient limits, and bifurcates messages if multiple copies must be created (for example, if recipients require different message formats). checksum A calculated value that is used to test data for the presence of errors that can occur when data is transmitted or when it is written to disk. The checksum is calculated for a given chunk of data by sequentially combining all of the bytes of data with a series of arithmetic or logical operations. After the data is transmitted or stored, a new checksum is calculated in the same way using the (possibly faulty) transmitted or stored data. If the two checksums do not match, an error has occurred, and the data should be transmitted or stored again. Checksums cannot detect all errors, and they cannot be used to correct erroneous data. connector A component that enables information to flow between two systems. For example, connectors support message transfer, directory synchronization, and calendar querying between Exchange and other messaging systems. When two systems are in place, the basic user experience is maintained on both messaging systems. The exchange of mail and other information between Exchange and other messaging systems is transparent to the user, even if the two systems function differently. Exchange store driver A component in Exchange 2003 that enables the SMTP service to communicate with the Microsoft Exchange Information Store service. foreign domain A directory object that defines a messaging environment that is external to the local messaging system and uses different message formats and communication protocols. Foreign domains are used for addressing and routing purposes. The external messaging system is usually connected to the local messaging system using a gateway connector.

342 Exchange Server 2003 Interoperability and Migration Guide

foreign messaging system A messaging system that uses different message formats and communication protocols than the local messaging system. For example, Novell GroupWise is a foreign messaging system for Exchange 2003. hub and spoke topology A topology in which a central node performs all routing for the other nodes in the environment. The central routing node is the hub, and the connections to all other nodes are the spokes. infrastructure A physical structure that builds the foundation of a network. For example, the physical structure of a computer network consists of cables, hubs, switches, routers, servers, and other resources that form the communication infrastructure of a company. Internet Security and Acceleration (ISA) Server A software application from Microsoft Corporation to increase the security and performance of Internet access for businesses. ISA Server provides an enterprise firewall and high-performance Web cache server to securely manage the flow of information from the Internet through the enterprise's internal network. local delivery queue A repository for messages that are awaiting local delivery to mailboxes in a mailbox store on the Exchange server through the Exchange store driver. mail exchanger (MX) record A database entry in a Domain Name System (DNS) zone that points to an SMTP host that is responsible for message transfer to an Internet domain. post-categorization queue A special message queue in the advanced queuing engine of the SMTP transport subsystem of Exchange 2003 for messages after they have been categorized. Messages in this queue might be delivered locally or passed to the routing engine to determine the next hop on the transfer path. pre-categorization queue A throttling queue in the advanced queuing engine for messages that are waiting for categorization by the categorizer. pre-submission queue A special message queue in the advanced queuing engine of the SMTP transport subsystem of Exchange 2003 that represents the entry point for all messages into the advanced queuing engine. Messages in this queue have not been processed yet. queue manager A component of the SMTP transport subsystem in Exchange 2003 that maintains the link queues in the transport subsystem. routing engine A component of the SMTP transport subsystem in Exchange 2003 that determines the next hop for messages on the transfer path to remote destinations. smart host An SMTP host that forwards e-mail messages on behalf of other SMTP hosts and Internet clients to the next hop on the way to their destinations. Internet service providers (ISPs) often provide their customers with a central smart host that handles message transfer across the Internet. If a smart host is designated, the Exchange server needs only to transmit messages to the smart host, and does not require a direct connection to the mail exchanger (MX) host of the destination domain. A smart host is also called a relay host, and a smart host that accepts messages from any source on the Internet and relays them to other destinations on the Internet is called an open relay. Open relays are often sources of unsolicited commercial e-mail (spam). SMTP protocol engine A component of the SMTP transport subsystem in Exchange 2003 that communicates through SMTP with remote hosts and Internet clients.

Appendix E: Terminology 343

topology The physical arrangement or layout of a network infrastructure. The topology of a network can consist of local area network (LAN) connections, metropolitan area network (MAN) connections, and wide area network (WAN) connections, and the devices that connect these networks. For additional definitions of Exchange 2003 terminology, see the Exchange Server 2003 Glossary (http://go.microsoft.com/fwlink/?LinkId=24625).

A P P E N D I X

F

Resources

Resources Cited in This Guide Exchange Server 2003 Technical Articles • Migration and Coexistence of Lotus Notes Applications Using Microsoft Application Services for Lotus Notes http://go.microsoft.com/fwlink/?LinkId=7467 •

Using the TreeView IE Web Control http://go.microsoft.com/fwlink/?LinkId=25929

Exchange Server 2003 Guides • Planning an Exchange Server 2003 Messaging System http://go.microsoft.com/fwlink/?LinkId=21766 •

Exchange Server 2003 Deployment Guide http://go.microsoft.com/fwlink/?LinkId=21768

•

Exchange Server 2003 Transport and Routing Guide http://go.microsoft.com/fwlink/?LinkId=26041

Microsoft Knowledge Base Articles The following Microsoft Knowledge Base articles are available on the Web at http://go.microsoft.com/fwlink/?linkid=14898 •

XADM: How to Customize the SMTP E-mail Address Generators Through Recipient Policies http://go.microsoft.com/fwlink/?linkid=3052&kbid=285136

•

Using LDIFDE to Import and Export Directory Objects to Active Directory http://go.microsoft.com/fwlink/?linkid=3052&kbid=237677

•

XFOR: Customizing Directory Synchronization Between Exchange and Notes http://go.microsoft.com/fwlink/?linkid=3052&kbid=180517

•

XFOR: Lotus Notes Client Versions That Are Tested with the Exchange Notes Connector http://go.microsoft.com/fwlink/?linkid=3052&kbid=316035

•

XFOR: SMTP Messages from Lotus Notes SMTPMTA to Exchange 2000 Append @NotesDomain to the Sender's Address http://go.microsoft.com/fwlink/?linkid=3052&kbid=255160

Appendix F: Resources 345

•

Directory Synchronization Between Notes and Exchange with SMTP Addresses http://go.microsoft.com/fwlink/?linkid=3052&kbid=303724

•

Frequently Asked Questions About Network Monitor http://go.microsoft.com/fwlink/?linkid=3052&kbid=294818

•

How to Capture Network Traffic with Network Monitor http://go.microsoft.com/fwlink/?linkid=3052&kbid=148942

•

How to Install ISO and TP4 Parser for Network Monitor http://go.microsoft.com/fwlink/?linkid=3052&kbid=168862

•

Delivery Status Notifications in Exchange 2000 Server http://go.microsoft.com/fwlink/?linkid=3052&kbid=284204

•

How to Troubleshoot Basic TCP/IP Problems http://go.microsoft.com/fwlink/?linkid=3052&kbid=169790

•

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

•

Telnet to Port 25 to Test SMTP Communication http://go.microsoft.com/fwlink/?linkid=3052&kbid=153119

•

XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts http://go.microsoft.com/fwlink/?linkid=3052&kbid=316047

Software Development Kit • Microsoft Exchange Server 2003 Software Development Kit (SDK) http://go.microsoft.com/fwlink/?LinkId=25925 •

Specific topics from the Exchange SDK: Checking Free/Busy Status http://go.microsoft.com/fwlink/?LinkId=25928

Web Sites • Exchange 2003 Technical Documentation Library http://go.microsoft.com/fwlink/?LinkId=21277 •

Microsoft Help and Support http://support.microsoft.com

•

Microsoft SharePoint Web site http://www.microsoft.com/sharepoint

•

Microsoft Metadirectory Services Web site http://go.microsoft.com/fwlink/?LinkId=25926

•

Microsoft Office Internet Free/Busy Service Web site http://go.microsoft.com/fwlink/?LinkId=25927

•

Exchange Management Pack Technical Reference http://go.microsoft.com/fwlink/?LinkId=23230

•

Novell Support Web site http://support.novell.com Note Third-party Web site information is provided to help you find the technical information you need. The URLs are subject to change without notice.

346 Exchange Server 2003 Interoperability and Migration Guide

Downloads • Importer for Lotus cc:Mail Archives http://go.microsoft.com/fwlink/?LinkId=25933 •

Address Rewrite (Exarcfg.exe) tool http://go.microsoft.com/fwlink/?LinkId=25932

•

WinRoute tool http://go.microsoft.com/fwlink/?LinkId=25049

•

MTA Check tool http://go.microsoft.com/fwlink/?LinkId=25924

•

Patch 2 for the GroupWise 4.1 API Gateway for NLM, available from Novell in the form of a self-extracting file called GW41API2.exe http://support.novell.com Note Third-party download information is provided to help you find the technical information you need. The URLs are subject to change without notice.

Additional Resources Besides the resources cited in this guide, you might find the following resources useful in your implementation of Microsoft® Exchange Server 2003.

Exchange Server 2003 Exchange Server 2003 Guide • Exchange Server 2003 Administration Guide http://go.microsoft.com/fwlink/?LinkId=21769 Exchange Server 2003 Glossary • Exchange Server 2003 Glossary http://go.microsoft.com/fwlink/?LinkId=24625 Software Development Kit • Microsoft Platform Software Development Kit for details about the development of custom workgroup and workflow solutions, if you are planning to port existing collaboration solutions to Exchange. http://go.microsoft.com/fwlink/?LinkId=28087 Web Sites • Exchange Server 2003 Tools and Updates http://www.microsoft.com/exchange/2003/updates •

Microsoft Developer Network (MSDN®) http://msdn.microsoft.com/

Appendix F: Resources 347

TechNet • Technical articles and other resources for Exchange published by Microsoft on the Internet (and also available on the TechNet CD) http://go.microsoft.com/fwlink/?LinkId=27733

Windows Server 2003 Web Sites • Microsoft Windows Server 2003 online documentation for detailed information about Windows 2003 Active Directory. http://www.microsoft.com/windowsserver2003 Resource Kit • Microsoft Windows 2003 Technical Reference for complete information about Windows 2003 components and networking technologies used in Exchange Server 2003. http://go.microsoft.com/fwlink/?LinkId=27734

Exchange 2000 Server Technical Papers • Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration http://go.microsoft.com/fwlink/?LinkId=25788 •

Microsoft Exchange 2000 and Lotus Domino Coexistence and Migration http://go.microsoft.com/fwlink/?LinkId=25822

•

Lotus cc:Mail and Exchange 2000 Server Coexistence and Migration http://go.microsoft.com/fwlink/?LinkId=25823

Resource Kit • Microsoft Exchange 2000 Server Resource Kit http://go.microsoft.com/fwlink/?LinkId=6543 Note You can order a copy of Microsoft Exchange 2000 Server Resource Kit from Microsoft Press® at http://go.microsoft.com/fwlink/?LinkId=6544.

A P P E N D I X

G

Accessibility for People with Disabilities

Microsoft is committed to making its products and services easy for everyone to use. This appendix provides information about features, products, and services that make the Microsoft Windows Server™ 2003 family, the Windows® 2000 Server family, Microsoft Exchange Server 2003, and Microsoft Office Outlook Web Access® 2003 more accessible for people with disabilities. The following topics are covered: •

Accessibility in Microsoft Windows

•

Adjusting Microsoft products for people with accessibility needs

•

Microsoft product documentation in alternative formats

•

Microsoft services for people who are deaf or hard-of-hearing

•

Specific information about Exchange 2003 and Outlook Web Access 2003

•

Other information resources for people with disabilities Note The information in this appendix applies only if you acquired Microsoft products in the United States. If you acquired Windows outside the United States, your package contains a subsidiary information card listing Microsoft support services telephone numbers and addresses. Contact your subsidiary to find out whether the type of products and services described in this appendix are available in your area. See the International Microsoft Accessibility Site (http://go.microsoft.com/fwlink/?LinkId=22008) for information available in the following languages: Chinese, English, French, Italian, Japanese, Portuguese, Spanish (Latin America), and Spanish (Spain).

Accessibility in Microsoft Windows Many accessibility features have been built into the Windows operating system, starting with the introduction of Windows 95. These features are useful for individuals who have difficulty typing or using a mouse, are blind or have low vision, or who are deaf or hard-of-hearing. The features can be installed during setup. For more information about the accessibility features of the various Windows operating systems, go to the Microsoft Products Accessibility Web site (http://go.microsoft.com/fwlink/?LinkId=22010).

Accessibility Files to Download If you have a modem or another type of network connection, you can download accessibility files from the following network services: •

The Microsoft Accessibility Web site at http://www.microsoft.com/enable/.

Appendix G: Accessibility for People with Disabilities 349

•

The Microsoft Help and Support Web site at http://go.microsoft.com/fwlink/?LinkId=14898. Select the Knowledge Base Article ID Number Search option, type 165486, and then click the arrow. The search displays the Knowledge Base article, "Customizing Windows for Individuals with Disabilities," which includes links to documents about customizing various versions of Microsoft Windows. For other accessibility articles, from the Microsoft Help and Support Web site, select the Search the Knowledge Base option, select All Microsoft Products, and in Search for, type kbenable, and then click Go.

•

Microsoft Internet server at ftp://ftp.microsoft.com/, in softlib/MSLFILES.

•

Microsoft Download Service (MSDL), which you can reach by dialing (425) 936-6735 in the United States or (905) 507-3022 in Canada. Direct modem access to MSDL is available 24 hours a day, 365 days a year. Outside the United States and Canada, contact your local Microsoft subsidiary for information. Note MSDL supports 1200, 2400, 9600, or 14,400 baud data transmission with no parity, 8 data bits, and 1 stop bit. MSDL does not support 28.8 Kbps, 56 K, or Integrated Digital Network (ISDN) connections.

Adjusting Microsoft Products for People with Accessibility Needs Accessibility options and features are built into many Microsoft products, including the Windows operating system. Accessibility options and features are useful for individuals who have difficulty typing or using a mouse, are blind or have low vision, or who are deaf or hard-of-hearing.

Free Step-by-Step Tutorials Microsoft offers a series of step-by-step tutorials to help you learn how to adjust the accessibility options and settings on your computer. The free tutorials provide detailed procedures on how to adjust options, features, and settings to meet your accessibility needs. Information related to the use of the mouse, the keyboard, or a combination of both is presented in a side-by-side format to help you learn. Visit the Microsoft Accessibility Step by Step Tutorials Overview Web site (http://go.microsoft.com/fwlink/?LinkId=14899) to find the latest step-by-step tutorials.

Assistive Technology Products for Windows A wide variety of assistive technology products are available to make computers easier to use for people with disabilities. Microsoft provides a searchable catalog of assistive technology products that run on the Windows operating systems at the Microsoft Overview of Assistive Technology page (http://go.microsoft.com/fwlink/?LinkId=14901). As an example, products available for the MS-DOS, Windows, and Windows NT operating systems are: •

Programs that describe information on the screen in Braille, or that provide synthesized speech for people who are blind or have difficulty reading.

•

Hardware and software tools that modify the behavior of the mouse and keyboard.

350 Exchange Server 2003 Interoperability and Migration Guide

•

Programs that enable people to type by using a mouse or their voice.

•

Word or phrase prediction software that people can use to type more quickly and with fewer keystrokes.

•

Alternative input devices, such as single switch or puff-and-sip devices, for people who cannot use a mouse or a keyboard.

Upgrading an Assistive Technology Product If you use an assistive technology product, be sure to contact your assistive technology vendor to check compatibility with products on your computer before upgrading. Your assistive technology vendor can also help you learn how to adjust your settings to optimize compatibility with your version of Windows or other Microsoft products.

Microsoft Documentation in Alternative Formats Documentation for many Microsoft products is available in several formats to make it more accessible. Exchange 2003 documents are available as Help on the CD included with the product and on the Exchange Web site at http://www.microsoft.com/exchange. If you have difficulty reading or handling printed documentation, you can obtain many Microsoft publications from Recording for the Blind & Dyslexic, Inc. (RFB&D). RFB&D distributes these documents to registered, eligible members of their distribution service in a variety of formats, including audiocassettes and CDs. The RFB&D collection contains more than 90,000 titles, including Microsoft product documentation and books from Microsoft Press®. You can download many of the Microsoft books from the Accessible Documentation for Microsoft Products Web site (http://go.microsoft.com/fwlink/?LinkId=22007). For more information, contact RFB&D at the following address or contact information: Recording for the Blind & Dyslexic 20 Roszel Road Princeton, NJ 08540 Phone from within the United States: (866) 732-3585 Phone from outside the United States and Canada: (609) 452-0606 Fax: (609) 987-8116 Web: http://www.rfbd.org/

Microsoft Services for People Who Are Deaf or Hard-of-Hearing If you are deaf or hard-of-hearing, complete access to Microsoft product and customer services is available through a teletype/telecommunication device for the deaf (TTY/TDD) service.

Appendix G: Accessibility for People with Disabilities 351

Customer Service Contact the Microsoft Sales Information Center on a TTY/TTD by dialing (800) 892-5234 between 06:30 and 17:30 Pacific Time [UTC-8, Coordinated Universal Time (Greenwich Mean Time)], Monday through Friday, excluding holidays.

Technical Assistance For technical assistance in the United States, contact Microsoft Product Support Services on a TTY/TDD at (800) 892-5234 between 06:00 and 18:00 Pacific Time (UTC-8), Monday through Friday, excluding holidays. In Canada, dial (905) 568-9641 between 8:00 and 20:00 Eastern Time (UTC-5), Monday through Friday, excluding holidays. Microsoft support services are subject to the prices, terms, and conditions in place at the time the service is used.

Exchange 2003 Section 508 of the Rehabilitation Act regulates how United States government agencies purchase electronic and information technology. It requires procurement officials to purchase only electronic and information technologies that are accessible to people with disabilities. Section 508 states that any "electronic and information technology" developed, procured, maintained, or used by federal agencies must be accessible to people with disabilities, including employees and members of the public, unless an undue burden would be imposed on the agency. To view the Exchange 2003 VPAT (Voluntary Product Accessibility Template), which describes the accessibility features that address the Section 508 standards, go to http://go.microsoft.com/fwlink/?LinkId=22011.

Outlook Web Access For customers who require assistive technology devices to interact with software applications, it is recommended that they use the Basic Outlook Web Access client. By default, the Basic client renders in all browsers except Microsoft Internet Explorer 5.01 to 6.x. However, an Exchange administrator can provide users of Internet Explorer 5.01 to 6.x with the option to choose the Basic client when logging on to Outlook Web Access. To do this, the administrator must use Exchange System Manager to enable forms-based authentication for Outlook Web Access. For details on enabling forms-based authentication, see the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?LinkId=21769). Administrators also have the option of setting the Basic client as the default client for all browsers. For more information about this approach, see the Microsoft Knowledge Base Article 296232, "XCCC: Empty Inbox When Using Internet Explorer 5 and Later to Gain Access to OWA" (http://go.microsoft.com/fwlink/?LinkId=14919).

352 Exchange Server 2003 Interoperability and Migration Guide

Getting More Accessibility Information The Microsoft Accessibility Web site (http://www.microsoft.com/enable/) provides information for people with disabilities, their friends and family members, people in outreach organizations, educators, and advocates. A free monthly electronic newsletter is available to help you keep up-to-date with accessibility topics about Microsoft products. To subscribe, visit the Accessibility Update subscription page (http://go.microsoft.com/fwlink/?LinkId=14920).

Appendix G: Accessibility for People with Disabilities 353

Does this guide help you? Give us your feedback. On a scale of 1 (poor) to 5 (excellent), how do you rate this guide? Mail feedback to [email protected]. For the latest information about Exchange, see the following Web pages: •

Exchange Product Team technical articles and guides http://www.microsoft.com/exchange/library

•

Exchange Tools and Updates http://www.microsoft.com/exchange/updates

•

Self-extracting executable containing all Exchange Product Team technical articles and guides http://go.microsoft.com/fwlink/?LinkId=10687