Lesson 2: Connecting Routing Groups

Exchange 2000 Server provides numerous messaging connectors, but not all can be used to link routing groups together. A connector must be able to handle messages in native Exchange formats and support link state information. Only the Routing Group Connector (RGC), SMTP Connector, and X.400 Connector are able to fulfill the requirements. For load balancing and fault tolerance, configure multiple bridgehead servers between two routing groups.

This lesson introduces the main connectors of Exchange 2000 Server for routing groups. Connections to earlier versions of Exchange Server and connections over dial-up links are also covered.


At the end of this lesson, you will be able to:

  • Configure the main connectors of Exchange 2000 Server.
  • Explain how to connect to Exchange Server 5.5 sites.
  • Use dial-up connections for message transfer.

Estimated time to complete this lesson: 90 minutes


Routing Group Connector

The RGC is the easiest connector to install and more powerful than the others. It provides a high level of fault tolerance because it supports multiple source and destination bridgehead servers. Multiple bridgeheads can guarantee message delivery even if a particular server is shut down. Because it provides many advantages, it is typically the preferred connector. The RGC, as its name implies, can only be used to provide a message path between routing groups in the same organization. In native Exchange 2000 Server environments, the RGC transfers messages in transport-neutral encapsulation format (TNEF) based on SMTP.

TIP


Although messages are transferred in TNEF and not in plain text, messages are not encrypted between bridgehead servers. Experienced intruders will be able to disclose the message content. To encrypt the server-to-server communication, use IP Security (IPSec) tunnels. Microsoft Windows 2000 Server supports IPSec.

Local and Remote Messaging Bridgeheads

It is important to note that the RGC is able to try any SMTP virtual server in the local and remote routing group without message rerouting. Only if all configured remote bridgeheads are unavailable is the RGC is marked as down. Messages are then rerouted to another connector.

You can specify local virtual bridgehead servers in the connector's General tab. By default, the Any Local Server Can Send Mail Over This Connector option is selected and all servers in the local routing group act as outbound bridgehead servers. If you want to implement dedicated bridgehead servers, select the These Servers Can Send Mail Over This Connector option instead, and specify the bridgeheads explicitly. Servers in the local routing group that are not explicitly listed must send their messages to a local bridgehead server first.

Remote bridgehead servers are specified in the Remote Bridgeheads tab. Multiple bridgeheads provide load balancing and fault tolerance, whereas single bridgeheads allow you to implement servers with dedicated purposes in your organization. To resolve a remote bridgehead's host name into an IP address, the local bridgehead relies on the DNS. If DNS cannot provide a valid IP address, NetBIOS name resolution is attempted. Microsoft Windows 2000 Server can automatically register A records when using Windows 2000 dynamic DNS. In this situation, you do not need to manually configure any DNS records for remote bridgehead servers.

Direction of Message Transfer

You should keep in mind that RGCs operate unidirectionally, meaning messages are transferred in only one direction. Hence, for full messaging connectivity, you need to configure RGCs in both connected routing groups. When you create an RGC, Exchange System Manager can retrieve most configuration parameters from the local instance to configure the opposing connector automatically for you.

Configuration Settings

To create a new RGC, expand the desired routing group (for example, First Routing Group), right-click Connectors, point to New, and then select Routing Group Connector. This will display a Properties dialog box with six tabs. At a minimum, you need to specify a name in the General tab, click on the Remote Bridgehead tab, and specify a remote bridgehead server.

The following are the Routing Group Connector Properties dialog box tabs:

  • General. Use this tab to define a name for this RGC, define the remote routing group to which this connector is supposed to transfer messages, and specify which SMTP virtual servers in the local routing group are allowed to transfer messages directly to the remote routing group. In addition, you can determine a cost value for the connection, which defines a preference level for this connector if multiple connectors are able to transfer messages to the same destination. Connectors with lower cost values are taken first. You can also select the Do Not Allow Public Folder Referrals check box to prevent Outlook 2000 users from accessing public folder resources in the remote routing group.
  • Remote Bridgehead. Use this tab to define SMTP virtual servers in the remote routing group that receive messages directly from this connector. All other servers receive messages indirectly via the bridgeheads. When connecting to an earlier version of Exchange Server, you also can specify the site services account of the remote site under Override Connection Credentials For Exchange 5.x.
  • Delivery Restrictions. Use this tab to specify who is allowed to send messages over this connector. By default, messages are accepted from everyone.
  • Content Restrictions. Use this tab to specify which type of messages can traverse the connector according to priority (High, Normal, or Low), message type (System Messages or Non-System Messages), and message sizes (Allowed Sizes).
  • Delivery Options. Use this tab to specify when normal messages are allowed to traverse the connector (Connection Time). It is possible to specify a size limit for oversized messages and configure a separate activation schedule for these messages.
  • Details. Use this tab to specify an administrative note for informative purposes.

