Skip navigation

A Dynamic Duo: Microsoft Exchange and the X.400 Connnector


Learn how to get these two powerful allies to join forces so they can battle the evil forces of high traffic and slow connections

Microsoft Exchange and the X.400 connector might sound like comic-book heroes who battle the forces of evil to save the world from doom. But you won't read about this dynamic duo's quest in comic books; instead, you'll read about this quest in computer books. Rather than having the world's fate being stake, for this dynamic duo networks communications capability are at stake. Exchange and the X.400 connector combine their strengths to battle the evil forces of high traffic and slow connections.

You don't have to partner Exchange with the X.400 connector. You can use several different types of connectors to establish communications between an Exchange server and other Exchange server sites or between an Exchange server and other messaging systems. In fact, one commonly used connector is the site connector. But the X.400 connector can provide several distinct advantages over the site connector.

Why Is the X.400 Connector Better?
Why use an X.400 connector and not a site connector? Although some experts will tell you that the site connector is easier to configure, works faster in sending messages, and has been optimized for intrasite communication, you can find several reasons for using an X.400 connector instead.

The first reason is that Exchange uses connectors between sites for more than messages. Directory updates, public folder data, and system status messages all flow across site boundaries through the configured connector. The X.400 connector lets you schedule the transfer of such updates, data, and messages from your network to another; the site connector does not. The ability to schedule transmissions can be critical. For example, if you incur costs when using the available network bandwidth during a certain time, the X.400 connector can help you minimize costs by scheduling your message-transfer activities around that time. Or, if you compete with other applications for network time, you can arrange to send large amounts of data across WAN links during off-peak times.

Using a set of X.400 connectors between your Exchange sites will also provide the immediate benefit of better message tracking and tracing capabilities. X.400 message logging is far more detailed than with site connectors. More detailed logs can help you determine message paths and troubleshoot problems.

Another reason to use X.400 is that the site connector uses remote procedure calls (RPCs). If a network has unreliable or slow links between sites, RPCs can cause timeouts. In contrast, the X.400 connector doesn't use RPCs to communicate with other systems, so you can use it for any network--including slow and unreliable ones.

Finally, an X.400 connector not only links your various Exchange sites, but it also links your system to the world of X.400 messaging. Most Fortune 1000 companies support X.400 as the message transfer protocol for communications between companies and within a company. International companies also endorse using X.400 because it supports expanded character sets and has attachment handling capability.

Now that you know the benefits of using an X.400 connector, here are some insights into installation and configuration. These insights will help ensure a successful installation.

Insights into Installation and Configuration
Before you can install an X.400 connector, you need to understand how it interacts with a network. The Open Systems Interconnect (OSI) seven-layer model in Figure 1 illustrates this interaction.

The model brings to light several important characteristics. First, the model points out that you need a pair of connectors between any two sites to be connected in Exchange. For example, to connect a site in New York with a site in Colorado, you need at least two X.400 connectors.

Second, the model illustrates Exchange's layered approach to putting applications on the network. Each layer relies on the underlying layer for services. If a lower layer is missing, the system halts at that point. Thus, you need a bottom-up approach to building applications.

Third, the model shows that you need the appropriate protocols before you can build an application. In the case of the X.400 connector, you need both a network protocol (because Exchange relies heavily on the Windows NT server for network services) and a transport protocol (because the X.400 is an OSI application). The X.400 connector supports three network protocols: IP, Connectionless Network Protocol-OSI (CLNP-OSI), and X.25 protocol. It also supports three transport protocols: TCP; OSI Transport Protocol, class 4 (TP4); and OSI Transport Protocol, class 0 (TP0).

Table 1 shows how you can pair the transport and network protocols. You are likely familiar with the famous Internet pair of TCP/IP. Originally used as a WAN protocol, TCP/IP is rapidly becoming the LAN protocol of choice for company intranets. Request for Comments (RFC) 1006 defines how to run X.400 messaging over TCP/IP.

X.25 is a WAN and OSI protocol. As an OSI protocol, X.25 provides network services to OSI transport classes TP0 through TP4. TP0 provides a lower level of service than does TP4, which is why TP0 runs over X.25, a very robust, connection-oriented protocol. Similarly, TP4 runs over CLNP because CLNP is a less robust, connectionless protocol.

