Creating and Configuring Routing Groups
A routing group is a collection of Exchange servers that have full-time, full-mesh, reliable connections between each and every server. Messages sent between any two servers within a routing group are delivered directly from the source server to the destination server. The message transport mechanism for this delivery is SMTP. Using SMTP as the native protocol provides several advantages. SMTP allows for a more flexible routing and administrative scheme because SMTP is more tolerant of low-bandwidth and high-latency topologies.
Ideally, you would be in a networking environment in which all servers were well connected. Of course, this is not always the case. For this reason, Exchange Server 2003 lets you define routing groups that collect well-connected servers into different groups and then connect those groups using several different kinds of connectors.
| Note |
|
Routing groups in Exchange Server 2003 should be planned similarly to sites in Exchange 5.5—according to available bandwidth and reliability of the connection. However, because Exchange Server 2003 uses SMTP, it is more tolerant of lower bandwidths and higher latency. This means you’ll be able to group servers into the same routing group that may not have been possible with an Exchange 5.5 site.
The most important factor to consider when defining routing group boundaries is the stability of the network connection rather than the actual bandwidth of the connection. If the connection is prone to failure or is often too saturated with network traffic to be useful, then you should divide your servers into separate routing groups.
| Note |
|
In order for servers to exist in the same routing group, they must meet the following criteria:
- All servers running Exchange Server 2003 must have reliable, permanent, and direct network connectivity between them that supports SMTP.
- All servers must belong to the same Active Directory forest.
- All servers must be able to connect to the routing group master. The routing group master maintains data about all of the servers running Exchange Server 2003 in the routing group.
If your servers do not meet these criteria, or if you have a need to maintain greater control over the way messaging information flows on your network, you will need to create multiple routing groups.
Creating Routing Groups
You will need to create separate routing groups if you have any servers that are separated by slow or unreliable links. Creating a routing group is a very similar process to the one for creating an administrative group. Exercise 8.3 outlines the steps for creating a new routing group.
EXERCISE 8.3: Creating a New Routing Group - Click Start > Programs > Microsoft Exchange, and then select System Manager.
- Expand the organization object in which you want to create a new routing group.
- Expand the Administrative Groups folder.
- Expand the administrative group in which you want to create a new routing group. If this administrative group does not already have a Routing Groups container in which to create a routing group, you will have to create one using the procedure discussed previously in this chapter.
- Right-click the Routing Groups container and select the New Routing Group command from the context menu. This opens the property pages for the new routing group, as seen below.
The new routing group will hold two subcontainers, as shown in Figure 8.4. The Connectors container holds any connectors that you create to connect this routing group to other routing groups or to foreign messaging systems. These connectors are covered later in this chapter. The second object is a Members container, which holds the servers that are part of the routing group. Both of these containers are empty right after you create the new routing group. - On the General page, enter a name for the new routing group that describes it.
- Optionally, you can switch to the Details page and enter some text that describes the purpose of the new group.
- Click OK to return to System Manager. The new routing group is displayed in the Routing Groups container.
Adding Servers to a Routing Group
Once a routing group is connected, there are two primary tasks you will need to take on to configure the new group. The first is moving or installing servers into the new group. The second, which is discussed a bit later in the chapter, is connecting the routing group to other routing groups.
There are two ways to make a server a member of a routing group. The first way is to drag a server from the Members container of an existing routing group and drop it into the Members container of the new routing group. It really is just that simple.
| Note |
|
In most small organizations, you will never have any reason to consider using more than one routing group. In these instances, it is fair to say that all of your Exchange servers will be located close to one another and have reliable, high-speed connectivity among them. But what will you do if your network happens to span multiple cities, states, countries, or even continents? Then you have a valid reason to start creating and using multiple routing groups.
A certain network, for example, has approximately 180 geographically distant sites within it that are located all over the globe. Of these approximately 180 remote sites, about 120 of them are located in the continental United States. The other 60 or so remote sites are located all over the globe in Germany, Korea, Japan, Italy, and several other countries. This network is split into five geographic regions based on network connectivity. Within each region, it can be reasonably said that reliable, high-speed IP connectivity exists between each and every host on the network. Between regions, often-unreliable WAN links exist, using a variety of technologies depending on where in the world they are located. Leased lines exist that are used to cross ocean expanses, with variable bandwidth available depending on the time of day.
In this network, it would be a good idea to create five different routing groups and place the servers from each of the five geographic regions into their respective routing groups. Within each routing group, several bridgehead servers could be configured from those that are available. In general, the bridgehead servers would usually be those that are located closest to the WAN Demarc point or points (the physical location in a network where external connections are made, such as to the Internet) for that region. If you’re using Routing Group Connectors between these routing groups, you can assign different route costs to those bridgehead servers that are closest to a backup WAN link.
Even though this network is large and distributed, you can still conceivably use just one administrative group for the entire network if desired. When Exchange Server 2003 operates in native mode, you can organize your routing groups and administrative groups independently of one another.
The second way to get a server into a routing group is to put it there during Exchange installation. If your organization contains more than one routing group, the Exchange setup program will ask you into which routing group (and which administrative group, if applicable) you want to install the new server. After setup is finished, the new server is added to the chosen routing group. For more information on installing Exchange Server, see Chapter 3, “Installing Microsoft Exchange Server 2003.”
Connecting Routing Groups
Once you have created multiple routing groups, you will need to connect them so that they can exchange messaging information. There are three types of connectors that you can create:
- The Routing Group Connector (RGC) is the main connector used to connect routing groups and is the simplest to configure. It used SMTP as its default transport mechanism, but it may also use a Remote Procedure Call (RPC) if the situation requires it.
- The SMTP Connector takes a bit more work to set up than the RGC and sports some different features. It is used mainly to connect routing groups where you want to force SMTP to be used for the transport mechanism. The SMTP Connector can also be used to connect an Exchange organization to a foreign messaging system using SMTP.
- The X.400 Connector can be used to connect routing groups and to connect to a foreign system. When used for connecting routing groups, its primary advantage is that it can be used over extremely low bandwidth and fairly unreliable connections.
The creation and configuration of each of these connectors are covered in the following sections.
In most cases, your best choice will be the Routing Group Connector because it is the simplest to configure and manage. However, your choice will depend on the purpose the connector will serve. In addition, multiple connectors, of differing types, can be created between the same two routing groups to provide a level of fault tolerance and load balancing.
Routing Group Connector
The RGC is the preferred method of connecting two routing groups in the same organization because it is fast, reliable, and the simplest to configure (has the fewest settings). SMTP is the native protocol used by the RGC, and the connector consults Exchange Server 2003’s link-state table for routing information.
The RGC is a one-way connection from one server to another. Therefore, when you configure a connector in one routing group, you’ll also need to create a connector in the other routing group to form a two-way connection. Fortunately, System Manager will automatically configure the other end of the link for you if you want it to.
A bridgehead server is one that is designated for passing messages from one routing group to another. The RGC offers a level of fault tolerance by allowing multiple source and destination bridgehead servers. Bridgehead servers can be used in one of three ways:
- No bridgehead server is designated, and all of the servers in the routing group function as bridgehead servers for message transmission.
- One bridgehead server is designated, and all mail destined for other routing groups flows through that one server. This gives the administrator great control over messaging configuration.
- Multiple bridgehead servers are used, and all mail flows over one of these designated servers. This configuration offers the advantages of load balancing and fault tolerance. Should one bridgehead server be unavailable for message transport, another will be available.
EXERCISE 8.4: Creating a New Routing Group Connector - Click Start > Programs > Microsoft Exchange, and then select System Manager.
- Expand the organization object, the Administrative Groups folder, the specific administrative group, and the Routing Groups folder in which you want to configure the connector.
- Right-click the Connectors container and select the New Routing Group Connector command from the context menu.
- This opens the property pages that you must configure for the new connector. Once you have configured these pages, which are described in the next section, System Manager offers to automatically create a connector for the other end of the link using the same properties you have just configured.
RGCs offer administrators the ability to control connection schedules, message priority, and message size limits.
Creating a Routing Group Connector
Creating a new RGC is a simple procedure. Exercise 8.4 outlines the steps involved.
Configuring Routing Group Connector Properties
The RGC holds a number of property pages that can be configured. You have the option of configuring these pages when you first create the connector or later by opening the pages for the connector object, which is placed in the Connectors container for the particular routing group. All of these, and the parameters they hold, are covered in the next several sections.
GENERAL PROPERTIES
The General page, shown in Figure 8.5, lets you enter several settings regarding the connector. These include the following:
- The name of the connector can be entered only when you are creating the connector. This field is not editable after the connector is created.
- The Connects This Routing Group With drop-down box lists the routing group with which you want to connect. All routing groups in the organization should be listed here.
- The Cost field indicates the cost value of using the connector relative to any other connectors that may connect the two routing groups. This value can range from 1 to 100, and lower cost links are always preferred over higher cost links. This provides you with a way of assigning preference when there are multiple connectors configured between routing groups. For example, you might want to configure two connectors to share the main messaging load between two sites and assign both of them a cost of 1. Then you might configure a backup connector with a cost of 5 that is used when the two main connectors are unavailable. As a general rule, the lower the bandwidth or reliability of the connection, the higher the cost value associated with the connector should be.
Figure 8.5: Remote Bridgehead properties of an RGC
While the option labeled Any Local Server Can Send Mail Over This Connector is enabled (which it is by default), all servers in the local routing group function as bridgehead servers and can route messages over the connector. You can specify that only particular servers be used as bridgehead servers by selecting the These Servers Can Send Mail Over This Connector option and then using the Add button to add servers to the list.
The Do Not Allow Public Folder Referrals option specifies that clients may not access public folder content using this connector. When a client tries to access public folder content that does not exist on a server in that client’s own routing group, it must try to find the content in other routing groups. This option gives you a way to govern the connections that can be used for this task.
REMOTE BRIDGEHEAD PROPERTIES
The Remote Bridgehead page, shown in Figure 8.6, allows you to specify one or more servers in the remote routing group as the bridgehead server(s) with which this connector will attempt to establish connections before sending messages. The servers are contacted in order, starting at the top of the list. Also, if the destination server has more than one SMTP virtual server configured, you’ll need to select the appropriate virtual server that will allow messages to be sent across the connector you are setting up.
DELIVERY RESTRICTIONS PROPERTIES
The Delivery Restrictions page, shown in Figure 8.7, lets you specify who can use this connector, either by specifying that all messages are rejected except for specified users or that all messages are accepted except for specified users. You can add mailbox-enabled or mail-enabled users and contacts to this list, but you cannot add groups.
CONTENT RESTRICTIONS PROPERTIES
The Content Restrictions page, shown in Figure 8.8, lets you configure several parameters:
- The Allowed Priorities section lets you select what priority messages are allowed over the connection. This is a great way to establish connectors dedicated, for example, to passing high-priority messages.
- The Allowed Types section lets you specify whether system messages and non-system messages are allowed over the connector. System messages would include any non–user-generated message, including directory replication, public folder replication, network monitoring, and delivery and non-delivery report messages.
- The Allowed Sizes section lets you restrict the size of messages that can be sent over the connector.
DELIVERY OPTIONS PROPERTIES
The Delivery Options page, shown in Figure 8.9, lets you specify when messages can flow through the connector. This is especially helpful if the connector uses a slow or unreliable WAN link. Click the Customize button to set up a schedule using a simple calendar interface. By selecting the Use Different Delivery Times For Oversize Messages option, you can channel larger messages to transfer at the times you configure, presumably when the connector would be experiencing little traffic.
SMTP Connector
Although the RGC uses SMTP as its native transport mechanism, Exchange Server 2003 also provides an SMTP Connector that can be used to link routing groups. There are three reasons why you might want to use an SMTP Connector instead of an RGC:
- The SMTP Connector is more configurable than the RGC and offers a greater ability to fine-tune the connection. The SMTP Connector also offers the ability to issue authentication before sending mail, specifying TLS encryption, and removing mail from queues on remote servers.
- The SMTP Connector always has to use SMTP. When you are connecting an Exchange 2000 Server with an Exchange 5.5 server, the RGC uses Remote Procedure Calls (RPCs) to communicate because it has no way of knowing whether the Exchange 5.5 server is configured to use SMTP, which was provided through the Internet Mail Service in previous versions of Exchange. There is no way to force the RGC to use SMTP, so an SMTP Connector can be used instead.
- The SMTP Connector is also capable of connecting independent Exchange forests within an organization so that messages can be transferred.
Another advantage of the SMTP Connector is that it can be used to connect an Exchange organization to the Internet or to a foreign (non-Exchange) messaging system that uses SMTP.
When connected to the Internet, the SMTP Connector uses a smart host or mail exchange (MX) records in DNS for next-hop routing. When configured internally between two routing groups, this connector will relay link-state information between routing groups but will still depend on the MX records in DNS for next-hop information.
Creating an SMTP Connector
Creating a new SMTP Connector is a simple procedure. Exercise 8.5 outlines the steps involved.
Configuring SMTP Connector Properties
The SMTP Connector holds a number of property pages that can be configured. You have the option of configuring these pages when you first create the connector or later by opening the pages for the connector object, which is placed in the Connectors container for the particular routing group. Two of these property pages, Content Restrictions and Delivery Restrictions, are identical to the RGC property pages of the same name. The rest are discussed in the following sections.
GENERAL PROPERTIES
The General page, shown in Figure 8.10, lets you configure the following options:
- The name of the connector can be entered only when you are creating the connector. This field is not editable after the connector is created.
- The Use DNS To Route To Each Address Space On This Connector option makes the connector work with DNS to make direct connections to the destination SMTP server based on MX records. To forward mail upstream to another SMTP server instead, select the Forward All Mail Through This Connector To The Following Smart Hosts option. For this option, enter either the Fully Qualified Domain Name (FQDN) or IP address of the server.
- The Local Bridgeheads area allows you to configure the servers that are to act as the local bridgehead servers for this connector.
- The Do Not Allow Public Folder Referrals option works the same way as the option for the RGC, and it is covered in that section.
EXERCISE 8.5: Creating a New SMTP Connector - Click Start > Programs > Microsoft Exchange, and then select System Manager.
- Expand the organization object, the Administrative Groups folder, the specific administrative group, and the Routing Groups folder in which you want to configure the connector.
- Right-click the Connectors container and select the New SMTP Connector command from the context menu.
- This opens the property pages that you must configure for the new connector. After you have configured these pages, which are described in the next section, System Manager does not offer to automatically create a connector for the other end of the link. You must do this manually.
DELIVERY OPTIONS PROPERTIES
The Delivery Options page, shown in Figure 8.11, lets you specify when messages can flow through the connector. For the most part, this page works the same as the Delivery Options page for the RGC, except that one feature has been added. The Queue Mail For Remote Triggered Delivery option allows clients to periodically connect to the Exchange Server 2003 computer and download messages using a special command. You can select which Active Directory user accounts can download mail.
ADVANCED PROPERTIES
The Advanced page, shown in Figure 8.12, has a number of important configuration points. These include the following:
- Normally, an SMTP client connects to an SMTP server using a command named HELO, which signals the start of a session between two SMTP servers and identifies the sender of the coming message. By default, Exchange Server 2003 sends the EHLO command, another start command, which indicates that the Exchange Server 2003 computer can use the Extended SMTP (ESMTP) commands. Not all SMTP servers are capable of dialogue using the extended commands, but you really have to worry about this only when connecting to non-Exchange servers.
- The Outbound Security button can be used to provide authentication credentials to the remote domain.
- The Do Not Send ETRN/TURN option prevents this connector from processing requests for remote servers to process mail sitting in their queues. This is selected by default.
- The Request ETRN/TURN When Sending Messages option is used to request that the server deliver queued mail to the client via a new ESMTP connection at certain times. Do this by selecting the Additionally Request Mail At Specified Times option and then scheduling the dequeuing time using the Connection Time drop-down list.
Figure 8.12: Advanced properties of the SMTP Connector
Use the Request ETRN/TURN From Different Server option and type the server’s name to request dequeuing from a server other than the one to which the message was sent.
To specify either the ETRN or the TURN command for dequeuing, select either the Issue ETRN or Issue TURN option. The ETRN command can be issued on a per-domain basis by clicking the Domains button and adding the domain names.
ADDRESS SPACE PROPERTIES
Whenever a message is sent that is not addressed to a recipient on the same server, that message is handed off for delivery to a remote server. To decide how to route that message to its destination, the routing engine uses an address space. An address space is the addressing information associated with a connector. Typically, an address space is a subset of a complete address. The Address Space property page, seen in Figure 8.13, lets you configure the default address spaces used for different types of messages, including SMTP, X.400, and many others. For the most part, this page is used when you are configuring the SMTP Connector to be used with a foreign system. This aspect is covered in detail in Chapter 13, “Connecting with Other Messaging Systems.” The Connected Routing Groups page is used instead when you are connecting two routing groups together.
CONNECTED ROUTING GROUPS PROPERTIES
If you do not configure an address space on the Address Space tab, you must configure which routing groups are connected to the local routing group using the Connected Routing Groups page (shown in Figure 8.14). This is a much better (and easier) way of handling routing between routing groups than using the Address Space page. The purpose of specifying connected routing groups is to inform the connector which routing groups are adjacent to it in order to enable internal routing of messages.
X.400 Connector
The X.400 Connector can be used to link Exchange routing groups and also to link an Exchange organization to a foreign, X.400-based messaging system. X.400 Connectors are useful for linking routing groups when there is very little bandwidth (less than 16 KB) available between servers or when X.400 is the only connectivity available. When linking routing groups with the X.400 Connector, you must designate a single server in each group as the bridgehead server. You must set up multiple X.400 Connectors between multiple servers in each routing group to gain a load-balancing feature.
Each end of an X.400 connection must be configured with the name of one remote Message Transfer Agent (MTA) to which it will connect. The local MTA name is assigned when an MTA Transport Stack is installed.
| Note |
|
Creating a Service Transport Stack
Creating an X.400 Connector to link routing groups is not too difficult. The one thing you must remember is that each end of an X.400 Connector must be configured separately and, unlike with the RGC, System Manager does not offer to do this for you automatically. To configure the X.400 Connector in Exchange Server 2003, you first must create an MTA Service Transport Stack. This transport stack is configured on a particular Exchange server and is basically a set of information about the software and hardware making up the underlying network. The use of the transport stack allows for a layer of abstraction between the X.400 Connector and the network itself.
| Note |
|
Exchange supports two different types of MTA Transport Stacks, each defined by the type of network hardware or software you have configured. The two types are as follows:
TCP/IP This type defines specifications for running OSI software, such as X.400 messaging systems, over a TCP/IP-based network. Microsoft Exchange Server 2003 uses Windows Server 2003 TCP/IP services.
TP0/X.25 This type uses an Eicon port adapter to provide both dial-up and direct communication in compliance with the OSI X.25 recommendation.
No matter which type of MTA Transport Stack you use, the configuration is nearly identical. Because it is easily the most-commonly installed, we cover the creation of a TCP/IP MTA Transport Stack in this chapter. Exercise 8.6 outlines the steps for creating a TCP/IP MTA Transport Stack.
Once the stack is created, you will manage it using two property pages: General and Connectors.
GENERAL PROPERTIES
The General property page, seen in Figure 8.15, is used to change the display name for the TCP Transport Stack and to configure OSI addressing information. Unless you plan to allow other applications besides Exchange Server 2003 to use the MTA Transport Stack, you do not need to worry about the OSI addressing values.
EXERCISE 8.6: Creating a TCP/IP MTA Transport Stack - Click Start > Programs > Microsoft Exchange, and then select System Manager.
- Expand the organization object in which you want to create a new administrative group.
- Expand the Administrative Groups folder, the administrative group, and then the server on which you want to create the stack.
- Expand the Protocols container, right-click the X.400 Container, and choose New TCP/IP X.400 Service Transport Stack from the context menu.
- Use the property pages to configure the new transport stack.
CONNECTORS PROPERTIES
The Connectors property page, shown in Figure 8.16, lists all of the messaging connectors in the routing group that are configured to use the current MTA Transport Stack. When you first create a stack, this list is blank. As new connectors are created that use the MTA Transport Stack, the connectors will be added to the list.
Creating an X.400 Connector
After you create an MTA Transport Stack, you must create the X.400 Connector itself. Exercise 8.7 outlines the steps involved.
EXERCISE 8.7: Creating a TCP/IP X.400 Connector - Click Start > Programs > Microsoft Exchange, and then select System Manager.
- Expand the organization object, the Administrative Groups Folder, the specific administrative group, and the routing group for which you want to create the connector.
- Right-click the Connectors container and choose the New TCP X.400 Connector command from the context menu.
- This opens the property pages that you must configure for the new connector. After you have configured these pages, which are described in the next section, System Manager does not offer to automatically create a connector for the other end of the link. You must do this manually.
Configuring X.400 Connector Properties
Many of the property pages that you see for the X.400 Connector are used only when you are connecting your Exchange organization to a foreign X.400 messaging system, and they do not pertain to connecting two routing groups to one another. This section examines only the property pages and parameters that are relevant to connecting routing groups. Also, the Delivery Restrictions and Content Restrictions pages are identical to the pages of the same names for the Routing Group Connector.
GENERAL PROPERTIES
For the most part, the General property page, shown in Figure 8.17, does not hold any parameters that are useful when connecting routing groups. The exceptions are the following:
- You can enter the name of the connector only when you are creating the connector. This field is not editable after the connector is created.
- The X.400 Transport Stack setting lets you change the MTA Transport Stack that the X.400 Connector is currently configured to use. You can change the MTA Transport Stack at any time.
- The Do Not Allow Public Folder Referrals option works the same way as for the Routing Group Connector and the SMTP Connector.
Figure 8.17: The General properties of the X.400 TCP connector
SCHEDULE PROPERTIES
The Schedule property page, shown in Figure 8.18, lets you restrict the times at which the X.400 Connector can be used. By default, the X.400 Connector can be used always and, for the most part, you will want to leave this value alone. There are times, however, when you may wish to limit connectivity, such as on a very busy network, or when you need to bring a network down for maintenance.
You can set an X.400 Connector schedule to one of four values:
- The Never option disables the connector altogether. It is useful for bringing down the connector while performing maintenance.
- The Always option allows connections to be made to and from the server at any time.
- The Selected Times option defines specific times at which the X.400 Connector is available. This can be useful on a busy network. If immediate messaging is not a concern, you can schedule messages to be sent only at specific periods during the day, when network traffic is otherwise low.
- The Remote Initiated setting allows remote servers to connect to the current server but does not allow the local server to initiate a connection.
STACK PROPERTIES
The Stack property page, shown in Figure 8.19, is used to specify transport address information about the server in the other routing group. If you input an IP address instead of a host name, be sure to enclose it in brackets, such as [192.168.2.200].
CONNECTED ROUTING GROUPS PROPERTIES
Just as with the SMTP Connector, the purpose of specifying connected routing groups is to inform the connector which routing groups are adjacent to it in order to enable internal routing of messages. If you were not connecting routing groups, you would use the Address Space page to configure actual address spaces.
Summary
In previous versions of Exchange Server, the concept of a site was used to define both the physical routing boundaries of a group of well-connected servers and the administrative boundaries within an organization. In Exchange Server 2003, sites have been replaced by administrative groups, which are objects logically grouped together for permissions management, and routing groups, which are physical groupings of Exchange servers used to define routing boundaries.
The use of both types of groups depends on whether your organization is running in mixed mode or native mode. Mixed mode allows Exchange Server 2003 servers and servers running earlier versions of Exchange to coexist in the same organization. It allows this interoperability between versions by limiting functionality to features that both products share.
Microsoft defines three basic administrative models: centralized, decentralized, and mixed.
- In the centralized model, one administrator or group of administrators maintains complete control over an entire Exchange organization. This can be done with one administrative group or a few administrative groups created to make certain functions earlier.
- The decentralized model is typically used to define administrative boundaries along real geographical or departmental boundaries. Each location would have its own administrators and its own administrative group.
- The mixed model is really a catchall model for any other ways you can think of to use administrative groups. It is useful for when you do not necessarily want the tight control of the centralized model and the strict geographic division of the decentralized model is not appropriate.
By default, Exchange Server 2003 is configured with a single administrative group that is named First Administrative Group. You can add new administrative groups, name them what you want, and then create Public Folder, Routing Group, and Policy containers inside the new group. Once these are created, you can move resources from other groups into the new group.
A routing group is a collection of Exchange servers that have full-time, full-mesh, reliable connections between each and every server. Exchange servers in the same routing group must also belong to the same Active Directory forest.
You create routing groups in System Manager in much the same way as you create administrative groups. When created, they are simple containers waiting for you to fill them with servers.
Once your routing groups are defined, you must connect them together using one or more of three types of connectors. The Routing Group Connector (RGC) is the main connector used to connect routing groups and is the simplest to configure. It uses SMTP as its default transport mechanism but may also use a Remote Procedure Call (RPC) if the situation requires it. The SMTP Connector is a bit more involved to set up than the RGC and sports some different features. It is mainly used to connect routing groups where you want to force SMTP to be used for the transport mechanism. The X.400 Connector can be used to connect routing groups and to connect to a foreign system.
0 comments
Post a Comment