Exercise 2: Configuring a Routing Group Connector

In this exercise you will connect two routing groups by means of an RGC. You will test the configuration by sending test messages, which will only work in one direction.

To view a multimedia demonstration that displays how to perform this procedure, run the EX2CH16*.AVI files from the \Exercise_Information\Chapter16 folder on the Supplemental Course Materials CD.

Prerequisites

  • Complete Exercise 1, earlier in this chapter.
  • Make sure BLUESKY-SRV1 and BLUESKY-SRV2 are available in the test environment.
  • Log on as Administrator to BLUESKY-SRV1 and BLUESKY-WKSTA.

To configure an RGC

  1. On BLUESKY-SRV1, launch Exchange System Manager, and, in the console tree, expand all nodes including the container called Second Routing Group.
  2. Under Second Routing Group, right-click Connectors, point to New, and select Routing Group Connector.
  3. In the General tab, under Name, type RGC to First Routing Group.
  4. Under Connects This Routing Group With, make sure First Routing Group (First Administrative Group) is displayed (see Figure 16.7).

    click to view at full size

    Figure 16.7 Configuring an RGC

  5. Click on the Remote Bridgehead tab, and click Add.
  6. In the Add Bridgehead dialog box, select BLUESKY-SRV1 - Default SMTP Virtual Server, and then click OK.
  7. Click on the Delivery Options tab, and verify that Always Run is displayed in the Connection Time list box.
  8. Click OK, and in the Exchange System Manager dialog box that prompts you to create the RGC in the remote routing group as well, click No.
  9. Allow some time for Active Directory replication, and then, on BLUESKY-SRV1, send another test message to Carl Titmouse. You should notice that the test message is delivered to Carl; however, he will not be able to reply to this message (see Figure 16.8).

    click to view at full size

    Figure 16.8 Unidirectional message transfer

Exercise Summary

The configuration of an RGC is quickly accomplished. However, because RGCs operate unidirectionally, you have to configure a separate connector in every routing group. Otherwise, users might be able to receive messages, but they will not be able to reply. Exchange System Manager will prompt you to configure an RGC in both routing groups.

SMTP Connector

The primary purpose of the SMTP Connector is to connect an Exchange 2000 organization to foreign SMTP systems, such as SMTP hosts on the Internet or other Exchange 2000 organizations. The SMTP Connector can also be used instead of an RGC to provide messaging connectivity between routing groups in a single Exchange 2000 environment.

TIP


It is advantageous to configure an SMTP Connector to provide Internet connectivity. The connector settings have higher priority than the settings for SMTP virtual servers. You have the ability to define dedicated bridgehead servers.

RGC Versus SMTP Connector

Both the RGC and SMTP Connector use SMTP for message transfer. The RGC is easier to maintain, but the SMTP Connector gives you more control over your routing configuration.

Consider the configuration of an SMTP Connector instead of an RGC in the following situations:

  • You need to configure outbound security settings, such as Transport Layer Security (TLS), to encrypt data transferred over the connection without the need for IPSec and to use specific account information for authentication.
  • You need to connect to a foreign SMTP host, such as the Internet Mail Service (IMS) of an earlier version of Exchange Server, or to another Exchange 2000 organization.
  • You need to issue a TURN, ATRN, or ETRN command to request mail from the queue on a remote SMTP virtual server.
  • You want to queue e-mail messages for remote triggered delivery.

DNS and Smart Host Configurations

When connecting to the Internet, the SMTP Connector is able to look up external DNS servers for mail exchanger (MX) records that correspond to Internet domain names specified in recipient addresses. This allows for direct message routing to destination domains. DNS was briefly introduced in Chapter 11, "Internet-Based Client Access," and is covered at length in the Windows 2000 Server TCP/IP Core Networking Guide of the Windows 2000 Resource Kit.