Although you can use all three pairs, my experience is that TCP/IP is the best choice when you're using a pair of X.400 connectors to link two internal Exchange sites. When you use X.400 connectors to link an internal Exchange organization to the outside world, the TP0 and X.25 pair is the best because X.25 is the most used in the interconnection area. (TCP/IP is gaining popularity in this area, however.) Trailing the field is the TP4 and CLNP pair. The reason is simple: Few systems have implemented the CLNP network protocol, and as a result, it suffers from a lack of presence. Given the Internet's and TCP/
IP's growing popularity, TP4/CLNP will probably soon disappear altogether.

Enough theory--now it's time to get into the mechanics of installing and configuring X.400 connectors. (But if you want to learn more about the OSI model or X.400, you can download the osi.hlp and x400.hlp files from http:// The following examples show you how to install and configure connectors between two internal Exchange sites and between an internal Exchange site and an external X.400 messaging site.

Installing Connectors Between Two Internal Sites
Suppose you want to link your two Exchange sites in New York and Colorado with X.400 connectors. A WAN connection runs between the two sites, and NT servers are running TCP/IP as the protocol of choice. You have already installed Exchange 5.0 on NT Server 4.0. Because your system uses Windows Internet Name Service (WINS) and Dynamic Host Configuration Protocol (DHCP), you use host names for the configuration. You decide to install the X.400 connectors using the TCP/IP transport and network protocols. You can install the connectors in three steps.

STEP 1: Install a transport stack.
From the Exchange Administrator, click File, New Other, and MTA Transport Stack. Select the TCP/IP MTA Transport Stack option and your server from the configuration window. Let all stack options remain at their default values. Click OK.

This step is deceptively simple because you have already addressed many of the networking issues when you installed the NT TCP/IP network. At this point, you are merely linking the Mail Transfer Agent (MTA) into the network. Because you are going from one Exchange server to another, you do not need to make any other parameter changes in the administration program.

Although this step is simple, you need to be aware of one possible glitch. You must create a transport stack first. If you don't, you will get an error message telling you that no transport stack exists. If you already have a different transport stack created, you will still want to create a TCP/IP transport stack.

STEP 2: Create an X.400 connector and link it to the TCP/IP transport stack.
From the Exchange Administrator, select File, New Other, and X.400 Connector. Next, choose the TCP/IP X.400 Connector, and then click OK. For each property page, fill in the appropriate values following the guidelines shown in Table 2, page 147. For the last value of address space in Table 2, you need to check your system configuration. For example, for the setup shown in Screen 1, a valid X.400 address space is . The MTA name is SATELLITE, which is the NT server name in the configuration.

Once you enter the appropriate values, click OK to return to the Exchange Administrator Mail window. You will receive a warning dialog box that alerts you to the necessity of configuring both sides of the connection before messages will be sent successfully. This message means that you will need to configure an X.400 connector and TCP/IP MTA stack on the system at the other site. In other words, you need to repeat steps 1 and 2 at the other site.

STEP 3: Establish directory replication between the sites.
After you have installed both of the X.400 connectors, you need to establish directory replication by configuring a directory replication connector. To begin, select File, New Other, and Directory Replication Connector from the Main Admin Program screen. Next, select the remote site name from the list, and type in the server name of the target server at the remote site. Select No, the Remote Site Is Not Available on this Network, and click OK.

At this point, you will see the Directory Replication Connector Properties dialog box shown in Screen 2. Change the Display name and the Directory name from the default names to names that are meaningful within your organization; for example, X400Directory and X400Directory, respectively. (If possible, make the display and directory names the same to avoid confusion.) Next, in the Site Name box, list the remote site that you are connecting to (i.e., the site you want to replicate directories with). For the local and remote bridgehead servers, you can change the target servers if you have multiple servers at each site. It is important to understand that, at this point, you are configuring one server at each site that will act as the focal point for directory updates between the local servers at the main site and the target server at the remote site. Instead of having all servers in each site freely replicating with each other, you are assigning certain servers this responsibility in an effort to efficiently use the link between sites.

After you enter the correct properties, click the Schedule tab. For testing purposes, choose Always, which triggers update requests to the remote server every 15 minutes. Once the X.400 connection is working, you can choose a button that best reflects your desired schedule for directory updates. However, do not select Never because this selection will disable replication for this connector.

If you want to configure a directory replication hub, click the Sites tab. Specify which inbound sites you want updates from and which outbound sites you want to send updates to. Click OK; you now have a Directory Replication connector established between the main site and the remote site.

If you click on the main site and then Expand Configuration in the Main Admin Program screen, the connector you just established will appear under the Directory Replication icon. The Main Admin Program screen will also show the remote site once the connector runs the first time, even if it is unsuccessful at establishing contact with remote site. The local copy of the directory will also contain the Site and Configuration objects. Depending on network bandwidth and availability, the time to complete replication will vary. Because this link is remote, do not expect instant gratification.

