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?

  • 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 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.

Figure 1   Sample messaging infrastructure

Figure 2 shows a sample directory synchronization topology that corresponds to the messaging infrastructure illustrated in Figure 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 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 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, 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 retire the legacy messaging infrastructure. There is more information about migration strategies and procedures later in this topic.

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?   The Connector for Novell GroupWise is 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 lists the most common messaging systems and corresponding possible connector choices.

  Table 1   Messaging systems and preferred gateway connectors

  Messaging system	Preferred gateway connector
  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 the Connector for Novell GroupWise requires third-party components, as listed in Table 2. Alternatively, if you plan to use 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 2   Additional components required for Exchange messaging connectors

    Messaging connector	Additional components and versions
    Connector for Novell GroupWise	A Novell GroupWise API Gateway version 4.1 with Novell GroupWise Patch 2 for API
    Calendar Connector	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. 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 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 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 3   Non-Exchange messaging systems supported through MAPI transport drivers

    Messaging connector	Additional components and versions
    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 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.