Especially over dial-up connections, Internet service providers (ISPs) typically provide their customers with a smart host that relays outgoing messages on behalf of the customer's SMTP host. In this situation, the SMTP Connector should not use DNS, but should forward all outgoing messages to the smart host. You can specify the host name or the smart host's IP address (in square brackets) in the SMTP Connector's General tab under Forward All Mail Through This Connector To The Following Smart Hosts.

If you want to forward messages for a particular domain to a smart host other than the default, configure two individual SMTP Connectors (see Figure 16.9). In the Address Space tab of the connector to the Internet, define an address space of type SMTP with an address of * (for example, SMTP: *). For the connector to the downstream domain, on the other hand, specify the corresponding smart host, and, in the Address Space tab, define a detailed address space, such as SMTP: downstream-domain.com. The most detailed address space match wins. Consequently, for all e-mail addresses of <recipient>@downstream-domain.com, Exchange 2000 Server selects the connector that is forwarding the messages to the correct smart host. You can read more about the configuration of address spaces in Lesson 3.

click to view at full size

Figure 16.9 Multiple SMTP Connectors for different destinations

As mentioned, parameters of an SMTP Connector have higher priority than the settings of SMTP virtual servers. However, if a recipient address does not match any connector's address spaces, the settings of the SMTP virtual server apply for message delivery. By default, Exchange 2000 Server attempts to locate the remote SMTP host using DNS until you change the delivery options of the SMTP virtual server as explained in Chapter 15, "SMTP Transport Configuration."

SMTP Connectors Between Routing Groups

DNS cannot be used when an SMTP Connector is used to link routing groups together because messages are transferred within the same e-mail domain. Consequently, you need to activate the Forward All Mail Through This Connector To The Following Smart Hosts option and specify the name or IP address (in square brackets) of an existing server in the remote routing group. In the General tab, under Local Bridgeheads, you can specify multiple local bridgehead servers to connect to the remote Exchange 2000 smart host for message delivery.

Retrieving Mail Through ETRN

Modern Extended STMP (ESMTP) systems, including Exchange 2000 Server, support the ETRN command, which is used to signal a remote ESMTP server to send its queued messages to the local host. The remote ESMTP server must be configured to receive and hold messages on behalf of the local destination domain. Messages will be requested based on fully qualified domain names (FQDNs), such as Bluesky-inc-10.com. Defined in RFC 1985, ETRN is commonly accepted across the Internet today.

The SMTP Connector supports the ETRN command completely. That means the SMTP Connector can use ETRN to request data from a remote host and it can answer incoming ETRN requests by sending queued messages to the requesting system. You can read more about recipient policies in Chapter 13, "Creating and Managing Recipients."

Configuration Settings

To create an SMTP Connector, expand the desired routing group (for example, First Routing Group), right-click Connectors, point to New, and then select SMTP Connector. This will display a Properties dialog box with eight tabs. At a minimum, you need to specify a name in the General tab and define a local bridgehead server. If you are connecting routing groups, you also need to specify a remote SMTP virtual server in the form of a smart host, then click on the Connected Routing Groups tab and specify a remote routing group. If you connect to the Internet instead, make sure you define an address space of the type SMTP.

The following are the SMTP Connector Properties dialog box tabs:

  • Address Space. Use this tab to identify the SMTP domains that this connector is supposed to transfer messages to. You can also define the scope of the connector as global (available in the entire organization) or local (available in the local routing group only) and select whether to allow messages to be relayed for the specified domains.
  • Advanced. Use this tab to configure outbound security, to specify whether to send a HELO instead of a EHLO command to the remote SMTP host (which can be useful if the remote SMTP host does not support ESMTP), and to specify whether to issue an ETRN or TURN command when connecting to remote hosts for message retrieval.
  • Connected Routing Groups. Use this tab to specify the names of remote routing groups that can be reached through this SMTP Connector.
  • Content Restrictions. Use this tab to specify which type of messages can traverse the connector according to priority (High, Normal, or Low), message type (System Messages or Non-System Messages), and message size (Allowed Sizes).
  • Delivery Options. Use this tab to specify when normal messages are allowed to traverse the connector (Connection Time). You can also specify a size limit for oversized messages and configure a separate activation schedule for these messages. In addition, the SMTP Connector allows you to queue mail for remotely triggered delivery.
  • Delivery Restrictions. Use this tab to specify who is allowed to send messages over this connector. By default, messages are accepted from everyone.
  • Details. Use this tab to specify an administrative note for informative purposes.
  • General. Use this tab to define a name for the SMTP Connector, to define whether to use DNS and MX records for message delivery or to forward all messages to a smart host, and to specify the SMTP virtual servers in the local routing group that can use this connector to transfer messages to the remote SMTP host. In addition, you can select the Do Not Allow Public Folder. Referrals check box to prevent Outlook 2000 users from accessing public folder resources in the remote routing group.

