Logo
HOW TO
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Understanding DNS Requirements for Exchange Server 2007

3/21/2013 6:32:00 PM

1. Using DNS to Route SMTP Mail in Exchange Server 2007

The primary protocol for sending email on the Internet today is known as Simple Mail Transfer Protocol, or SMTP. SMTP has been used for quite some time in UNIX and Linux environments, and has been incorporated into Active Directory as an alternative transport mechanism for site traffic.

Domains that want to participate in electronic mail exchange need to set up MX record(s) for their published zone. This advertises the system that will handle mail for the particular domain, so that SMTP mail will find the way to its destination.

Understanding SMTP Mail Routing

Email is arguably the most widely used TCP/IP and Internet application today. SMTP defines a set of rules for addressing, sending, and receiving mail between systems. As a result of a user mail request, the SMTP sender establishes a two-way connection with the SMTP receiver. The SMTP receiver can be either the ultimate destination or an intermediate (mail gateway). The SMTP sender generates commands that are replied to by the receiver. All this communication takes place over TCP port 25. When the connection is established, a series of commands and replies are exchanged between the client and server. This connection is similar to a phone conversation, and the commands and responses are equivalent to verbal communication.

Note

In various implementations, there is a possibility of exchanging mail between the TCP/IP SMTP mailing system and the locally used mailing systems. These applications are called mail gateways or mail bridges. Sending mail through a mail gateway may alter the end-to-end delivery specification because SMTP guarantees delivery only to the mail gateway host, not to the real destination host, which is located beyond the TCP/IP network. When a mail gateway is used, the SMTP end-to-end transmission is host-to-gateway, gateway-to-host, or gateway-to-gateway; the behavior beyond the gateway is not defined by SMTP.


Examining Client DNS Use for Exchange

Before users can access their mailboxes on an Exchange server, they must be authenticated. Authentication requires a DNS lookup to locate a domain controller on which the users’ accounts can be authenticated.

Clients normally cannot deliver messages directly to destination mail hosts. They typically use a mail server to relay messages to destinations. Using SMTP, clients connect to a mail server, which first verifies that the client is allowed to relay through this server, and then accepts the message destined for other domains.

A client uses DNS to resolve the name of a mail server. For example, when configuring an Outlook mail client to connect to an Exchange server, only the short name and not the FQDN is used to connect to the server. The short name is resolved by DNS to the FQDN of the Exchange server to which the client is connected.

2. Understanding DNS Requirements for Exchange Server 2007

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 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 2007

As has been stated, Active Directory and DNS access are vital to an Exchange implementation. It is critical that the host records for all Exchange 2007 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 2007 servers.

Any computer acting in one of the Exchange 2007 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 and Mailbox server roles are required for a minimal Exchange 2007 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 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

Exchange 2007 can be deployed in an existing Exchange 2000 Server or Exchange Server 2003 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 Environments

For Exchange 2007 to communicate properly with Exchange 2000 or Exchange 2003, the routing group connectors between the Exchange 2007 Hub Transport servers and the older bridgehead servers must be configured correctly. When you install an Exchange 2007 server into an existing organization, the server is recognized by the Exchange 2000 Server or 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 2000 Server and Exchange Server 2003 used SMTP as the primary communication protocol between Exchange servers, but in Exchange 2007, 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.

Routing in Exchange Server 2007

Although Exchange 2000 Server and Exchange Server 2003 use routing groups to define the Exchange routing topology, Exchange 2007 uses Active Directory sites to do so, so an Exchange-specific routing configuration is no longer needed in a pure Exchange 2007 organization.

For the two routing topologies to coexist, all Exchange 2007 servers are automatically added to a routing group when the server is installed. This Exchange 2007 routing group is recognized in the Exchange System Manager for Exchange 2000 and 2003 as an Exchange Routing Group within Exchange Administrative Group.

For Exchange 2007 to coexist with Exchange 2000 Server or Exchange Server 2003, you need to perform the following tasks:

  • A two-way routing group connector must be created from the Exchange routing group to each Exchange 2000 Server and Exchange Server 2003 routing group that Exchange 2007 will communicate with directly.

Note

The first routing group connector is created during installation of the first Hub Transport server when installed in an existing Exchange organization.


These connectors allow mail to be routed from Exchange 2000 Server or Exchange Server 2003 to Exchange 2007.

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:

1.
The sender contacts its SMTP gateway for message delivery.

2.
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.

3.
The application proxy forwards the message for virus checking.

4.
After virus checking, the mail is routed back to the application proxy.

5.
Mail is delivered to the internal SMTP gateway.

6.
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 25 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 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 2007, 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 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 2007 organization.

Actually, you can add an Edge Transport server to any existing Exchange 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 2007, 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 2003 and Exchange Server 2007 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.

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 off-load 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.

Other -----------------
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Examining DNS Components
- Nginx HTTP Server : Basic Nginx Configuration - Base module directives
- Nginx HTTP Server : Basic Nginx Configuration - Configuration file syntax
- SharePoint 2010 : Configuring Search Settings and the User Interface - Web Parts (part 4)
- SharePoint 2010 : Configuring Search Settings and the User Interface - Web Parts (part 3)
- SharePoint 2010 : Configuring Search Settings and the User Interface - Web Parts (part 2)
- SharePoint 2010 : Configuring Search Settings and the User Interface - Web Parts (part 1)
- Windows Server 2008 R2 file and print services : Administering Print and Document Services (part 2) - Distributed scan server
- Windows Server 2008 R2 file and print services : Administering Print and Document Services (part 1)
- Windows Server 2008 R2 file and print services : Services for Network File System, Windows Search Service
 
 
REVIEW
- First look: Apple Watch

- 10 Amazing Tools You Should Be Using with Dropbox

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
 
VIDEO TUTORIAL
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
 
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Popular keywords
HOW TO Swimlane in Visio Visio sort key Pen and Touch Creating groups in Windows Server Raid in Windows Server Exchange 2010 maintenance Exchange server mail enabled groups Debugging Tools Collaborating
Top 10
- Microsoft Excel : How to Use the VLookUp Function
- Fix and Tweak Graphics and Video (part 3) : How to Fix : My Screen Is Sluggish - Adjust Hardware Acceleration
- Fix and Tweak Graphics and Video (part 2) : How to Fix : Text on My Screen Is Too Small
- Fix and Tweak Graphics and Video (part 1) : How to Fix : Adjust the Resolution
- Windows Phone 8 Apps : Camera (part 4) - Adjusting Video Settings, Using the Video Light
- Windows Phone 8 Apps : Camera (part 3) - Using the Front Camera, Activating Video Mode
- Windows Phone 8 Apps : Camera (part 2) - Controlling the Camera’s Flash, Changing the Camera’s Behavior with Lenses
- Windows Phone 8 Apps : Camera (part 1) - Adjusting Photo Settings
- MDT's Client Wizard : Package Properties
- MDT's Client Wizard : Driver Properties
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro