Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Understanding DNS Requirements for Exchange Server 2010

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
3/20/2011 8:56:49 AM
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:

  • A two-way routing group connector must be created from the Exchange Server routing group to each Exchange Server 2003 routing group that Exchange Server 2010 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 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:

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

Other -----------------
- Exchange Server 2010 : Examining DNS Components (part 2) - DNS Replication or Zone Transfer & DNS Resource Records
- Exchange Server 2010 : Examining DNS Components (part 1) - DNS Zones & DNS Queries
- Domain Name System and Its Role in Exchange Server 2010
- Configuring Windows Server 2003 for LAN Routing (part 4) - Exploring LAN Routing Scenarios
- Configuring Windows Server 2003 for LAN Routing (part 3) - Managing General IP Routing Properties & Working with Routing Tables
- Configuring Windows Server 2003 for LAN Routing (part 2) - Configuring Routing And Remote Access Service Properties
- Configuring Windows Server 2003 for LAN Routing (part 1) - Using the Routing And Remote Access Console
- Microsoft Content Management Server : Managing Template Galleries and Templates (part 4) - Moving Template Galleries and Templates
- Microsoft Content Management Server : Managing Template Galleries and Templates (part 3) - Copying Templates
- Microsoft Content Management Server : Managing Template Galleries and Templates (part 2) - Creating Templates
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server