Exercise 3: Configuring an SMTP Connector

In this exercise you will configure an SMTP Connector between two routing groups. You will continue the configuration of the test environment to enable bidirectional message transfer between BLUESKY-SRV1 and BLUESKY-SRV2.

To view a multimedia demonstration that displays how to perform this procedure, run the EX3CH16*.AVI files from the \Exercise_Information\Chapter16 folder on the Supplemental Course Materials CD.

Prerequisites

  • Complete Exercise 1, earlier in this chapter.
  • Make sure BLUESKY-SRV1 and BLUESKY-SRV2 are available in the test environment.
  • Log on as Administrator to BLUESKY-SRV1 and BLUESKY-WKSTA.

To configure an SMTP connector between two routing groups

  1. On BLUESKY-SRV1, in Exchange System Manager, expand First Routing Group, and, underneath, right-click Connectors, point to New, and select SMTP Connector.
  2. In the General tab, under Name, type SMTP Connector to BLUESKY-SRV2.
  3. Select the Forward All Mail Through This Connector To The Following Smart Hosts option, and, in the corresponding text box, type bluesky-srv2.bluesky-inc-10.com (see Figure 16.10).

    click to view at full size

    Figure 16.10 Configuring an SMTP Connector

  4. Click Add, and, in the Add Bridgehead dialog box, select BLUESKY-SRV1 - Default SMTP Virtual Server, and then click OK.
  5. Click on the Connected Routing Groups tab, then click Add. In the Properties dialog box, make sure First Administrative Group/Second Routing Group is displayed under Routing Group, and then click OK.
  6. Click on the Delivery Options tab, and make sure Always Run is displayed under Connection Time. Click OK.

    At this point, you should be able to reply as Carl Titmouse to the test message from the Administrator that was sent via the RGC in Exercise 2.

Exercise Summary

The configuration of an SMTP Connector differs from an RGC in that you have to specify the remote bridgehead server in the form of an SMTP host. It is also possible to use DNS MX records to locate the host that accepts messages for a particular Internet domain. Because the SMTP Connector may be used to connect to foreign SMTP systems, you must specify the remote routing group explicitly in the Connected Routing Groups tab.

X.400 Connector

Although Exchange 2000 Server relies on SMTP for native message transfer, deploying an SMTP-based communication infrastructure may not fit your organization's needs. This is particularly the case if your messaging backbone relies on X.400 and connects different e-mail systems together. Using an X.400 Connector, you can connect Exchange 2000 Server to any foreign X.400 system and to earlier versions of Exchange Server and Exchange 2000 Server in different routing groups or organizations.

TIP


Because of simplicity and faster message transport, it is advantageous to use the RGC and SMTP Connector between routing groups. Use X.400 Connectors to connect Exchange 2000 Server with external X.400 systems.

Microsoft Exchange Message Transfer Agent Service

Exchange 2000 Server supports the X.400 standard through its Microsoft Exchange Message Transfer Agent (MTA) Stacks service, which corresponds to an MTA of the 1988 conformance year. This X.400 MTA supports link state information for full X.400 and SMTP interoperability according to RFC 2156, and it uses LDAP for directory lookups. RFC 2156 describes Multipurpose Internet Mail Extensions (MIME) Internet X.400 Enhanced Relay functions.

MTA Transport Stacks

