|
|
|
Windows Server 2012 : Preparing for deploying domain controllers (part 1) - AD DS deployment scenarios
|
|
|
|
|
|
|
|
|
|
|
|
12/26/2013 3:00:23 AM
|
|
|
Careful planning is of key importance when you roll out or make
changes to an AD DS environment by adding, replacing, or upgrading
domain controllers. A number of different scenarios are possible, and
you should identify best practices for each scenario you need to
implement for your organization. This lesson describes some common AD DS
deployment scenarios and the different ways that domain controllers can
be deployed for these scenarios.
1. AD DS deployment scenarios
Here are the two basic scenarios for AD DS deployment:
The sections that follow describe the high-level differences
between these scenarios.
If your organization has not yet deployed AD DS, you’re in
luck: this is your opportunity to get it right. Although deploying a
new forest based on Windows Server 2012 AD DS is as simple as
deploying your first domain controller (the forest root domain
controller), there are numerous planning considerations you need to
be aware of before you perform this task.
At a basic level, the technical requirements for deploying
your forest root domain controller are straightforward:
-
You must have local Administrator credentials on the
server. -
You must have one or more local fixed NTFS volumes to
store the directory database, log files, and SYSVOL
share. -
You need to appropriately configure TCP/IP settings,
including Domain Name Server (DNS) server addresses. -
You either need to use an existing DNS server
infrastructure or deploy the DNS Server role together with the
Active Directory Domain Services role when you make your server
a domain controller.
The preceding technical requirements, however, are only a
small part of the overall AD DS planning process. The key at this
stage is to plan the entire directory structure of your organization
so that you won’t need to make drastic changes later on, like
renaming domains or modifying your hierarchy of OUs.
After you create your forest by deploying the forest root
domain controller, you can then deploy additional controllers for
the following purposes:
-
Deploy additional domain controllers in your forest root
domain for redundancy and load-balancing purposes. -
Deploy domain controllers that create additional domains
within your forest based on your organization’s administrative
or geographical structure. -
Deploy read-only domain controllers (RODCs) at less
secure, branch-office sites within your organization. -
Deploy virtualized domain controllers to provide greater
support for private and public cloud-computing
environments.
Note
MORE INFO Resources for AD DS
planning and design
The following resources can be helpful if you are planning
an implementation of AD DS for the first time:
-
Designing and Deploying Directory
and Security Services This section of the Windows
Server 2003 Deployment Guide on Microsoft TechNet—found at
http://technet.microsoft.com/en-us/library/cc787010(v=WS.10).aspx—is
a bit dated, but it’s still a good starting point to learn how
to design and plan an AD DS environment. Be sure to supplement
this resource, however, with the more recent resources that
follow. -
AD DS Design Guide This
section of the TechNet Library—found at http://technet.microsoft.com/en-us/library/cc754678(v=ws.10)—provides
updated guidance on how to design an AD DS environment based
on Windows Server 2008, Windows Server 2008 R2, or Windows
Server 2012. -
Windows Server 2008 Active
Directory Resource Kit from Microsoft Press This book
provides an excellent introduction to basic AD DS concepts,
design, and administration. The book is available from
O’Reilly Media at http://shop.oreilly.com/product/9780735625150.do
in various formats, including APK, DAISY, ePub, Mobi, PDF, and
print-on-demand.
Finally, a good place to find answers to your AD DS
questions is the Directory Services forum on TechNet at http://social.technet.microsoft.com/Forums/en-us/winserverDS/threads.
Best practices for new forest deployments
The actual number of domain controllers and the types needed
for your environment depends on a number of factors, but here are
some key best practices to keep in mind:
-
Each domain should have at least two functioning writeable
domain controllers to provide fault tolerance. If a domain has
only one domain controller and this domain controller fails,
users will not be able to log on to the domain or access any
resources in the domain. And if you have only one writable
domain controller in your domain and this domain controller
fails, you won’t be able to perform any AD DS management
tasks. -
Each domain in each location should also have a sufficient
number of domain controllers to service the needs of users for
logging on and accessing network resources. The TechNet sections
described in the earlier “More Info” topic include some
recommendations on how to determine the number of domain
controllers based on their hardware configuration and the number
of users at the location. -
Domain controllers should be dedicated servers that are
used only for hosting the AD DS and DNS Server roles and nothing
else. Their full attention should be directed to performing
their main job, which is authenticating users and computers for
client logons and for accessing network resources. -
The simplest forest design is to have only one domain. The
more domains you have, the more administrative overhead you will
experience in the form of managing multiple service
administrator groups, maintaining consistency among Group Policy
settings that are common to different domains, maintaining
consistency among access control and auditing settings that are
common to different domains, and so on. -
If your organization has multiple sites, such as a head
office and one or more remote branch offices, you should
generally deploy at least one domain controller at each remote
office to provide users with faster logon times and more
efficient access to network resources. For best security, domain
controllers at remote offices should be RODCs.
Important
End of support date for Windows Server 2003
Windows Server 2003 exited mainstream support in July 2010
and will exit extended support in July 2015, so if you are
planning to upgrade your AD DS environment to Windows Server 2012,
you should do it soon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
