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 Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 4)

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
12/13/2014 8:12:29 PM
Service (SRV) Records

SRV records are RRs that indicate which resources perform a particular service. Domain controllers in Active Directory are referenced by SRV records that define specific services, such as the global catalog, LDAP, and Kerberos. SRV records are relatively new additions to DNS and did not exist in the original implementation of the standard. Each SRV record contains information about a particular functionality that a resource provides. For example, an LDAP server can add an SRV record indicating that it can handle LDAP requests for a particular zone. SRV records can be very useful for Active Directory because domain controllers can advertise that they can handle GC requests.


Note

Because SRV records are a relatively new addition to DNS, they are not supported by several down-level DNS implementations, such as UNIX BIND 4.1 and NT 4.0 DNS. It is, therefore, critical that the DNS environment that is used for Windows Server 2012 Active Directory has the capability to create SRV records. For UNIX BIND servers, version 8.1.2 or higher is required.


Alias Records

A canonical name (CNAME) record represents a server alias or allows any one of the member servers to be referred to by multiple names in DNS. The record redirects queries made to the A record for the particular host. CNAME records are useful when migrating servers, and for situations in which friendly names, such as mail.companyabc.com, are required to point to more complex, server-naming conventions, such as sfoexch01.companyabc.com.


Caution

Though DNS entries for MX records can be pointed to CNAME host records, doing so is not advised and is not a Microsoft recommended best practice. Increased administrative overhead and the possibility of misrouted messages can result. Microsoft recommends that mail/DNS administrators always link MX records to fully qualified principal names or domain literalss.


Other Records

Other, less common forms of records that might exist in DNS have specific purposes, and there might be cause to create them. The following is a sample list, but it is by no means exhaustive:

AAAA—Maps a standard IP address into a 128-bit IPv6 address. This type of record becomes more prevalent as IPv6 is adopted.

ISDN—Maps a specific DNS name to an Integrated Services Digital Network (ISDN) telephone number.

KEY—Stores a public key used for encryption for a particular domain.

RP—Specifies the responsible person for a domain.

WKS—Designates a particular well-known service.

MB—Indicates which host contains a specific mailbox.

Multihomed DNS Servers

For multihomed DNS servers, an administrator can configure the DNS service to selectively enable and bind only to IP addresses that are specified using the DNS console. By default, however, the DNS service binds to all IP interfaces configured for the computer.

This can include the following:

• Any additional IP addresses configured for a single network connection.

• Individual IP addresses configured for each separate connection where more than one network connection is installed on the server computer.

• For multihomed DNS servers, an administrator can restrict DNS service for selected IP addresses. When this feature is used, the DNS service listens for and answers only DNS requests that are sent to the IP addresses specified on the Interface tab in the Server properties.

By default, the DNS service listens on all IP addresses and accepts all client requests sent to its default service port (UDP 53 or TCP 53 for zone transfer requests). Some DNS resolvers require that the source address of a DNS response be the same as the destination address that was used in the query. If these addresses differ, clients could reject the response. To accommodate these resolvers, you can specify the list of allowed interfaces for the DNS server. When a list is set, the DNS service binds sockets only to allowed IP addresses used on the computer.

In addition to providing support for clients that require explicit bindings to be used, specifying interfaces can be useful for other reasons:

• If an administrator does not want to use some of the IP addresses or interfaces on a multihomed server computer

• If the server computer is configured to use a large number of IP addresses and the administrator does not want the added expense of binding to all of them

When configuring additional IP addresses and enabling them for use with the Windows Server 2012 DNS server, consider the following additional system resources that are consumed at the server computer:

• DNS server performance overhead increases slightly, which can affect DNS query reception for the server.

• Although Windows Server 2012 provides the means to configure multiple IP addresses for use with any of the installed network adapters, there is no performance benefit for doing so.

• Even if the DNS server is handling multiple zones registered for Internet use, it is not necessary or required by the Internet registration process to have different IP addresses registered for each zone.

• Each additional address might only slightly increase server performance. In instances when a large overall number of IP addresses are enabled for use, server performance can be degraded noticeably.

• In general, when adding network adapter hardware to the server computer, assign only a single primary IP address for each network connection.

• Whenever possible, remove nonessential IP addresses from existing server TCP/IP configurations.

Using DNS to Route SMTP Mail in Exchange Server 2013

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

After the World Wide Web, email is arguably the second 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.

Understanding DNS Requirements for Exchange Server 2013

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 2013

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 Server 2013 servers be properly registered and configured in the DNS server for the Active Directory forest. Clients, as well as other servers, will use DNS to locate and communicate with Exchange Server 2013 servers.

Any computer acting in one of the Exchange Server 2013 organizational server roles must be a domain member and registered in DNS. The three server roles are as follows:

• Edge Transport

• Client Access server

• Mailbox server

All server roles, with the exception of the Edge Transport, can be deployed on a single server.

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

3. Click Advanced System Settings to open the System Properties dialog box.

4. Click the Computer Name tab.

5. Click Change.

6. On the Computer Name Changes page, click More.

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

RFCs 2821 and 2822 define SMTP, which replaced the earlier versions of RFCs 821 and 822.

Other -----------------
- Windows Server 2012 : Enhancing DHCP Reliability - Windows Server 2012 DHCP Failover
- Windows Server 2012 : Enhancing DHCP Reliability - Implementing Redundant DHCP Services
- Windows Server 2012 : Enhancing DHCP Reliability - DHCP Network Access Protection Integration
- Windows Server 2012 : Enhancing DHCP Reliability - DHCP Name Protection, DHCP and Dynamic DNS Configuration
- Windows Server 2012 : Enhancing DHCP Reliability - Link-Layer Filtering, DHCP Reservations
- Exploring DHCP Changes in Windows Server 2012 : Migrating DHCP Services from 2008 R2 to Windows Server 2012, derstanding DHCP Client Alternate Network Capability
- Exploring DHCP Changes in Windows Server 2012 : Migrating DHCP Servers Using Windows Server Migration Tools
- Sharepoint 2013 : The Office Web Applications for Sharepoint - Preparing the Server and Installing OWA via the GUI
- Sharepoint 2013 : The Office Web Applications for Sharepoint - Topology
- Sharepoint 2013 : The Office Web Applications for Sharepoint - Mobile Device Support
 
 
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