The MTA service of Exchange 2000 Server is able to utilize TCP/IP or X.25 for communication by means of an MTA transport stack, which must be added to the server before you can configure an X.400 Connector. Unfortunately, Exchange 2000 Server does not support the transport protocol class 4 (TP4) protocol because a TP4 protocol stack is not available for Windows 2000.

The TCP/IP transport stack allows you to establish X.400 connections over the Internet and virtual private networks (VPNs). Fortunately, all modern X.400 systems support TCP/IP over LAN connections. To install this stack, launch Exchange System Manager. Expand the desired administrative group, then Servers, then the desired server, and then open the Protocols container. Right-click X.400, point to New, and select TCP/IP X.400 Service Transport Stack. A dialog box will appear, allowing you to define Open Systems Interconnection (OSI) address information. Usually, you don't need to specify any configuration settings because the local protocol configuration is determined by Windows 2000. If desired, however, you can specify a transport service access point (TSAP), session service access point (SSAP), or presentation service access point (PSAP). TSAP, SSAP, and PSAP correspond to the text boxes labeled T Selector, S Selector, and P Selector.

The X.25 protocol, on the other hand, can be used to communicate with remote X.400 systems using a packet switching network. This is usually the case when connecting to a public X.400 provider. The X.25 protocol, also called TP0 (transport protocol class 0), is OSI compliant and designed specifically for WAN connections. A special computer adapter—an X.25 card—and a synchronous modem are required. Before you can install the X.25 X.400 Service Transport Stack, corresponding Windows 2000 protocol drivers need to be configured. The X.121 Address is the most important configuration parameter for X.25, yet all other settings, such as Call User Data and Facilities Data, must be specified precisely as well; otherwise, you will experience communication problems. X.25 configurations are challenging, and it is advisable to have an experienced specialist do the job. As usual, you can define additional service access points using the T Selector, S Selector, and P Selector; however, these options are not necessarily required for proper operation.

Configuring the X.400 Connector

As soon as an MTA transport stack has been installed, X.400 Connectors can be configured. This is a complex task, especially when connecting to a foreign X.400 system. Specify all configuration settings carefully, and make sure they match the configuration of the remote system. To begin the configuration, expand the routing group where you want to add the X.400 Connector, right-click Connectors, point to New, and select either TCP X.400 Connector or X.25 X.400 Connector, according to the configuration of your server. You will be confronted with a dialog box containing 10 tabs. The General tab, for example, is used to define a name for the new X.400 Connector object. You can also determine the desired MTA transport stack.

Connect Request Information

Every X.400 connection is a secured connection. In other words, an X.400 MTA that wants to contact another MTA must identify itself within its connect request. The identification information includes name and password for the local and remote MTA. If this information does not match the configuration of the remote X.400 system, the connection request will be refused and messages cannot be transferred.

The name and password of the local MTA can be determined in the properties of the X.400 object underneath the server's Protocols container. This information must be presented to the remote administrator so that the remote connector or MTA can be configured properly. You also need to retrieve the name and password of the remote MTA from the remote administrator to complete the configuration task yourself. The information must be entered in the Remote Connection Credentials dialog box that you can display by clicking Modify in the connector's General tab.

IMPORTANT


The MTA password is case-sensitive. If it is misspelled, connections cannot be established.

Transport Stack Configuration

The transport stack configuration, accomplished using the Stack tab, does not refer to the configuration of the local computer. At this location, you need to define the address information for the remote system, such as remote host name or IP address for a TCP/IP X.400 Connector, or the X.121 address for an X.25 X.400 Connector. Via the OSI Address button, you can also specify the SSAP, PSAP, and TSAP configuration of the remote MTA (S Selector, P Selector, and T Selector). The corresponding fields can be left blank if no additional service access points have been defined. You also need to inform the remote administrator about the transport stack configuration of your MTA transport stack.

Overriding Local Information

Especially when connecting to a public X.400 network, you may be forced to override the name and password of the local MTA. The public X.400 carrier provides the required information for you to use. To adjust the configuration on a per-connector basis, use the Override tab. Once specified, the X.400 Connector will use this information to establish connections with the remote system. The local MTA name and password, as defined in the properties of the server's X.400 object, will be ignored. Furthermore, you can adjust the various X.400 protocol parameters, such as Maximum Open Retries and Maximum Transfer Retries, which determine how often a connection or transfer attempt is carried out before messages are returned as undeliverable.

