Lesson 1: Assessing the Current Messaging Infrastructure

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.

After this lesson, you will be able to

  • Identify essential components in your messaging environment that influence the options for an implementation of Exchange 2000 Server
  • Document specific and detailed information about all messaging systems that are currently part of your messaging infrastructure
  • Determine whether an environment is ready for coexistence with Exchange 2000 Server

Estimated time to complete this lesson: 60 minutes

Typical Characteristics of Messaging Infrastructures

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:

  • User agent (UA) A component providing the end user with access to the messaging system—in other words, these are the messaging clients.
  • Message transfer agent (MTA) A component that provides the routing and relaying of e-mail messages.
  • Access unit (AU) A component that connects the message transfer system to foreign messaging systems that do not comply with the X.400 standard. A better term for the AU is the gateway or messaging connector.
  • Message store (MS) A component that stores the e-mail messages for the UAs. The MS corresponds to a post office or repository server, which is supposed to be permanently available for the MTAs so that they can deliver incoming messages to the users even if their UAs are currently not active.
  • Message transfer system (MTS) The collection of MTAs and MSs in a messaging infrastructure.
  • Message handling system (MHS) The collection of MTSs, AUs, and UAs that provide message and document handling.

    Figure 4.1 - The components of a messaging system according to the X.400 standard

Private vs. Public Servers

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.

Bridgehead 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

Messaging Backbone and Message Switches

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:

  • To concentrate message traffic between distinct locations to gain more control over the utilization of expensive network resources (such as wide area network [WAN] links).
  • To implement a uniform messaging standard in the corporate network to provide connectivity between heterogeneous messaging systems. The classic standard for messaging backbones is X.400; modern environments rely on Simple Mail Transfer Protocol (SMTP) instead.

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.

Routing Groups

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.

Gateways and Connectors

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.

Documenting Messaging Infrastructures

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:

  • Information about mailbox servers, including their names and location, the installed messaging system, number of mailboxes, the names of administrators, and so forth
  • Information about public servers, including their names, location, and purpose, and the number of users that access the public forums and workgroup applications
  • The structure of the messaging backbone, including central messaging links and their transfer protocols, the names and locations of bridgeheads, connections to foreign messaging systems and the Internet, and so on

Tip


You can find a Microsoft Excel workspace with several worksheets to document messaging infrastructures in the \Chapter04\Worksheets directory on the Supplemental Course Materials CD. The filename is MESSAGING_ENVIRONMENT.XLS.

Documenting Mailbox and Public Servers

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:

  • Where in the corporate network are the servers located and who is their administrator?
  • How many users does each system support?
  • Which messaging system is installed on the mailbox and public servers?
  • Are there any special configuration settings (such as post office passwords, database versions, and so on) or workgroup applications installed on the servers?
  • Which administrative utilities are used to manage the systems, and what is their version?
  • Which backup and restore procedures are used to secure the messaging resources?

Tip


You can use the Mailbox and Public Servers worksheet in the MESSAGING_ENVIRONMENT.XLS workspace as a guide to gather information about your mailbox and public servers.

Documenting the Messaging Backbone

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:

  • Which mailbox and public servers transfer messages to each other directly and where are these routing groups located?
  • Which systems perform the message transfer between routing groups and assume the responsibility of bridgehead servers?
  • Does the backbone rely on dedicated bridgeheads or do these systems provide other services to the messaging environment? Which services?
  • Who is in charge of the messaging backbone and the bridgehead servers?
  • Which bridgehead servers handle the message transfer to and from external environments?
  • Which message transfer protocols are used in the messaging backbone?
  • What address information is used to route messages between the locations (such as domain names) and what are individual direct and indirect paths a message can take through the corporate messaging backbone (that is, what does the message routing table look like)?

Tip


You can use the Messaging Backbone worksheet in the MESSAGING_ENVIRONMENT.XLS workspace as a guide to gather the required information about your bridgehead servers and messaging backbone. If possible, include a graphical representation of the topology.

Assessing Messaging Infrastructures

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:

  • Are there any known problems in the current infrastructure that may adversely affect the migration project?
  • Are you planning to consolidate messaging resources with the deployment of Exchange 2000 Server?
  • Which gateways or messaging connectors do you intend to use to connect Exchange 2000 Server to the existing messaging system?
  • Do you need to install additional components in the production environment to support the connectivity components?

Determining Connectivity Options

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.

Identifying Connectivity Risks

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

Analyzing the Messaging Environment of Adventure Works for an Integration of Exchange 2000 Server

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:

  • Are there any known problems in the current infrastructure?

    No, the current environment operates reliably with fast response times.

  • Is Adventure Works planning to consolidate messaging resources?

    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.

  • Which messaging connectors should Adventure Works use to connect Exchange 2000 Server to Exchange Server 5.5?

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

  • Do you need to install additional components in the production environment to support the connectivity components?

    No, all components come with Exchange 2000 Server.

    Figure 4.4 - The Exchange Server 5.5 organization of Adventure Works

Tip


You can find the complete worksheet, describing the current messaging environment of Adventure Works, in the \Chapter04\Examples directory on the Supplemental Course Materials CD. The filename is ADVENTURE_WORKS.XLS.

Activity: Evaluating Messaging Environments

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


You can use Figure B.10 in Appendix B as a guide to accomplish this activity.

Scenario: Coho Vineyard & Winery

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.

  1. Are there any known problems in the current infrastructure?
  2. Would you recommend a consolidation of messaging resources?
  3. Which connector could Coho Vineyard & Winery use to connect Exchange 2000 Server to Mdaemon PRO?
  4. Do you need to install additional components in the production environment to support the connectivity components?

Scenario: Woodgrove Bank

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.

  1. Are there any known problems in the current infrastructure?
  2. Would you recommend consolidation of messaging resources in their Swiss locations?
  3. Which connector should Woodgrove Bank use to connect Exchange 2000 Server to the messaging backbone and to the MS Mail postoffices?
  4. Do you need to install additional components in the production environment to support the connectivity components?

Lesson Summary

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



MCSE Microsoft Exchange 2000 Server Design and Deployment Training Kit(c) Exam 70-225
MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)
ISBN: 0735612579
EAN: 2147483647
Year: 2001
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net