Logo - tutorial.programming4.us
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 2013 (part 1)

12/13/2014 8:07:19 PM

With Microsoft Exchange relying on Active Directory and domain name system (DNS) to function, it is important for an organization to make sure that critical networking services are configured and operating properly and that domain controllers have been deployed and configured to adequately support the environment. Exchange Server 2013 has removed its reliance on NetBIOS and Windows Internet Naming Service (WINS) for its networking services and is now very dependent upon the successful operation of Active Directory and DNS.

Domain Name System and Its Role in Exchange Server 2013

For computer systems to communicate with each other, whether you are talking about a local area network (LAN), a wide area network (WAN), or the Internet, they must have the ability to identify one another using some type of name resolution. Several strategies have been developed over the years, but the most reliable one to date (and the current industry standard) is the use of a DNS.

Accurate name resolution is critical in a mail environment as well. For a message to reach its destination, it might pass through several systems that need to know where it came from and where it is going.

Even Lightweight Directory Access Protocol (LDAP) queries for local mailbox users require the DNS client to be properly configured and functioning on your Exchange Server 2013 servers.

Domain Name System Defined

The Internet, as well as most home and business networks, rely on Internet Protocol (IP) addresses to allow computers to connect to one another. If we had to remember the IP addresses of every website, server, workstation, and printer that we connect to on a daily basis, it would be very difficult to accomplish anything!

The domain name system, commonly abbreviated as DNS, is a hierarchical, distributed database used to resolve, or translate, domain and host names to IP addresses. Using DNS, users, computers, and applications that query DNS can specify remote systems by fully qualified domain names (FQDNs).

DNS is the primary method for name resolution for the Microsoft Windows Server platforms. DNS is also a requirement for deploying Active Directory (AD), though Active Directory is not a requirement for deploying DNS. That being said, in a Microsoft Windows environment, integrating DNS and Active Directory enables DNS servers to take advantage of the security, performance, and fault-tolerance capabilities designed into Active Directory.

Using DNS

DNS is composed of two components: clients and servers. Servers store information about specific components.

When a DNS client needs to contact a host system, it first attempts to do so by using local resources. The client first checks its local cache, which is created by saving the results of previous queries. Items in the local cache remain until one of three things occurs:

• The Time to Live (TTL) period, which is set on each item, expires.

• The client runs the ipconfig /flushdns command.

• The DNS client is shut down.

Next, the client attempts to resolve the query using the local hosts file, which, on Windows systems, is located in the %systemroot%\system32\drivers\etc directory. This file is used to manually map host names to IP addresses, and remains in place even if the system is rebooted.

Finally, if the client is unable to resolve the query locally, it forwards the request to the first DNS server in the list in the network configuration that responds for resolution. The DNS server attempts to resolve the client’s query as detailed next:

• If the query result is found in any of the zones for which the DNS server is authoritative, the server responds to the host with an authoritative answer.

• If the result is in the zone entries of the DNS server, the server checks its own local cache for the information.

If the DNS server is unable to resolve the query, it forwards the request to other DNS servers, sending what is known as a recursive query. The server forwards to other servers that are listed as “forwarders,” or to one of a set of servers configured in the DNS server’s “Root Hints” file.

The DNS query is forwarded through communications channels on the Internet until it reaches a DNS server that is listed as being authoritative for the zone listed in the query. That DNS server then sends back a reply—either an “affirmative,” with the IP address requested, or a “negative” stating that the host in question could not be resolved.

Understanding Who Needs DNS

Not all situations require the use of DNS. There are other name resolution mechanisms that exist besides DNS, some of which come standard with the operating system (OS) that companies deploy. Although not all scenarios have the requirement of a complex name resolution structure, DNS makes life easier by managing name servers in a domain sometimes with little overhead.

In the past, an organization with a standalone, noninterconnected network could get away with using only host files or WINS to provide NetBIOS-to-IP address name translation. Some very small environments could also use broadcast protocols such as NetBEUI to provide name resolution. In modern networks, however, DNS becomes a necessity, especially in Active Directory environments.

Outlining the Types of DNS Servers

DNS is an integral and necessary part of any Windows Active Directory implementation. In addition, it has evolved to be the primary naming service for UNIX operating systems and the Internet. Because of Microsoft’s decision to make Windows 2000 Server, Windows Server 2003, and Windows Server 2012 Internet-compatible, DNS has replaced WINS as the default name resolution technology. Microsoft followed Internet Engineering Task Force (IETF) standards and made its DNS server compatible with other DNS implementations.