NOTE


When using an X.400 Connector over an on-demand dial-up connection, it may be advisable to increase the Maximum Transfer Retries to a value of 5. You can read more about the configuration of dial-up connections later in this lesson.

Connecting Routing Groups

Over extremely unreliable, low-bandwidth network links, it might be a good idea to use X.400 Connectors between routing groups. X.400 has the advantage of supporting graceful recovery of transfer associations. In many situations, message transfer can be resumed where it was interrupted. To specify remote routing groups for an X.400 Connector, use the Connected Routing Groups property page.

Keep in mind that the local and remote MTAs represent the only bridgehead servers in each routing group. If multiple bridgeheads are desired, configure additional X.400 Connectors on different computers running Exchange 2000 Server. A single server can support multiple X.400 Connectors, each using the same or different MTA transport stacks.

Advanced Configuration Issues

In the Advanced tab, you can specify X.400 features that should be enabled when connecting the organization to a foreign X.400 system. Important settings are the X.400 conformance year and X.400 body parts. The MTA conformance year, for instance, must match the conformance year of the foreign system because significant differences exist between the 1984 and 1988 X.400 standards. Otherwise, the local MTA overtaxes the remote MTA, and communication problems will occur.

NOTE


Exchange 2000 Server supports the 1988 X.400 standard. As the X.400 standard demands, MTAs of the 1992 conformance year must fall back to the 1988 conformance year for communication with 1988 MTAs.

When connecting to a remote Exchange MTA, make sure the Allow Exchange Contents check box is selected to send messages in native format without the overhead of message conversion. The native Exchange format is not X.400-conforming, but between Exchange MTAs this isn't an issue. Another important setting refers to the global domain identifier (GDI) of the remote system, which prevents message transfer loops.

The following are the X.400 Connector Properties dialog box tabs:

  • Address Space. Use this tab to define the type and format of routing addresses. Cost values are associated with address spaces to optimize the routing. In addition, you can specify whether this connector is available to the entire organization or restricted to the local routing group.
  • Advanced. Use this tab to specify X.400 message formats and transfer procedures when sending messages to a remote X.400 system or Exchange 2000 server.
  • Connected Routing Groups. Use this tab to specify the names of remote routing groups that can be reached through this X.400 Connector.
  • Content Restrictions. Use this tab to specify which type of messages can traverse the connector according to priority (High, Normal, or Low), message type (System Messages or Non-System Messages), and message size (Allowed Sizes).
  • Delivery Restrictions. Use this tab to specify who is allowed to send messages over this connector. By default, messages are accepted from everyone.
  • Details. Use this tab to specify an administrative note for informative purposes.
  • General. Use this tab to define a name, the remote X.400 MTA and password, and the transport stack. You can also specify whether remote clients support the Messaging Application Programming Interface (MAPI) and whether to allow public folder referrals.
  • Override. Use this tab to override default X.400 attributes of the local MTA.
  • Schedule. Use this tab to set the communication schedule. Never, Always (communication occurs constantly), Selected Times (up to 15-minute intervals), and Remote Initiated may be configured.
  • Stack. Use this tab to specify required address information, such as remote host name or IP address (or X.121 address), and service access points for the remote system.

Exercise 4: Configuring a TCP/IP-Based X.400 Connector

In this exercise you will configure and test an X.400 Connector between two routing groups. To successfully test the configuration, you should remove the existing connectors from the test environment. Otherwise, test messages may bypass the X.400 Connector.

To view a multimedia demonstration that displays how to perform this procedure, run the EX4CH16*.AVI files from the \Exercise_Information\Chapter16 folder on the Supplemental Course Materials CD.

Prerequisites

  • Start BLUESKY-SRV1, BLUESKY-SRV2, and BLUESKY-WKSTA, and make sure they are operational.
  • Log on as Administrator to BLUESKY-SRV1 and BLUESKY-WKSTA.
  • If you have completed all previous exercises in this chapter, delete the existing connectors between the First Routing Group and the Second Routing Group.

