Isode X.400 Deployment Guide

This document is designed to help end users and system integrators plan how to deploy X.400 systems. It covers deployments ranging from single servers to complex distributed deployments, and applications including Military, Aviation, EDI, and MIXER. This document does not describe a deployment in detail, it is designed more as a check list of things that need to be done, and pointers to appropriate resources.

The overall approach Isode recommends is:

Initial practical familiarization with with Isode products.
Study and Preparation
Further familiarization
Deployment Planning
Deployment

This document covers these tasks in the above order.

X.400 Evaluation: A practical start

A good practical way to start is an evaluation of the Isode X.400 products. This will enable you to operate all of the necessary Isode server products, and to use and experiment with the associated management tools. This should only take a few hours, and we recommend doing it early.

Study and Preparation

In order to deploy an X.400 system, some knowledge of X.400 is necessary. For someone familiar with general messaging, the most important additional piece of knowledge for X.400 that is necessary is to understand how its hierarchical attribute based addressing works, including the concept of Management Domains. Chapter 1 of the Isode M-Switch Administration Guide provides appropriate information.

You need to become familiar with M-Switch. We recommend to print and study a copy of the M-Switch Administration Guide. You should also read Getting Started with M-Vault which gives sufficient information to set up a basic directory server. If the deployment will need a complex directory infrastructure (e.g., multiple replicated directory servers) or complex use of the directory (e.g., sophisticated use of access control) then you should also study the M-Vault Administration Guide.

Moving beyond X.400 Quick Install

X.400 Quick install is a "scripted install" that automatically sets up a configuration that incorporates all of the main X.400 products. While this is a good way to start, it is not the right basis to continue learning about the Isode systems (although this may seem tempting). At this stage, it is important to learn how to configure a system using Isode's standard management tools.

For most configurations, the best approach is to use Isode's management tools and wizards to configure a complete system. These tools provide significant functionality and flexibility, and time should be allowed for learning how to use these (either self training or an Isode course).

A recommended exercise is to use the tools to create configuration that is similar to the one created by the X.400 Quick Install script. Someone who is familiar with the tools can do this in five to ten minutes. A description, which outlines the steps and wizards needed is here. This exercise will help gain familiarity with the Isode configuration system, and build knowledge for setting up more complex configurations.

Scripted Installs

Scripted installs can be useful for some deployments, particularly where a large number of very similar systems are installed. It is reasonably straightforward to develop scripts to set up complete systems. Isode's scripts are written in Tcl, and most of Isode management APIs have
published Tcl interfaces.

X.400Quick is a Tcl script, which is included as a part of the Isode product. This is a Tcl/Tk GUI front end onto another Tcl script called Createmhs, which does the real work. Createmhs has a number of parameters, which make it suitable for setting up a simple system. For more complex systems, Createmhs is quite straightforward to modify.

The way that the core of CreateMHS works is to load an LDIF configuration into the directory. Key elements of the LDIF are changed to parameters that are set by the script. If you need to have a rather different configuration, a new configuration can be created using the GUI tools, and then an LDIF version of this configuration can be used as part of a modified Createmhs script.

Things you need to understand

In order to build an operational configuration, there are number of things that you will need to understand. This section lists the most important ones, and explains in which situations these will be needed.

Isode recommends directory based configuration, and this page only considers directory based configuration. A directory based configuration needs to have the directory installed first. If configuration is using a single directory server, typically as part of a single machine configuration, then very little knowledge of the directory is needed, as install is straightforward and configuration is very simple. Getting Started with M-Vault covers all that is needed. More information may be needed in the following situations:

If you need to operate multiple directory servers, in order to replicate information or to distribute information amongst multiple servers, you will need to understand the basics of configuring the administration of a directory server and dealing with replication agreements. This is covered in Chapters 2, 3 and 4 of the M-Vault Administration Guide.
If you plan to operate multiple messaging servers, or wish to use the directory for applications other than simply configuring the Isode servers, it is important to understand about the directory information tree (DIT) in order to understand how the configuration will be laid out over the DIT. Chapter 1 of the M-Vault Administration Guide provides a suitable tutorial.
If you plan to use access control, so that different administrators have different rights to control parts of the configuration, you need to understand directory access control. This is covered in Section 6.4 of the M-Vault Administrator's Guide.

