In
Active Directory, all client logons and lookups are directed to local
domain controllers and GC servers through references to the SRV records
in DNS. Each configuration has its DNS and resource requirements.
Exchange Server relies on other servers for client authentication and
uses DNS to find those servers. In an Active Directory domain controller
configuration, on the other hand, the Exchange server also participates
in the authentication process for Active Directory.
Using DNS in Exchange Server 2010
As has been
stated, Active Directory and DNS access are vital to an Exchange Server
implementation. It is critical that the host records for all Exchange
Server 2010 servers be properly registered and configured in the domain
name system (DNS) server for the Active Directory forest. Clients, as
well as other servers, will use DNS to locate and communicate with
Exchange Server 2010 servers.
Any
computer acting in one of the Exchange Server 2010 organizational
server roles must be domain members and registered in DNS. The five
server roles are as follows:
Edge Transport
Hub Transport
Mailbox
Client Access
Unified Messaging
All server roles,
with the exception of the Edge Transport, can be deployed on a single
server. Although there are five roles listed, only the Hub Transport,
Client Access, and Mailbox server roles are required for a minimal
Exchange Server 2010 installation.
Configuring Edge Transport Server DNS Settings
For the Edge
Transport server(s), which reside in the perimeter network, to
communicate with the Hub Transport servers in your Exchange Server
environment, they must be able to locate each other using host name
resolution. This is accomplished by creating host records in a forward
lookup zone on the internal DNS server that each server is configured to
query, or by editing the local Hosts file for each server.
Before installing the
Edge Transport server role, you have to configure a DNS suffix for the
server name. After you have installed the Edge Transport server role,
the server name cannot be changed.
To complete this task, you must log on to the Edge Transport server as a user who is a member of the local Administrators group.
To use Windows Control Panel to configure the DNS suffix, complete the following steps:
1. | Open Windows Control Panel.
|
2. | Double-click on System to open the System Properties dialog box.
|
3. | Click the Computer Name tab.
|
4. | Click Change.
|
5. | On the Computer Name Changes page, click More.
|
6. | In the Primary DNS Suffix of This Computer field, type a DNS domain name and suffix for the Edge Transport server.
|
DNS and SMTP RFC Standards
In 1984, the
first DNS architecture was designed. The result was released as RFC 882
and 883. These were superseded by RFC 1034 (Domain Names—concepts and
facilities) and 1035 (Domain Names—implementation and specification),
the current specifications of the DNS. RFCs 1034 and 1035 have been
improved by many other RFCs, which describe fixes for potential DNS
security problems, implementation problems, best practices, and
performance improvements to the current standard.
RFC 2821 defines the SMTP, which replaced the earlier versions of RFC 821 and 822.
Interoperability with Older Versions of Exchange Server
Exchange
Server 2010 can be deployed in an existing Exchange Server 2003 or
Exchange Server 2007 organization, as long as the organization is
operating in Native mode. This interoperability is supported; however,
there are many differences between the older systems and the newer,
especially in how the servers are administered and how server-to-server
communication occurs.
Understanding Mixed Exchange Server Environments
For Exchange
Server 2010 to communicate properly with Exchange Server 2003, the
routing group connectors between the Exchange Server 2010 Hub Transport
servers and the older bridgehead servers must be configured correctly.
When you install an Exchange Server 2010 server into an existing
organization, the server is recognized by the Exchange Server 2003
organization. However, because server-to-server communications differ
greatly, you must configure routing group connectors to let the
different versions communicate and transfer messages. This is because of
the fact that Exchange Server 2003 used SMTP as the primary
communication protocol between Exchange servers, but in Exchange Server
2010, the server roles use remote procedure calls (RPCs) for
server-to-server communication and allow the Hub Transport server to
manage the transport of SMTP traffic.
Exchange Server
2010 communicates directly from the Exchange Server 2010 Hub Transport
role to the Exchange Server 2007 Hub Transport role. However, the
Exchange 2007 servers must be at Exchange 2007 Service Pack 2.
Similarly, the Exchange Server 2010 Hub Transport role can interoperate
with the Exchange Server 2007 Edge Transport role.
Routing in Exchange Server 2010
Although Exchange
Server 2003 uses routing groups to define the Exchange Server routing
topology, Exchange Server 2010 uses Active Directory sites to do so, so
an Exchange-specific routing configuration is no longer needed in a pure
Exchange Server 2010 organization or in a mixed Exchange Server
2007/2010 organization.
For the two routing
topologies to coexist, all Exchange Server 2010 servers are
automatically added to a routing group when the server is installed.
This Exchange Server 2010 routing group is recognized in the Exchange
System Manager for Exchange Server 2003 as an Exchange Routing Group
within Exchange Administrative Group.
For Exchange Server 2010 to coexist with Exchange 2000 Server or Exchange Server 2003, you need to perform the following task:
Note
The first
routing group connector is created during installation of the first Hub
Transport server when installed in an existing Exchange Server
organization.
These connectors allow mail to be routed from Exchange Server 2003 to Exchange Server 2010.
SMTP Mail Security, Virus Checking, and Proxies
Spamming and security
issues are daily concerns for email administrators. As the Internet
grows, so too does the amount of spam that mail servers have to
confront. Unwanted messages not only can take up a lot of space on mail
servers, but can also carry dangerous payloads or viruses.
Administrators have to maintain a multilayered defense against spam and
viruses.
There are several security areas that have to be addressed:
Gateway security to control access to the mail server delivering messages to/from the Internet.
Mail database security where messages are stored.
Client mail security where messages are opened and processed.
Gateway security
is a primary concern for administrators because a misconfigured gateway
can become a gateway used by spammers to relay messages. Unauthenticated
message relay is the mechanism spammers rely on to deliver their
messages. When a server is used for unauthenticated message relay, it
not only puts a huge load on server resources, but also might get the
server placed on a spam list. Companies relying on spam lists to control
their incoming mail traffic refuse mail delivered from servers listed
in the database; therefore, controlling who can relay messages through
the mail relay gateway is a major concern.
Application-level
firewalls such as Microsoft Internet Security and Acceleration (ISA)
Server 2006 allow mail proxying on behalf of the internal mail server.
Essentially, mail hosts trying to connect to the local mail server have
to talk to the proxy gateway, which is responsible for relaying those
messages to the internal server. Going one step further, these proxy
gateways can also perform additional functions to check the message they
are relaying to the internal host or to control the payload passed
along to the internal server.
This
configuration is also helpful in stopping dangerous viruses from being
spread through email. For example, dangerous scripts could potentially
be attached to email, which could execute as soon as the user opens the
mail. A safe configuration allows only permitted attachment types to
pass through. Even those attachments have to pass virus checking before
they are passed to an internal mail server.
The following process describes how one server contacts another server to send email messages that include virus checking:
The sender contacts its SMTP gateway for message delivery.
The
SMTP gateway looks up the MX record for the recipient domain and
establishes communication with it. The application proxy acting as the
SMTP server for the recipient’s domain receives the message. Before the
recipient gateway establishes communication with the sender gateway, it
can check whether the sender SMTP gateway is listed
on any known spam lists. If the server is not located on any spam
lists, communication can resume and the message can be accepted by the
proxy server.
The application proxy forwards the message for virus checking.
After virus checking, the mail is routed back to the application proxy.
Mail is delivered to the internal SMTP gateway.
The recipient picks up the mail message.
Note
Application proxy and
virus or spam checking might be done within the same host. In that case,
steps 2–5 are done in one step without having to transfer a message to a
separate host.
Third-party products
can be used for virus checking not only at the gateway level, but also
directly on an Exchange Server email database. Database-level scans can
be scheduled to run at night when the load is lower on the server;
real-time scans can perform virus checking in real time before any
message is written to the database.
The final checkpoint for
any multilayered virus protection is on the workstation. The file system
and the email system can be protected by the same antivirus product.
Messages can be scanned before a user is able to open the message or
before a message is sent.
Protecting email
communications and message integrity puts a large load on
administrators. Threats are best dealt with using a multilayered
approach from the client to the server to the gateway. When each step
along the way is protected against malicious attacks, the global result
is a secure, well-balanced email system.
The Edge Transport Servers Role in Antivirus and Antispam Protection
In Exchange Server
2010, the introduction of the Edge Transport server role was brought
about by the increased need to protect organizations from unwanted
message traffic. The Edge Transport server is designed to provide
improved antivirus and antispam protection for the Exchange Server
environment. This server role also applies policies to messages in
transport between organizations. The Edge Transport server role is
deployed outside the Active Directory forest in the perimeter network
and can be deployed as a smarthost and SMTP relay server for an existing
Exchange Server 2010 organization.
Actually, you can add an
Edge Transport server to any existing Exchange Server environment
without making any other organizational changes or upgrading the
internal Exchange servers. There are no preparation steps needed in
Active Directory to install the Edge Transport server. If you are
currently using the antispam capabilities of the Intelligent Message
Filter in Exchange Server 2010, you can still use the Edge Transport
server as an additional layer of antispam protection.
SMTP Server Scalability and Load Balancing
In
a larger environment, administrators might set up more than one SMTP
server for inbound and/or outbound mail processing. Windows Server 2008
and Exchange Server 2010 provide a very flexible platform to scale and
balance the load of SMTP mail services. DNS and Network Load Balancing
(NLB) are key components for these tasks.
Administrators should
not forget about hardware failover and scalability. Multinetwork
interface cards are highly recommended. Two network cards can be teamed
together for higher throughput, can be used in failover configuration,
or can be load-balanced by using one network card for front-end
communication and another for back-end services, such as backup.
Network design
can also incorporate fault tolerance by creating redundant network
routes and by using technologies that can group devices together for the
purpose of load balancing and delivery failover. Load balancing is the
process where requests can be spread across multiple devices to keep
individual service load at an acceptable level.
Using NLB, Exchange
Server SMTP processes can be handed off to a group of servers for
processing, or incoming traffic can be handled by a group of servers
before it gets routed to an Exchange server. The following example
outlines a possible configuration for using NLB in conjunction with
Exchange Server.
DNS, in this example, has
been set up to point to the name of the NLB cluster IP address.
Externally, the DNS MX record points to a single mail relay gateway for companyabc.com.
Exchange server uses smarthost configuration to send all SMTP messages
to the NLB cluster. The NLB cluster is configured in balanced mode where
the servers share equal load. Only port 25 traffic is allowed on the
cluster servers. This configuration would offload SMTP mail processing
from the Exchange servers because all they have to do is to pass the
message along to the cluster for delivery. They do not need to contact
any outside SMTP gateway to transfer the message. This configuration
allows scalability because when the load increases, administrators can
add more SMTP gateways to the cluster. This setup also addresses load
balancing because the NLB cluster is smart enough to notice whether one
of the cluster nodes has failed or is down for maintenance. An
additional ramification of this configuration is that message tracking
will not work beyond the Exchange servers.
Note
Administrators
should not forget about the ramifications of antivirus and spam checking
software with NLB. These packages in Gateway mode can also be used as
the SMTP gateway for an organization. In an NLB clustered mode, an
organization would need to purchase three sets of licenses to cover each
NLB node.
A less used
but possible configuration for SMTP mail load balancing uses DNS to
distribute the load between multiple SMTP servers. This configuration,
known as DNS round-robin, does not provide as robust a message-routing
environment as the NLB solution.