To configure a TCP/IP-based X.400 Connector between two routing groups

  1. On BLUESKY-SRV1, in Exchange System Manager, expand Servers, expand BLUESKY-SRV1, expand Protocols, right-click the X.400 container, point to New, and select TCP/IP X.400 Service Transport Stack. Accept the default settings and click OK.
  2. Right-click the X.400 container and select Properties. Note that the Local X.400 Name is set to BLUESKY-SRV1.
  3. Click Modify, delete any entries under Password and Confirm Password, and then click OK twice.
  4. Expand BLUESKY-SRV2, expand Protocols, right-click the X.400 container, point to New, and select TCP/IP X.400 Service Transport Stack. Accept the default settings and click OK.
  5. Right-click the X.400 container and select Properties. Verify that the Local X.400 Name is set to BLUESKY-SRV2.
  6. Click Modify, delete any entries under Password and Confirm Password, and then click OK twice.
  7. Expand Routing Groups, expand First Routing Group, and, underneath, right-click Connectors. Point to New and select TCP X.400 Connector.
  8. Under Name, type X.400 to BLUESKY-SRV2.
  9. Under Remote X.400 Name, click Modify, and, in the Remote Connection Credentials dialog box, under Remote X.400 Name, type BLUESKY-SRV2. Clear any entries under Password and Confirm Password, and then click OK.
  10. Click on the Schedule tab, and verify that the Schedule is set to Always.
  11. Click on the Stack tab, make sure the Remote Host Name option is selected, and, under Name, type BLUESKY-SRV2.
  12. Click on the Connected Routing Groups tab, and click Add.
  13. In the Properties dialog box, under Routing Group, make sure First Administrative Group/Second Routing Group is selected, and then click OK.
  14. Click on the Advanced tab, and verify that the Allow Exchange Contents check box is selected.
  15. Click OK, and, in the Exchange System Manager dialog box informing you that you must configure both sides of this connection before messages can be sent, click OK.

    At this point, you have configured the first part of the X.400 Connector on BLUESKY-SRV1 (see Figure 16.11).

  16. Expand Second Routing Group, and, underneath, right-click Connectors, point to New, and select TCP X.400 Connector.
  17. Under Name, type X.400 to BLUESKY-SRV1.
  18. Under Remote X.400 Name, click Modify, and, in the Remote Connection Credentials dialog box, under Remote X.400 Name, type BLUESKY-SRV1. Clear any entries under Password and Confirm Password, and then click OK.
  19. Click on the Schedule tab, and verify that the Schedule is set to Always.
  20. Click on the Stack tab, and make sure the Remote Host Name option is selected. Under Address, type BLUESKY-SRV1.
  21. Click the Connected Routing Groups tab, click Add, and, in the Properties dialog box, under Routing Group, make sure First Administrative Group/First Routing Group is selected, and then click OK.
  22. Click on the Advanced tab, and verify that the Allow Exchange Contents check box is selected.
  23. Click OK, and, in the Exchange System Manager dialog box informing you that you must configure both sides of this connection before messages can be sent, click OK.

    click to view at full size

    Figure 16.11 Configuring an X.400 Connector on BLUESKY-SRV1

    At this point, you have completed the configuration of the X.400 messaging link between the First and the Second Routing Group (see Figure 16.12).

    click to view at full size

    Figure 16.12 Two sides of one X.400 Connector

  24. On BLUESKY-WKSTA, log on as Administrator, and send a test message to Carl Titmouse, then log on as the latter, and check whether the test message has been received. Reply to the message, log off, log on as Administrator again, and check that the communication works in both directions.

Exercise Summary

The X.400 Connector is the most complex connector of Exchange 2000 Server. It requires careful configuration of MTAs, X.400 transport stacks, and X.400 Connector components on both ends of the communication link. The configuration must match exactly. Any error, such as a misspelled remote X.400 name, will cause the remote MTA to reject incoming connections, and messages will not be transferred. Message transfer in one direction does not necessarily mean that the other direction is operational as well.

Previous Exchange Connectors

As outlined in Chapter 6, "Coexistence with Previous Microsoft Exchange Server Versions," Exchange 2000 Server can operate in mixed mode to support seamless integration with earlier versions of Exchange Server. This implies that users on the old system can use new Exchange 2000 connectors for message transfer, and vice versa.

Exchange 2000 Server and Earlier Versions in the Same Site or Routing Group

