Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

November 01, 1997 12:00 AM

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

Windows IT Pro
InstantDoc ID #17
Rating: (0)
Downloads
17.zip

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://
www.winntmag.com.) 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.

Related Content:

ARTICLE TOOLS

Comments
  • harish
    10 years ago
    Apr 16, 2002

    good

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.