1. Sites, Site Links, and Site Link Bridgeheads
For purposes of replication, AD DS logically
organizes groups of servers into a concept known as sites. Generally
speaking, a single site should be composed of servers that are connected
to each other via high-speed connections. The links that are
established to connect two or more locations connected potentially
through slower-speed connections are known as site links. Sites are
created with site links connecting the locations together to enable the
administrator to specify the bandwidth used to replicate information
between sites.
Instead of having information replicated
immediately between servers within a high-speed connected site, the
administrator can specify to replicate information between two sites
only once per night or at a time when network demands are low, allowing
more bandwidth availability to replicate AD DS information.
Servers that funnel intersite replication through themselves are known as site link bridgeheads.
Figure 1
shows a potential Windows Server 2012 AD DS site structure. Site links
exist between offices, and a DC in each site acts as the site link
bridgehead. The site structure is completely modifiable and should
roughly follow the WAN structure of an organization. By default, only a
single site is created in AD DS, and administrators must manually
create additional sites to be able to optimize replication.
Figure 1. A potential AD DS Site Structure
2. Understanding Originating Writes
Replication of objects between DCs is
accomplished through the use of a property known as originating writes.
As changes are made to an object, this property is incrementally
increased in value. A DC compares its own version of this value with
the one received during a replication request. If it is lower, the
change is applied; if not, it is discarded. This simple approach to
replication is also extremely reliable and efficient and allows for
effective object synchronization.
3. Using New PowerShell Replication Commandlets in Windows Server 2012
Windows Server 2012 introduces new
PowerShell commandlets that are meant to act as a replacement for
legacy tools such as repadmin, which were previously used to control AD
DS replication. These commandlets, allow for fully automated replication administration and the creation
of automated scripts for managing replication between DCs.
4. Examining DNS Namespace Concepts
A DNS namespace, simply defined, is the
bounded logical area formed by a DNS name and its subdomains. For
example, europe.companyabc.com, asia.companyabc.com,
and companyabc.com are all part of the same contiguous DNS namespace. A
DNS namespace in AD DS can be published on the Internet, such as microsoft.com or cco.com, or it can be hidden from public exposure, depending on the strategy and security needs of its implementers.
• External (published) namespaces—A DNS name that can be resolved from anywhere on the Internet is known as a published or external namespace. This type of
namespace was previously common for organizations that wanted the full
convenience of having their commonly used Internet domain name
represent their AD DS structure. Best practices have evolved to make
this model less attractive, however, as security becomes a concern and
DNS must be set up as “split brain” because it is generally ill-advised
to have internal AD DNS zones accessible from the Internet.
• Internal (hidden) namespaces—For
many organizations, publication of their internal domain structure is
too high a security risk. These organizations can easily define their
AD DS with an internal namespace that is not readable from the
Internet. For example, a company might have an external DNS namespace
of cco.com but decide that
its AD DS structure will correspond to cco.internal or any namespace it
wants. Bear in mind that any combination will work for internal
namespaces because there is no limitation on using .com, .net, .gov,
and so on when dealing with a namespace that is not published. For all
intents and purposes, you could name your domain ilovemydomain.verymuch
if you want (although it’s not recommended, of course). For practical
reasons, however, the .internal namespace has been specifically
reserved for private name addressing, and using it is a best practice
approach in many cases.
Note
If deciding to use a domain
namespace that theoretically could be bought and used on the Internet
either now or in the future, it is wise to purchase the rights to that
domain name to prevent potential conflicts with name resolution in the
future. For example, if you choose the internal namespace
companyabc.com, you might want to first verify that it is not taken and
buy it if possible. If you find the domain name is already owned by
another company, you might choose a different domain name for your AD
DS namespace. Even though your domain might not be published on the
Internet, home or laptop users who need dial-in or VPN access to your
domain might experience conflicts because they would be incorrectly
routed to the wrong DNS name on the Internet instead of to your
company’s namespace.
5. Dynamic DNS
Dynamic DNS (DDNS) was developed as
an answer to the problem of DNS tables having to be manually updated
when changes were made. DDNS in Windows Server 2012 automatically
updates the DNS table based on registrations, and can work in
conjunction with Dynamic Host Configuration Protocol (DHCP) to
automatically process DNS changes as clients are added and removed from
the network infrastructure. DDNS is not required for AD DS to function
properly, but it makes administration much easier than previous manual
methods.
6. Comparing Standard DNS Zones and AD-Integrated DNS Zones
Standard DNS essentially stores all name
records in a text file and keeps it updated via dynamic updates. If you
are accustomed to using UNIX BIND DNS or other standard forms of DNS,
this is essentially what standard DNS is in Windows Server 2012.
AD DS expands
on other implementations of DNS by allowing administrators to integrate
DNS into AD DS. By doing this, the DNS zones themselves exist as
objects in the AD DS, which allows for automatic zone transfers to be
accomplished. DNS replication traffic piggybacks off AD DS traffic, and
the DNS records are stored as objects in the directory. In the Windows
Server 2012 implementation of AD DS, AD-integrated DNS zones are
optimized by being stored in the application partition, thus reducing
replication traffic and improving performance.
7. Understanding How AD DS DNS Works with Foreign DNS
Often, some local administrators
might be hesitant to deploy AD DS because of their desire to maintain
their own foreign DNS implementation, usually UNIX BIND. If this is the
case, it is possible for Windows Server 2012 DNS to coexist in this
type of environment, as long as the DNS supports dynamic updates and
SRV records (BIND 8.2.x or later). These situations occur more often
than not, as political situations within IT departments are often
divided into pro-Microsoft and pro-UNIX groups, each of which has its
own ideology and plans. The ability of Windows Server 2012 to coexist
peacefully in these types of environments is, therefore, key.
