Creating a new RGC is very straightforward
and the two major screens you need to complete are shown in Figure 25 and
Figure 26. Before starting, you need to know:
The
server to act as the local bridgehead
The
servers to act as the bridgehead in the Routing Group that you wish to connect
to. You can specify more than one bridgehead, if you wish to spread the
messaging load across multiple servers.
The
cost that will be allocated to the connection.
The
name of the connector. Names can be up to 64 characters long.
The default cost for connections is 1.
Best practice suggests that you should set a default cost of 10 for all major
connectors and use steps of at least 10 for minor connectors. Because the
notion of “major” and “minor” links vary greatly from company to company and
depend on network connectivity and the way that Routing Groups are created, it
is very difficult to offer hard and fast definitions. For most purposes, a
major connector can be defined as a link that you expect a lot of traffic to
pass along. For instance, a link between a Routing Group and a Hub Routing
Group in a hub and spoke network falls into this category. Minor connections
are defined as links that carry less traffic. A connection that serves a
downstream Routing Group (one that is not connected directly into a Hub Routing
Group) falls into this category. If you look at the organization illustrated in
Figure 21, the major connection is between London and New York, and has a cost
of 10. The links between the Routing Groups off the two hubs all have a cost of
20.
After the RGC is created, you will be
asked whether you wish to create the corresponding RGC in the target Routing
Group. This is functionally equivalent to way that Site connectors are created
in Exchange 5.5, where if you have the necessary permissions in the Windows NT
domain that hosts the remote site, you can create connectors in both sites in a
single operation.
The Content Restrictions, Delivery
Restrictions, and Delivery Options property pages allow you to exert additional
control over messages that flow across the link. Content restrictions determine
what priority of messages can be transmitted — High, Normal, or Low. Delivery
restrictions allow administrators to create lists of users who are either
permitted or barred from using the link. The combination of Content and
Delivery restrictions is enough to create a scenario where a link is only able
to handle high-priority messages from a select group of users. In most cases,
administrators will not want to create such a restrictive environment, but many
will be interested in the Delivery options.
Everyone wants their messages to go as
quickly as possible, but sometimes people send messages that you really wish
were left until after office hours. Most of the time, these messages are very
large. Delivery options allow you to determine when the connector is available
and set a different schedule for messages that exceed a certain size. Figure 27
shows that the connector is always available (the default) and that a separate
schedule governs when messages over 2MB (2,000KB) can be transmitted. Given the
size of many PowerPoint presentations sent around major corporations today, 2MB
may be too small a limit, but it serves to illustrate the point. Any messages
that exceed the limit are kept on the queue for the connector until the
schedule allows them to be sent.
Connectors are one-way, so it’s important
to remember that any change you make to a RGC only applies in the Routing Group
that the connector belongs to. If you impose a restriction on who can use the
connector or the size of messages that can be processed and only make the
change on one side of the link, then it is quite possible to end up in a
situation where users can send large messages from one side to the other, but
not the other way round. The best way to avoid potential problems is to ensure
that the same configuration is maintained for the RGC from both sides of the
link.
After the RGC is configured on both sides,
you should be able to see both connectors in their respective Routing Groups
(Figure 28).
CREATING A SMTP CONNECTOR
The RGC
uses SMTP, so why is there a separate SMTP connector? The answer is simple –
there’s a big bad SMTP world out there where Exchange 2000 is a very small
presence right now. People want to communicate with other SMTP domains, and
they’d like to do so in as functional a manner as possible. Also, RGCs can only
connect to other routing groups and cannot send e-mail to an SMTP server that’s
outside the Exchange organization, so another connector is required to link
Exchange to the wider SMTP world.
Like the RGC, the SMTP connector runs
under the context of a SMTP virtual server. The RGC uses the Exchange
configuration data held in the AD to route messages, but the SMTP connector is
designed to use standard SMTP routing techniques such as the MX (Mail
Exchanger) records held in DNS. You should therefore use a SMTP connector
whenever you want to route messages to a “smarthost” system, use MX records as
the basis for routing, or generally to send messages outside Exchange
(including to the IMS running on older Exchange servers).
Figure 29 shows a good example of a SMTP
connector in action. The connector is configured to send any message to
“smarthost.compaq.com.” Smart hosts are mail servers that often act as central
collection and dispatch points for SMTP mail for an enterprise. Either a fully
qualified domain name (as in this case) or a specific IP address can be
specified for the smart host. If you use an IP address, remember to enclose it
in square brackets. For example, [16.18.19.20]
Bringing messages together to a central point
before they are sent outside a company allows for centralized checking for
viruses or profanity or verification that users are complying with company
standards such as disclaimer text on messages or even that classified
information isn’t been sent to external correspondents. MimeSweeper
(www.mimesweeper.com) is a popular example of software that runs on smart
hosts.
Setting up the connector to route all mail
to a smart host is one step towards control. You can achieve finer control
through the address space property page. Here we define the SMTP domains that
can be reached through the connector. The default is “*”, meaning that all
domains can be reached, but in some cases you might want just messages for a
specific domain to be handled in a certain manner. Figure 30 shows how the
address space is configured for a specific domain, in this instance compaq.com.
With this configuration, the connector is only able to handle messages
addressed to a recipient in compaq.com, and all other messages will have to
find another route.
At the bottom of Figure 30 you can see how
Exchange 2000 controls the scope of a connector. This feature was introduced in
Exchange 5.5 and restricts the availability of a connector to other servers. In
Exchange 5.5, you can restrict a connector to servers at a location, site, or
the organization. In Exchange 2000, the restriction is either to the routing
group or organization. In our example, the connector is only available to the
servers in the local routing group. Setting a scope on a SMTP connector is most
useful when several connectors exist in an organization, each of which has very
different capacities, possibly because of varying costs of Internet connections
via ISPs from country to country. For example, let’s assume that you have two
SMTP connectors created in routing groups in Paris and New York. ISP charges
are typically cheaper in North America, so if the New York connector ever goes
down, you may not want to reroute messages across the Atlantic to Paris as this
would drive up the use of the ISP connection there and might result in heavier
fees. In this case, you could set the scope for the SMTP connector in Paris at
the level of the routing group. Controlling scope has been built into Exchange
for a reason, so it’s a good idea to consider this option for every SMTP
connector that is created.
The Exchange IMS was constantly tweaked
from 4.0 through 5.5 and in many service packs. In fact, the IMS was possibly
the component that changed most dramatically in terms of scope and
functionality in the first generation of Exchange. Obviously, the impact of the
Internet grew at an ever-increasing pace during the 1996-1999 period, so the
fact that Microsoft made so many changes isn’t at all surprising.
The Exchange 2000 SMTP connector has many
advanced properties that can be manipulated, many of which don’t have to be
touched if you simply want to connect together routing groups, or link Exchange
to the Internet across a permanent connection. Companies that depend on ISPs to
provide a message drop service will be happy to find that the SMTP connector
supports all the features required to make a connection to an ISP and pick up
messages using the SMTP ETRN or TURN commands (Figure 31). Creating a
connection between Exchange and an ISP can be a specialized business that
requires much more discussion than can be afforded in a book like this, so
those interested in the topic are best advised to go to a specialized web site
such as that at www.swinc.com.
Encrypted
SMTP Communications
SMTP
messages are sent in plain text, so unless the actual content is encrypted using
Exchange advanced security or some other secure scheme, the possibility exists
that the data could be intercepted and examined by someone that you’d rather
not. The Exchange 5.5 Site connector uses encrypted RPCs, so obviously security
is somewhat downgraded when you switch site connectors over to RGCs or SMTP
connectors.
The solution is to establish a secure
connection for SMTP traffic to flow across. The preferred and recommended
solution is to do this with IPSEC, although it is also possible to create an
encrypted connection with TLS. However, IPSEC incurs far less overhead than a
TLS connection and is an inbuilt feature of Windows 2000, so it should be used
whenever possible. An IPSEC connection secures all IP traffic across the link,
which is another advantage gained by selecting this approach.
CREATING A X.400 CONNECTOR
With
all the focus on SMTP, you’d be forgiven if you assumed that an Exchange
administrator would never have to create an X.400 connector again. This may
well be the case in many companies, especially those in the US, where SMTP
links have always been more popular. The largest constituency for X.400
connectivity will be companies that operate X.400-based backbones that
integrate many different messaging systems.
The X.400 connector was regarded as
“complex” in previous versions of Exchange. This is an unfair label, and
largely came about due to the fact that the X.400 connector had more property
pages than either the Site or SMTP connectors. The real truth is that the
majority of the pages could safely be ignored if you wanted to set up a
connection between Exchange sites or organizations, or link to an X.400
backbone (including the X.400 service offered by large service providers such
as AT&T). The X.400 connector offers more opportunity to tune the way that
connections are established and operated, but that’s no reason to consider it
to be complex.
To illustrate how easy it is to create an
X.400 connector, let’s look at the steps required to set up an X.400 connector
to link Exchange 2000 to an Exchange 5.5 organization. While SMTP is the
easiest way to link Exchange 2000 to Exchange 5.5, it may be the case that you
want to operate a scheduled connection (on both sides), and X.400 is able to
offer this facility.
Figure 32 illustrates the general
properties of the X.400 connector. The important items here are:
The
name of the remote MTA: This is usually the name of the remote bridgehead
server that you want to connect to. Unlike the RGC or SMTP connectors, you can
only define a single bridgehead server for each side of an X.400 connection.
However, you can install multiple X.400 connections within a Routing Group to
provide fault tolerance if the server that hosts the primary connection fails.
A
password for the remote MTA: This is usually blank, unless you wish to secure
the connection by forcing each MTA to authenticate itself to its partner by
exchanging passwords each time a connection is attempted. Note that the
password is sent in plain text.
Message
text word-wrap: As this connection is going to another Exchange organization,
it is safe to send messages without forcing lines to wrap at a set position.
Older X.400 systems (usually those that support the 1984 X.400 recommendations)
may insist that each line is wrapped at column 75 or 78, or another value.
Remote
clients support MAPI: Again, as the connection is going to an Exchange 5.5
organization, we can expect that any client that connects to the servers will
understand MAPI or the server will provide the client with a translated version
of the messages (as in the case of POP3, IMAP, or OWA).
Do
not allow public folder referrals: If the X.400 connector is used to link
Routing Groups together in the same Exchange 2000 organization (including a
mixed mode organization), then it is safe to allow public folder referrals to
flow across the connector. However, in this case we’re using the X.400
connector to link two different Exchange organizations, one of which is running
Exchange 5.5. You can’t share public folders between two different
organizations, so the check box is filled in.
The X.400 transport stack defines the
method used to establish the X.400 link and the server that will act as the
bridgehead. Most X.400 connections within the Exchange community flow across a
TCP/IP link, although we could equally an X.25 dial-up link. The details of how
X.400 works across a TCP/IP link can be found in RFC 2126, which defines how
OSI software can connect over IP (messages are routed through port 102). X.25
dial-up links are usually confined to situations where a telephone connection
is the only possible link. In these circumstances a dial-up SMTP connection,
either direct to a central hub or via a connection managed by an ISP, is now a
better option. SMTP supports authentication and encryption whereas X.400 only
supports basic authentication (MTA passwords) and, as we’ve seen, SMTP is the
way of the future, so it’s best to move if at all possible.
A suitable transport stack must be
configured on a server before it can support an X.400 connector. Figure 33
shows where the option to configure a new stack can be invoked. The properties
of the stack are very simple and merely require you to provide a name for the
new object plus values for the TSAP, SSAP, and PSAP used in OSI address
information. TSAP, SSAP, and PSAP stand for Transport, Session, and
Presentation access points and represent the different points within the OSI
model that are used by the X.400 connector. This is a real opportunity to make
things complex for you. You can keep things simple by specifying blank values,
which means that incoming MTAs can also specify blank values when they make a
connection, or you can complicate matters by playing around with different hex
and text values in each access point. Of course, you’re much more secure now
because you have created a situation where incoming MTAs absolutely must be
able to pass the required access point information before a connection is
established. This is sometimes required, especially when communicating with
X.400 backbones, but if you’re only ever going to communicate with other
Exchange servers you should use blank values. Over the years, there has been
more frustration and bad words spoken during attempts to make Exchange servers
talk to each other across X.400 connections where the MTAs have mismatching
access points than for any other reason. Life is too short to get involved in
such situations.
Figure 34 illustrates the properties
defined in the Stack page. Two major pieces of data are defined here. First,
you need to specify either the name of the host server you want to connect to
or its IP address. It is best practice to use the fully qualified domain name
of the host server as this allows the IP address to be changed if necessary.
Just to prove that best practices aren’t always followed, the IP address is
used here. This is safe to do if you are sure that the address is unlikely to
change. Using the IP address offers a major advantage in that connectivity can
still be established if DNS is unavailable to resolve the host name. However,
if DNS is unavailable your Windows 2000 infrastructure will be experiencing
some major problems of its own, and sending e-mail across an X.400 connector is
likely to be one of the lower priority items on an administrator’s to-do list.
The OSI address information can be entered
in hex or text format. Computers and some human beings understand hex well
enough to be able to accurately interpret data entered in hex, but I don’t and
can’t be bothered to work it out, so I take the easy option and go for text,
and then leave the values blank whenever possible. You can enter outgoing and
incoming OSI information for the TSAP, SSAP, and PSAP selectors. The outgoing
information will be sent to the remote MTA when the connection is established,
while the local MTA expects the remote MTA to provide the specified OSI data
when an incoming connection is initiated. If the information doesn’t match
expectations, the connection will be determined. Between Exchange servers there
is no real need to specify OSI selector information, so it’s best to leave
these fields blank. Connecting to other X.400 systems may require you to know
the OSI selectors the remote MTA will broadcast, so be sure to know this
information before you set up the connector.
All Exchange connectors specify an address
space. The address space determines how messages are routed to the connector.
In the case of the X.400 connector, we need to define what X.400 addresses can
be handled by the connector. The routing core will then send any message it
finds that matches the address space to the connector. Figure 35 shows two
screens. The left-hand screen lists all of the address spaces defined for the
connector while the right-hand screen shows how an address space is defined. In
this case, the definition means that any message with an X.400 address starting
with:
C=IE;A=;P=Compaq;O=Dublin
Will be
routed through the connector. Most users don’t know (and don’t want to) how to
generate X.400 addresses, but it is useful to know how so that you can send a
test message to an address on the other side of the connection to make sure
that everything works. Using a MAPI client, you can enter an X.400 address by
enclosing it in square brackets and prefixing the address with X400, as
follows:
Be careful with blank values. In the
example shown above, the A (administrative domain) part of the address is
blank, meaning that no value is passed at all. In some situations, a single
space character may represent a “blank”, and you might have to test several
variations of address formats before you determine the correct format.
Figure 36 shows the advanced properties of
our X.400 connector. These properties are easy to determine when you connect to
another Exchange server — just accept the default values. However, when you
connect to a foreign X.400 system, you’ll have to know what the other system
supports.
Allow
BP-15 means that the remote MTA supports bodypart-15, which means that
information about attachments are passed as file names instead of X.400 OIDs
(object identifiers). In other words, if you send a Word attachment, the
filename is transmitted in the message header with a value such as
“document1.doc” instead of a binary value. Most modern X.400 systems support
BP-15. Note that the responsibility for interpreting the file names and
processing the attachment with the correct application lies with the client,
not the MTA, so clients that attach to the receiving MTA must be able to
understand the filenames that Exchange will send.
Allow
Exchange contents means that the message will contain MAPI content (header
properties, message text, and attachments). If the clients attached to the
remote MTA understand MAPI, then you can check this box.
Two-way
alternate means that the two MTAs can send and receive messages alternatively.
Some older MTAs can only accept or send messages in a connection.
IA5
is the most common encoding scheme used for text bodyparts.
Older
X.400 systems may support the 1984 recommendations. However, these systems are
few and far between now, and you will normally find that the remote system
supports 1988 mode.
The values used to configure X.400
connectors in older versions of Exchange are exactly the same as those required
by Exchange 2000. If you already have X.400 connectors in use, they should
continue to function perfectly after you upgrade the servers to Exchange 2000.
Deciding
to use an X.400 Connection
The
X.400 connector is just one of the options that can be used for connectivity.
When do you choose to deploy this connector instead of another? Here are a few
valid reasons:
An
enterprise uses a well-established X.400 backbone to link diverse messaging
systems together. The temptation may exist to move to a SMTP backbone, but the
other messaging systems may not support the same level of rich SMTP extensions
as Exchange 2000. On the other hand, because X.400 has been in use since the
recommendations were first published in 1984, it’s probable that all of the
systems support a rich set of features as defined in the subsequent 1988 or
1992 X.400 recommendations. In this case, it’s best to operate on the basis
that you shouldn’t seek to fix something that isn’t broken and continue to use
the existing backbone. As new versions of the other messaging systems become
available that might support extended SMTP, you can test their interoperability
with Exchange and decide whether the time has arrived to move to a new
backbone.
Similarly,
you may want to connect to a public e-mail service that uses X.400. Most public
systems now offer SMTP, but there are a few (reducing all the time) that still
rely on X.400.
The
bandwidth available between Routing Groups is 16 K/bps or less. The Advanced
properties page for an X.400 connector allow you to tune how messages are
transmitted to achieve a finer degree of control than is possible with the SMTP
or RG connectors. Fine control becomes very important when bandwidth is low.
Finally,
no technical reason might exist, but X.400 may be the preferred protocol for
connections. This might come about because system administrators are more
familiar and comfortable with X.400 and still believe that SMTP is only for
simple messaging, or a decision taken some time ago to use X.400 is still in
place and has not been revised in the light of recent developments.
Despite the charge towards Internet
protocols, X.400 will be in use for some time yet. SMTP will eventually win in
the battle of the messaging protocols, but achieving final victory for the SMTP
camp will be a long drawn out affair.
Master SharePoint with 3 eLearning Seminars Learn how to build a better SharePoint infrastructure and enable powerful collaboration with MVPs Dan Holme and Michael Noel. Register today!
SharePointConnections Conference Fall 2008 Don’t miss the premier event for Microsoft IT Professionals in Las Vegas, November 10-13. Register and book your room by August 25 and receive a FREE room night (based on a three night minimum stay).
VMworld 2008 - Sign Up Today! Join your peers on September 15-18 at The Venetian Hotel in Las Vegas as VMware hosts VMworld 2008, the leading Virtualization event.
Microsoft® Tech•Ed EMEA 2008 IT Professionals Advance your thinking with new ideas and practical real-world solutions at Microsoft’s FIVE day technical infrastructure conference 3-7 Nov., 2008. Register before 26 September 2008 to save €300.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
Are You Really Compliant with Software Regulations? View this web seminar that will help you with compliance best practices and check out a management solution to assure that you won’t be in jeopardy of an audit.
Windows IT Pro
Register