Within the same site or routing group, X.400 over remote procedure call (RPC) is used for server-to-server communication between Exchange 2000 Server and earlier versions of Exchange Server. For native message transfer between computers running Exchange 2000 Server, however, SMTP over TCP/IP is preferred over RPC.

Before you can add Exchange 2000 Server to an existing Exchange Server organization, you need to deploy the Active Directory Connector (ADC). Among other things, ADC, in conjunction with Site Replication Service (SRS), replicates connector and routing information from the existing organization with Active Directory directory service, which allows Exchange 2000 Server to discover and route messages to existing Exchange 5.5 connectors. ADC and SRS are covered in more detail in Chapter 6, "Coexistence with Previous Microsoft Exchange Server Versions."

NOTE


Users with mailboxes on the new system are able to benefit from existing Exchange 5.5 connectors that are not supported in Exchange 2000 Server, such as the Professional Office System (PROFS) Connector.

Gateway Address Routing Table

Earlier versions of Exchange Server use a Gateway Address Routing Table (GWART) for message routing. Exchange 2000 Server relies on connector configurations stored in the configuration naming context of the Active Directory directory service and link state information instead. Nevertheless, a GWART is generated and replicated to Exchange Server 2000. This is an important feature because it allows users with mailboxes on Exchange Server 5.5 to send messages across any connector, including Exchange Server 2000 connectors.

NOTE


Earlier versions of Exchange Server can use Exchange 2000 connectors because ADC and SRS replicate Exchange 2000 routing information to the Exchange Server directory.

Communication Using Messaging Connectors

The RGC of Exchange 2000 Server provides features similar to the Site Connector of Exchange Server 5.5. As a matter of fact, when using the RGC to connect to an Exchange 5.5 server, RPCs are used automatically instead of SMTP. Hence, you can use the RGC to transfer messages to a Site Connector, and vice versa. You need to specify the required Site Services account for the remote Exchange 5.5 server in the Routing Group Connector's Remote Bridgehead tab.

The SMTP Connector is the counterpart of the Internet Mail Service in earlier versions of Exchange Server. Consequently, if you want to transfer messages to a remote site via SMTP, configure a dedicated SMTP Connector as you would to connect to another remote routing group.

Although the X.400 MTA of Exchange 2000 Server provides enhancements over earlier versions, substantial features remained unchanged. Hence, you will find it straightforward to connect Exchange 2000 Server to a remote system running Exchange Server 5.5 via X.400.

Connectors over Dial-Up Connections

When configuring the various main messaging connectors, you will find that direct support for dial-up connections is missing. A Dynamic Remote Access Service (RAS) Connector is not available, nor does any Exchange 2000 connector provide a Dial-Up Connections tab. Nevertheless, all main connectors (RGC, SMTP Connector, and X.400 Connector) support on-demand dial-up connections by means of Windows 2000 Routing and Remote Access Service.

Let's say you want to use an SMTP Connector to connect to a smart host provided by your ISP over a dial-up connection. In a first step, install and configure your modem or Integrated Services Digital Network (ISDN) under Windows 2000. In a second step, enable Routing and Remote Access Service via the Routing and Remote Access utility from the Administrative Tools program group, and configure the server as a network router. Make sure you specify use of demand-dial connections to access remote networks. As soon as Routing and Remote Access Service is active, add a new routing interface to the configuration. Within the Routing and Remote Access utility, open the local server container in the console tree, right-click Routing Interfaces, and select New Demand-Dial Interface. Define the required settings to connect to your ISP in the Demand Dial Interface Wizard, select the desired modem or ISDN adapter, and make sure to route IP packets on this interface. Define the correct dial-in credentials and finish the configuration. After that, right-click the new demand-dial router object in the details pane, and select Set IP Demand-Dial Filters. To prevent any other machines from accessing the dial-up connection, specify the exact IP addresses of the local SMTP Connector and the ISP's smart host by using a subnet mask of 255.255.255.255. After that, you can configure the messaging connector as if it were making a LAN connection. You can read more about the Routing and Remote Access Service in the Microsoft Windows 2000 Server Resource Kit Deployment Planning Guide.

TIP


To configure specific dial-out hours, make sure the schedule configured for the demand-dial interface in the Routing and Remote Access Service utility matches the configuration of the messaging connector as specified in the Delivery Options or Schedule tab.



MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 186

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