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

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
12/13/2014 8:15:40 PM

Troubleshooting with DNSLINT

DNSLINT is a Microsoft Windows utility that helps administrators diagnose common DNS name resolution issues. The utility is not installed by default on Windows servers and has to be downloaded from Microsoft.

When this command-line utility runs, it generates a Hypertext Markup Language (HTML) file in the directory it runs from. It can help administrators with Active Directory troubleshooting and also with mail-related name resolution and verification. Running DNSLINT /d <domain_name> /c tests DNS information as known on authoritative DNS servers for the domain being tested; it also checks SMTP, Post Office Protocol version 3 (POP3), and Internet Message Access Protocol (IMAP) connectivity on the server. For the complete options for this utility, run DNSLINT /?.

Using dnscmd for Advanced DNS Troubleshooting

The dnscmd utility is essentially a command-line version of the MMC DNS console. Installed natively with Windows Server 2012, this utility enables administrators to create zones, modify zone records, and perform other vital administrative functions. To install the support tools, run the support tools setup from the Windows Server 2003 CD (located in the \support\tools directory). You can view the full functionality of this utility by typing DNSCMD /? at the command line.

Global Catalog and Domain Controller Placement

When deploying Exchange Server 2013 in your environment, Active Directory is a critical component. Exchange Server 2013 uses the Active Directory directory service to store and share directory information with Microsoft Windows.

If you have already deployed Active Directory into your environment, it is important that you have a solid understanding of your existing implementation and how Exchange will fit into your structure. If you have not deployed AD, you need to design the environment with your Exchange environment in mind.

In addition, you need to evaluate your organization’s administrative model, as the marriage of Exchange Server 2013 and AD allows you to administer Exchange along with the operating system.

When integrating Exchange Server 2013 and Active Directory, the placement of domain controllers and global catalog servers is paramount; without proper placement of these key items, your Exchange environment will not be able to perform optimally.

Understanding Active Directory Structure

AD is a standards-based LDAP directory service developed by Microsoft that stores information about network resources and makes it accessible to users and applications, such as Exchange Server 2013. Directory services are vital in any network infrastructure because they provide a way to name, locate, manage, and secure information about the resources contained.

The Active Directory directory service provides single-logon capability and a central repository for the information for your entire organization. User and computer management are greatly simplified, and network resources are easier than ever to access.

In addition, Active Directory is heavily utilized by Exchange, and stores all of your Exchange attributes: email addresses, mailbox locations, home servers, and a variety of other information.

Exploring AD Domains

An Active Directory domain is the main logical boundary of Active Directory. In a standalone sense, an AD domain looks very much like a Windows NT domain. Users and computers are all stored and managed from within the boundaries of the domain. However, several major changes have been made to the structure of the domain and how it relates to other domains within the Active Directory structure.

Domains in Active Directory serve as a security boundary for objects and contain their own security policies. For example, different domains can contain different password policies for users. Keep in mind that domains are a logical organization of objects and can easily span multiple physical locations. Consequently, it is no longer necessary to set up multiple domains for different remote offices or sites because replication concerns can be addressed with the proper use of Active Directory sites.

Exploring AD Trees

An Active Directory tree is composed of multiple domains connected by two-way transitive trusts. Each domain in an Active Directory tree shares a common schema and global catalog. The transitive trust relationship between domains is automatic, which is a change from the domain structure of NT 4.0, wherein all trusts had to be manually set up. The transitive trust relationship means that because the asia domain trusts the root companyabc domain, and the europe domain trusts the companyabc domain, the asia domain also trusts the europe domain. The trusts flow through the domain structure.

Exploring AD Forests

Forests are a group of interconnected domain trees. Implicit trusts connect the roots of each tree into a common forest.

The overlying characteristics that tie together all domains and domain trees into a common forest are the existence of a common schema and a common global catalog. However, domains and domain trees in a forest do not need to share a common namespace. For example, the domains microsoft.com and msnbc.com could theoretically be part of the same forest, but maintain their own separate namespaces (for obvious reasons).


Each separate instance of Exchange Server 2013 requires a completely separate AD forest. In other words, AD cannot support more than one Exchange organization in a single forest. This is an important factor to bear in mind when examining AD integration concepts.

The domain is not an ironclad security boundary between domains in a forest because a domain administrator who knows what he is doing can grant himself rights on other domains in the forest. This security hole has diminished the justification for creating multidomain forests. Delegated organizational units can actually provide better compartmentalized security.

Understanding AD Replication with Exchange Server 2013

An understanding of the relationship between Exchange and Active Directory is not complete without an understanding of the replication engine within AD itself. This is especially true because any changes made to the structure of Exchange must be replicated across the AD infrastructure.

Active Directory replaced the concept of Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs) with the concept of multiple domain controllers that each contains a master read/write copy of domain information. Changes that are made on any domain controller within the environment are replicated to all other domain controllers in what is known as multimaster replication.

Active Directory differs from most directory service implementations in that the replication of directory information is accomplished independently from the actual logical directory design. The concept of Active Directory sites is completely independent from the logical structure of Active Directory forests, trees, and domains. In fact, a single site in Active Directory can actually host domain controllers from different domains or different trees within the same forest. This enables the creation of a replication topology based on your WAN structure, and your directory topology can mirror your organizational structure.

From an Exchange point of view, the most important concept to keep in mind is the delay that replication causes between when a change is made in Exchange and when that change is replicated throughout the entire AD structure. The reason for these types of discrepancies lies in the fact that not all AD changes are replicated immediately. This concept is known as replication latency. Because the overhead required in immediately replicating change information to all domain controllers is large, the default schedule for replication is not as often as you might want. To immediately replicate changes made to Exchange or any AD changes, use the following procedure:

1. Open the Active Directory Sites and Services tool.

2. Drill down to Sites, sitename, Servers, servername, NTDS Settings. The server name chosen should be the server you are connected to, and from which the desired change should be replicated.

3. Right-click each connection object and choose Replicate Now, as illustrated in Figure 4.


Figure 4. Forcing AD replication.

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
- First look: Apple Watch

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

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
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 windows Phone 7 windows Phone 8
programming4us programming4us
Natural Miscarriage
Windows Vista
Windows 7
Windows Azure
Windows Server
Game Trailer