Many organizations have significant investment in UNIX DNS implementations. Microsoft Exchange heavily relies on Active Directory, and Active Directory heavily relies on DNS. Microsoft Active Directory can coexist and use third-party DNS implementations as long as they support active updates and Service (SRV) records. In some cases, organizations choose not to migrate away from the already implemented UNIX DNS environment; instead, they coexist with Microsoft DNS. Companies using UNIX DNS for Microsoft AD clients should consider the following:

• The UNIX DNS installation should be at least 8.1.2.

• For incremental zone transfers, the UNIX DNS implementation should be at least 8.2.1.

Examining DNS Compatibility Between DNS Platforms

In theory, DNS clients should be able to query any DNS server. Active Directory, however, has some unique requirements. Clients that authenticate to Active Directory look specifically for server resources, which means that the DNS server has to support SRV records. In Active Directory, DNS clients can dynamically update the DNS server with their IP address using Dynamic DNS. It is important to note that Dynamic DNS is not supported by all DNS implementations.


In a mixed DNS environment, Microsoft specifically recommends using Microsoft DNS server as the primary DNS server for clients, with other DNS servers set up as forwarders or secondary zone servers. This is because Microsoft clients natively support dynamic registration and lookups against Microsoft DNS.

Examining DNS Components

As previously mentioned, name servers, or DNS servers, are systems that store information about the domain namespace. Name servers can have either the entire domain namespace or just a portion of the namespace. When a name server only has a part of the domain namespace, the portion of the namespace is called a zone.

DNS Zones

There is a subtle difference between zones and domains. All top-level domains, and many domains at the second and lower levels, are broken into zones—smaller, more manageable units by delegation. A zone is the primary delegation mechanism in DNS over which a particular server can resolve requests.

A name server can have authority over more than one zone. Different portions of the DNS namespace can be divided into zones, each of which can be hosted on a DNS server or group of servers.

Forward Lookup Zones

A forward lookup zone is created to do forward lookups on the DNS database, resolving names to IP addresses and resource information.

Reverse Lookup Zones

A reverse lookup zone performs the opposite operation as the forward lookup zone. IP addresses are matched up with a common name in a reverse lookup zone. This is similar to knowing the phone number but not knowing the name associated with it. Reverse lookup zones must be manually created, and do not exist in every implementation. Reverse lookup zones are primarily populated with Pointer (PTR) records, which serve to point the reverse lookup query to the appropriate name.


It is good practice for the Simple Mail Transfer Protocol (SMTP) mail server to have a record in the Internet-facing reverse lookup DNS zone. Spam control sites check for the existence of this record. It is possible to have outbound mail rejected as spam if the site does not have a PTR record for the Mail Exchange (MX) entry in the DNS reverse lookup zone.

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 Exchange Server 2013 : Working with cmdlets (part 2) - Understanding cmdlet errors, Using cmdlet aliases
- Microsoft Exchange Server 2013 : Working with cmdlets (part 1) - Using Windows PowerShell cmdlets, Using cmdlet parameters
- Microsoft Exchange Server 2013 : Using Windows PowerShell (part 2) - Running and using cmdlets, Running and using other commands and utilities
- Microsoft Exchange Server 2013 : Using Windows PowerShell (part 1) - Running and using Windows PowerShell
- Troubleshooting Stop Messages : Being Prepared for Stop Errors - Prevent System Restarts After a Stop Error
- Troubleshooting Stop Messages : Memory Dump Files (part 3) - Using Memory Dump Files to Analyze Stop Errors - WinDbg Debugger
- Troubleshooting Stop Messages : Memory Dump Files (part 2) - Using Memory Dump Files to Analyze Stop Errors - Using Problem Reports And Solutions
- Troubleshooting Stop Messages : Memory Dump Files (part 1) - Configuring Small Memory Dump Files, Configuring Kernel Memory Dump Files
- Troubleshooting Stop Messages : Stop Message Overview - Identifying the Stop Error, Finding Troubleshooting Information
- Deploying IPv6 : Planning for IPv6 Migration - Understanding ISATAP, Migrating an Intranet to IPv6