It is important to have familiarity with the core messaging administrative tools. These are:

EMMA (Enterprise Messaging Management and Administration). EMMA is the core tool for configuring an X.400 deployment, and detailed knowledge will be needed. Chapter 2 of the Manual (Isode M-Switch Administration Guide) gives a good introduction.
MConsole is the primary tool for monitoring and controlling an operational configuration. It will be important for testing systems.
Log Viewer. It will be important to understand the viewing and monitoring capabilities of the log view, and to use this in conjunction with log level setting in EMMA.

It is also important to understand broadly the overall architecture of the Isode system, and in particular the multi-process architecture of M-Switch. This is covered in Chapter 1 of the Manual. Understanding the process architecture will help in diagnosis of failures, and in verifying that the correct set of processes are running. M-Switch has a channel architecture for dealing with different protocol and management functions. It is useful to understand this architecture, and what all of the various M-Switch channels do, so that a correct set of channels can be selected.

Most of the concepts exposed in EMMA are quite natural in terms of an X.400 system design (Message Transfer Agents; Message Stores; Users). A key concept in the Isode design is that of a Message Routing Tree, which provides a powerful and flexible mechanism to configure message routing. The Message Routing Tree is fundamental to the core routing and configuration of an Isode X.400 system, and it is important to understand how this works. Practical examples of using routing trees are given in Chapter 3 of the manual. The overall design of routing trees is set out in RFC 1801, "X.400-MHS use of the X.500 Directory to support X.400-MHS Routing". This specification explains how routing trees work, and how multiple routing trees can be used to achieve complex routing configurations and the flexibility and benefits of using routing trees. It also shows how each managed recipient will have multiple entries:

An entry in one or more routing trees, to control routing of the message.
An entry associated with the local store, which controls delivery and UA binding.
Optionally a "white pages" entry, containing phone numbers and other external information.

When building a system which contains only Isode components, EMMA cleanly manages the interconnection. Often, there is a need to interconnect external components, and in particular X.400 Clients (P3 or P7) and remote X.400 MTAs. In these situations, a number of parameters must be matched externally, and so this functionality must be understood.

If MIXER is used for mapping between X.400 and Internet Mail, the configuration and mapping options described in Chapter 5 of the Manual should be read.

Planning a Deployment

In order to plan a deployment, it will be necessary to have familiarity with the Isode products as described above and with the requirements of the deployment. This section notes key planning steps.

Work out the number of Messaging Servers needed, and connectivity between servers, users and external MTAs and Gateways. This will depend on a number of factors:

Location of users. It will often be desirable to position Message Stores close to the users supported (e.g., on a local network).
Location of gateways, firewalls and external connectivity may dictate server location.
Performance. Traffic estimates should be made, to determine optimum layout of servers and to choose appropriate hardware, network bandwidth and server number.

Review messaging redundancy. Once a core layout is determined, it should be reviewed in light of service requirements in the event of component failure. In particular:

Which servers require to be configured with fail-over clustering.
Redundant message routing and load sharing, so that single points of failure are minimized.

Plan overall message routing strategy. This may be clear from the server configuration, or may require separate design.
Design DIT (Directory Information Tree) layout. Where there are multiple servers, consideration needs to be given as to the structure of the DIT. In particular:

How servers are named, and where configuration is held.
How many routing trees are to be used.
Naming of administrators.
Interaction with other information stored in the directory.

Plan number, location and DIT content of directory servers. Where information is shared between multiple servers, it will make sense for data to be mastered in on directory server with shadow copies for resilience. It may make sense for all servers to hold all data, or to distribute data. Factors influencing this include:
- Ensuring that all messaging servers have high performance access to necessary configuration and routing data.
- Resilience in the event of network or server failure.

Putting in Place a Deployment

The details of a specific deployment roll-out, the level of configuration testing, and the amount of scripting used to automate roll-out will depend heavily on the type of deployment planned. Some general guidelines:

Deploy the directory servers first. Given that the messaging infrastructure relies on the directory infrastructure, it is cleanest to put this in place at the start.
Configure in the messaging administrator accounts.
Configure core message switches, and then systems and clients at the boundary.

Documentation List

Documentation