Rarely will you be able to replace an existing messaging system with Exchange 2000 Server in one step. Such strategy is acceptable only in small companies, and even there you should consider a multistage migration to minimize the risk of interfering with daily business operations. It’s better to migrate in several stages to control the pace of change and mitigate risk. Multistage migrations, however, pass through a phase of coexistence, which requires you to connect Exchange 2000 Server to the legacy system. To find the best connectivity options, you need to gain detailed insight into the existing environment.
This lesson revolves around the topic of assessing an existing corporate network in regard to e-mail connectivity and system coexistence. You can read about important infrastructure elements, such as mailbox and bridgehead servers, as well as backbones and message switches, and find guidelines for documenting these components, identifying bottlenecks, and determining requirements for improvements to prepare the infrastructure for Exchange 2000 Server.
Regardless of their varying complexity, all messaging environments have several typical components in common. In fact, the most comprehensive messaging standard—the X.400 standard—once defined these components and assigned them specific tasks. Some terms may be outdated, but the concepts are still relevant.
Important messaging components according to the X.400 standard (Figure 4.1) include the following:
Figure 4.1 - The components of a messaging system according to the X.400 standard
The official messaging standards do not define the terms private and public server. However, these names are helpful to clarify the specific roles of each messaging system. Private servers hold mailboxes and are therefore also called mailbox servers. Public servers, on the other hand, hold discussion forums and workgroup applications that are shared between groups of users. In the Exchange 2000 Server product documentation, public servers are often referred to as public folder servers. In other systems they may be called bulletin board systems, newsgroup hosts, Notes application servers, and so forth. It is important to realize that a particular messaging server can be both a private and a public server.
It is not unusual to separate mailboxes from public servers to gain the ability to design the hardware according to the specific requirements of each server role. For instance, you may distribute a large community of users across a number of mailbox servers with a moderate hardware configuration, while implementing only a few public servers for all of the public forums and workgroup applications. Multiple private servers allow you to distribute mailboxes easily, whereas public folders are usually not replicated to every system in the environment to keep the replication traffic under control. This implies that a public server may be exposed to a heavy load due to concurrent user access from multiple mailbox servers.
Mailbox and public servers are for the user community, but a third type, the bridgehead server, is for administrators only. In some cases, these are called mail routing hubs, or smart hosts. Smart hosts, connecting a messaging environment to the Internet, are a good example of bridgehead servers. Bridgeheads do not provide access to any mailboxes or discussion forums. Instead, they are dedicated to the tasks of concentrating and routing message traffic through the corporate network (Figure 4.2). Bridgeheads may have to transfer large amounts of messages and are usually optimized for network communication instead of data storage.
Figure 4.2 - Dedicated bridgehead servers in a corporate network
The thick lines between the locations in Figure 4.2 form a messaging backbone, which represents the main connections in the corporate network. Usually, but not necessarily, the network connections in the backbone have a high bandwidth to handle data transfer from all locations.
Messaging backbones have two main purposes:
Messaging backbones rely heavily on the concept of bridgehead servers. In complex environments with many systems using different transfer protocols, central bridgeheads that support all of these protocols are necessary. This central arrangement of bridgeheads is known as a message switch. Lotus Messaging Switch is a good example of a powerful switching system for connecting SMTP, X.400, and other PC-based or mainframe mail systems together.
Microsoft uses the term routing groups to describe separate geographic locations, which is appropriate because each location in the backbone is a distinct node to which messages are routed. For example, in Figure 4.2, a server in Australia would route its messages to other locations indirectly via its local bridgehead, which in turn forwards the messages to an appropriate bridgehead in the remote locations, which then delivers the messages directly to the appropriate mailbox servers. Neither the Australian mailbox servers nor the Australian bridgehead needs to contact the individual servers in each routing group. For the purposes of message routing, all servers in a routing group can be considered a single unit.
Open Systems Interconnection (OSI) standards define the term gateway as a device that forwards packets unconverted between networks. Nowadays, the term router is more commonly used to describe this device, and the term gateway describes a device that converts and transfers messages between systems using different protocols. Gateways may or may not make routing decisions. In fact, gateways in Exchange 2000 Server do not perform any routing at all. This is the task of the transport engine. The gateway simply receives a message from one side, converts it, and delivers it to the other side—making it merely a component that connects the two systems. It is actually more a connector than a router, and that’s the official term in Exchange 2000 Server: messaging connector.
It is commonplace to outsource complex information technology (IT) projects to external consultants with sufficient knowledge and practical experiences. These external consultants, as well as internal specialists, who are unfamiliar with the current infrastructure, need detailed information about your messaging systems to understand how the infrastructure is put together. Nontechnical management personnel may also be interested in reading the infrastructure documentation.
Among other things, your documentation must provide answers to two key questions: Which systems do you want to replace with Exchange 2000 Server? Which other messaging systems requiring long-term coexistence are in your environment? Answers to the first question will help the project team develop appropriate migration strategies based on available migration tools. Precise information about the messaging topology, on the other hand, is essential for seamless system integration and the configuration of message routing. The integration of Exchange 2000 Server into your environment must not lead to interrupted message paths.
When documenting a messaging infrastructure, include the following information:
Tip
Mailbox and public servers are fundamental resources in any messaging environment and must be documented in detail to provide the project team with all required information to develop reliable migration strategies. The good news is that a great deal of the work has already been done—if you have documented the network and server configurations according to the guidelines from Chapter 3, "Assessing the Current Network Environment."
Migration strategies can differ depending on configuration, purpose, and other parameters of the messaging system, such as the number of users on the server. Check available documentation and interview the mailbox and system administrators to ensure that no features, functions, or services are overlooked. It is also a good idea to rate each system’s role with respect to daily business operations, just to forewarn the project team about crucial systems that require special care, such as the mailbox server of upper management.
Your documentation must provide answers to the following questions:
Tip
A core issue in any multiphase migration revolves around how to integrate Exchange 2000 Server into the existing messaging environment. Is it possible to connect to the production system using direct messaging connections, or is it necessary to build an indirect message path across a global message backbone? A clear understanding of the bridgeheads and backbone infrastructure is vital for determining the message routing configuration. You may even need to restructure the backbone to provide the required access points for Exchange 2000 Server.
Your documentation should provide answers to the following questions:
Tip
You should keep your assessment focused on the project objectives defined in the vision and scope document, discussed in Chapter 2, "Preparing for a Microsoft Exchange 2000 Server Deployment Project." For instance, if it is your intention to consolidate server resources to lower the total cost of maintaining your IT infrastructure, identify those systems in your project documentation to deal with them as single entities. Among other things, this helps you determine the overall number of Exchange 2000 servers to install.
An important objective of the assessment is to find appropriate connectivity components to connect Exchange 2000 Server to the existing messaging system. To support the desired messaging connectors, you may need to install additional components in the production environment before rolling out Exchange 2000 Server (see Figure B.10 in Appendix B).
When assessing messaging infrastructures for their readiness for Exchange 2000 Server, the following key questions should be asked:
First, the good news. It’s easy to integrate Exchange 2000 Server into an existing infrastructure. Exchange 2000 is bilingual and speaks X.400 and SMTP fluently. This platform can also communicate with Microsoft Mail, Lotus cc:Mail, Lotus Notes, and Novell GroupWise, and with the help of a translator (Exchange Server 5.5), it can also exchange information with Professional Office System (PROFS)-based and System Network Architecture Distribution Services (SNADS)-based messaging systems (Table 4.1). If your messaging system is not on this list, Exchange 2000 does not provide a direct connector. In this situation, check with your vendor to determine whether an appropriate third-party gateway is available. Most vendors have, at a minimum, SMTP gateways available for their messaging products. If such a direct gateway to Exchange 2000 Server does not exist, you need to make way for one of the well-established messaging standards (SMTP or X.400) to build the e-mail bridge. Indirect connectivity via the SMTP or X.400 messaging backbone is always an option for systems integration.
Table 4.1 Messaging Systems and Preferred Messaging Connectors
Messaging System | Preferred Messaging Connector |
---|---|
Microsoft Mail for PC Networks | MS Mail Connector |
Lotus cc:Mail | Connector to Lotus cc:Mail |
Lotus Domino/Notes | Connector to Lotus Notes |
Novell GroupWise | Connector to Novell GroupWise |
PROFS and SNADS | Via connectors in Exchange Server 5.5 |
Others | Check with vendor for available third-party gateways or implement an X.400 or SMTP gateway to use the X.400 Connector or SMTP Connector in Exchange 2000. |
Recall that within each routing group, the message transfer should be direct (Figure 4.3). Hence, if you deal with Microsoft Mail, Lotus cc:Mail, Lotus Notes, or Novell GroupWise, use the corresponding messaging connector available in the Exchange 2000 Server product package, instead of X.400 or SMTP. For PROFS and SNADS, consider primarily a connector running under Exchange Server 5.5. This may result in a slightly awkward routing architecture, but these connectors support the automatic synchronization of address information, which you may otherwise have to perform manually. You can read more about the purpose and advantages of directory synchronization in Lesson 2.
It takes two to communicate. Therefore, you need to check the existing infrastructure for shortcomings that may negatively affect the transfer of messages between the systems. Do not hesitate to address critical issues in your risk management plan. It is much harder to correct the infrastructure after deployment of Exchange 2000 Server has begun and users are migrated. Any communication problems discovered at later deployment stages might severely impair business processes and users’ perceptions of the Exchange 2000 organization.
When integrating Exchange 2000 Server into an existing messaging infrastructure, you have to deal with three major risks: overtaxed network connections, inefficient or incorrect message routing, and transmission problems due to questionable software components. To address the first, review the documentation of the existing environment for potential bottlenecks. You can find a discussion about network topology and performance issues in Chapter 3, "Assessing the Current Network Environment."
Figure 4.3 - Direct vs. indirect connectivity
Nondelivery reports (NDRs) or messages that got stuck in a message queue somewhere on a bridgehead are indicators of incorrect message routing. The most common reasons for NDRs are missing address space information and Domain Name System (DNS) configuration problems. Message loops, on the other hand, are created if messages are routed multiple times through the same bridgehead. Fortunately, Exchange 2000 Server adds trace information to all transferred messages to detect message loops and cancel the message delivery with an NDR. However, if multiple messaging systems are included in the message path, the trace information may be lost during message conversion between the systems, in which case it would be possible for messages to loop permanently. Review your existing messaging topology carefully to ensure that the implementation of Exchange 2000 Server does not lead to message loops. You can read more about the routing of messages to foreign systems in Chapter 7, "Designing a Migration Plan to Microsoft Exchange 2000 Server."
Messages may get stuck in message queues if the target system is unavailable or if the messaging connector is malfunctioning. It doesn’t always have to be a serious problem: The target system may be unavailable temporarily due to maintenance. However, if messages queue up for a significant time, check that the name resolution works and that other computers are able to connect to the target host. If the target system is available, the gateway or connector may be the problem, often due to incorrect connector components. Many connectors, such as the Connector to Lotus cc:Mail, Connector to Lotus Notes, and the Connector to Novell GroupWise, require system components not included in Exchange 2000 Server (Table 4.2). If incorrect component versions are used, delivery problems can occur. Check the product documentation for each connector’s requirements and make sure that the correct versions are available and installed on your systems before implementing Exchange 2000 Server. Do not forget to test the performance and reliability of your messaging connectors in a test lab and during the pilot rollout.
Table 4.2 Additional Components Required for Exchange 2000 Messaging Connectors
Messaging Connector | Additional Components and Versions |
---|---|
MS Mail Connector | No additional components required |
Connector to Lotus cc:Mail | A Lotus cc:Mail release 8 post office with database version 8 (DB8), and the Lotus cc:Mail IMPORT.EXE and EXPORT.EXE utilities version 8.3 or higher |
Connector to Lotus Notes | A Lotus Notes release 3 or 4 server or a server running Lotus Domino release 4.5, 4.6, or 5, and a Lotus Notes client release 4 or 5 |
Connector to Novell | A Novell GroupWise API Gateway version 4.1 with GroupWise Novell GroupWise Patch 2 for API |
Adventure Works, a company introduced in Chapter 3, "Assessing the Current Network Environment," with headquarters in Canada and subsidiaries in the United States, South Africa, and Australia, has globally deployed Exchange Server 5.5. According to John Y. Chen, Senior IT Administrator at Adventure Works, the current environment operates reliably with fast response times. Chen said, "We did not decide to move to Exchange 2000 Server because of problems with the current environment. Adventure Works simply wants to implement Exchange 2000 Server for its technological advantages, such as the Web Storage System, Instant Messaging, and the new workflow engine." The current Exchange Server 5.5 organization of Adventure Works is shown in Figure 4.4.
Chen has assessed his existing environment as follows:
No, the current environment operates reliably with fast response times.
No, Adventure Works is planning to keep the current structure of sites, servers, and Internet access points in place, although there are options to consolidate the resources in North America.
In South Africa and Australia, we will upgrade the servers directly. These servers will use routing group connectors to communicate with North America. Within North America, the order of server upgrades has not been decided yet, but Exchange Server 5.5 and Exchange 2000 Server can communicate directly with each other without the need for explicit messaging connectors. We are going to install an SMTP connector on VAC-02-EX after its upgrade to connect this machine to DMZ-01-SMTP in the demilitarized zone (DMZ).
No, all components come with Exchange 2000 Server.
Figure 4.4 - The Exchange Server 5.5 organization of Adventure Works
Tip
In this activity, you need to assess messaging environments for an integration of Exchange 2000 Server at two fictitious companies, Coho Vineyard & Winery and Woodgrove Bank, both introduced in Chapter 3. It is your task to determine possible messaging connectors and required changes in the current environment to optimally support the integration.
Tip
The current messaging environment of Coho Vineyard & Winery is displayed in Figure 4.5. Currently, the company uses Alt-N Technologies MDaemon PRO for Windows as its enterprise messaging system, which is a Microsoft Windows-based system that provides Internet mail services with a similar administrative feel to UNIX-based messaging systems. MDaemon supports SMTP, Post Office Protocol 3 (POP3), and Internet Message Access Protocol 4 (IMAP4). Paul West, Information Technology Administrator at Coho Vineyard & Winery, says, "MDaemon PRO is a great platform for all those who want to use a UNIX-like messaging system in a Windows-based environment. Our UNIX-like environment works great, but it’s not the right choice for us any longer. Simple messaging services do not give us the means to integrate network and messaging administration, automate our business processes, or implement sophisticated workgroup or workflow solutions, just to name a few examples. For this reason, we have implemented Windows 2000 and Active Directory, and we are now ready to migrate to Exchange 2000 Server. We are not sure whether we should move over to Exchange in one single step or perform multiple small steps. I tend to prefer the latter option, though."
Figure 4.5 - The current messaging environment of Coho Vineyard & Winery
It is your task to review Coho Vineyard & Winery’s messaging environment for an integration of Exchange 2000 Server.
Woodgrove Bank maintains a highly diversified infrastructure with numerous messaging systems (Figure 4.6). "As a modern bank," says Luis Bonifaz, Chief Information Officer, "we wanted to give all of our locations the option to choose their own messaging system. A global X.400/SMTP backbone based on a central message switch running on an IBM S/390 mainframe interconnects all of our locations. Our environment is stable, but we intend to eliminate our X.400-based backbone and the costly mainframe system. We will continue to support X.400 as long as required, but we are encouraging our locations to change to SMTP. Recently, all of our IT departments voted for a homogenization of the entire messaging environment. This was an unusual decision for Woodgrove Bank. I assume that high maintenance costs and limited options for streamlining business processes promoted this consensus. At Woodgrove Bank, we believe that Exchange 2000 Server is the right tool to decrease maintenance costs and increase business opportunities. Thus, we have deployed Windows 2000 Server and the Active Directory service in all of our locations. Now it’s time to migrate. In a first stage, we intend to implement Exchange 2000 Server only in our Swiss locations. International branches will follow later."
It is your task to review Woodgrove Bank’s messaging environment for an integration of Exchange 2000 Server in their Swiss locations.
All messaging environments have several typical components in common. There are systems that store mailboxes, provide access to public forums, or transfer messages across a messaging backbone. These systems are called mailbox, public, and bridgehead servers, respectively. It is not unusual to separate these roles and assign them to dedicated servers individually to optimally design system resources for the specific requirements.
You need to document your organization’s messaging infrastructure to provide your project team with detailed information about the existing mailbox, public, and bridgehead servers. The team must understand how the current infrastructure is put together to make the right design and migration decisions. Among other things, your documentation must provide answers to questions including where in the existing environment you want to install Exchange 2000 Server and which connector components to use for messaging connectivity.
As some connectors have specific requirements, it may be necessary to install additional components in the production environment before rolling out Exchange 2000 Server. It is also a good idea to fix any existing problems that may adversely affect the deployment project. For these reasons, you need to assess your current environment for its Exchange 2000 readiness.
Figure 4.6 - The current messaging environment of Woodgrove Bank