Installing and Configuring Connectors Between an Internal and External Site
Suppose you want to link your Exchange organization site in Colorado with an X.400 messaging system in Texas. You decide to install an X.400 connector using the TP0 and X.25 transport and network protocols. After you install and configure the underlying software and hardware, you can install and configure the X.400 connector in three steps.

STEP 1: Install the EiconCard and software.
Eicon Technology ( supplies the software, WAN Services for NT, and the interface card you need to connect your system directly to X.25 interconnect services. The procedure to install the Eicon software and card depends on which version of the software you have. With version 2.x and greater, you simply insert the card into the appropriate slot in the PC and load the CD-ROM, letting NT find the hardware and prompt you to install the software. With the 1.x version, you might need to add the Eicon software and card to your NT server in the traditional manner of using the Network Settings portion of the Control Panel.

STEP 2: Configure the EiconCard and software.
The Eicon configuration program is a graphical program that is easy to navigate and use. Even better, you need to configure only WAN services, making the configuration process relatively painless.

To begin, go to the WAN Services - Configuration dialog box shown in Screen 3. Under WAN Services, you will find configuration settings for High-Level Protocols, X.25, HDLC, and Direct for each installed card. These settings must match the parameters set by the network service provider. Thus, you will need the following information before you configure WAN Services:

* Node type: Most nodes are data terminal equipment (DTE). Most modems are data circuit-terminating equipment (DCE). The node type determines, among other things, what types of control signals pass on the wire and which of the devices is responsible for providing those control signals. If you configure both the node type and modem to be DTE or DCE, confusion will result at the hardware level and the end systems will not communicate. People often make this error, especially when they read the RS232 definition of DTE and DCE.

* DTE address: This address is analogous to your network phone number. Your network service provider can provide your DTE address.

* Type and number of virtual circuits: With X.25, you can have multiple virtual circuits on one physical connection, usually in multiples of four. (The charge for service increases accordingly.) Most standard configurations contain four virtual circuits.

* Packet sizes (minimum and maximum allowable): These parameters must match the network service provider's specifications. If the parameters don't match, excessive negotiation and timeouts can lead to failed connections and circuit delays.

* Window sizes (minimum and maximum allowable): The window size specifies how many outstanding packets that require acknowledgement can be sent before the sending system requests acknowledgement. These parameters must match the network service provider's specifications. Improper settings can cause significant transmission delays.

In addition to needing this information to configure WAN Services, you will need it for another reason. X.25 network services providers often require you to submit a detailed, preinstallation configuration document that contains these parameters and addresses.

STEP 3: Install a new MTA Transport Stack.
Assuming that you already have installed the TCP/IP MTA Transport Stack and Eicon's WAN Services for NT, you need to add a new transport stack: the Eicon X.25 MTA Transport Stack. From the Main Admin Program screen, select File, New Other, MTA Transport Stack, and Eicon X.25 MTA Transport Stack. Select the local server, and then click OK. The Eicon X.25 General Properties page will appear. You can either accept the default name or change it. Fill in the X.121 Address field with the number your service provider supplies you. (Your service provider might refer to this number as the DTE or data network identification code--DNIC--address.) Often, you can leave the Call User Data, Facilities Data, and OSI Address boxes blank. (Your service provider will have this information, if you need it.)

The T, S and P selectors on the General Properties page distinguish among multiple software stacks running on a host system and are required when you're connecting to many computer systems for the purposes of transferring X.400 messages. A nice feature of the General Properties configuration page is the Hex and Text buttons. If you select Hex, Eicon X.25 will display T, S, and P selector values in hex. If you select Text, Eicon X.25 will display the selector values in US ASCII text.

On the General Properties page, select the I/O port associated with the Eicon card installed (usually port 1.) Select the Leased Line button for direct connection via a leased circuit. Select OK. You will see that your choices now include a TCP/IP X.400 connector and an Eicon X.25 X.400 Connector. Congratulations, you now have installed multiple transport stacks with NT Server and linked them to Exchange.

The Dynamic Duo Awaits
Now that you have the necessary hardware, software, and protocols in place, the dynamic duo of Exchange and the X.400 connector are ready to battle the evil forces of high traffic and slow connections. By establishing reliable, fast, and cost-effective communications, this dynamic duo can help save your day.

OSI and X.400 Help files discussed on page 144 are available for downloading from Windows NT Magazine's Web site at

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.