3. Thinking about server roles and Active Directory
When planning for server usage, consider the workload
of each server: which services it is providing, the expected user load,
and so on. In small network environments, it is common for a single
server to act as a domain controller and to provide DNS and Dynamic Host
Configuration Protocol (DHCP) services and possibly even additional
services. In larger network environments, one or more standalone servers
might provide each of these services rather than them being aggregated
on a single system.
Active Directory is an extremely complicated, and critical, portion
of Windows Server 2012, and you should plan for it with appropriate
care.
The following section discusses, in abbreviated form, some high-level
aspects of server usage and Active Directory that you must consider. It
is meant to offer a perspective on how various server roles, including domain controllers, fit in the overall planning picture, not to explain how to plan for a new Active Directory installation.
Planning for server usage
Windows Server 2012 employs a number of server
roles, each of which corresponds to one or more services. Your plan
should detail which roles (and additional services) are needed and the
number and placement of servers, as well as define the configuration for
each service. When planning server usage, be sure to keep the expected
client load in mind and account for remote sites that might require
additional servers to support local operations.
Key Windows Server 2012 server roles are as follows:
-
Domain controller
Active Directory domain controllers are perhaps the most important type
of network server on a Windows network. Domain controllers are also one
of the most intensively used servers on a Windows network, so it is
important to realistically assess the operational requirements and
server performance for each one. Remember to take into account any
secondary Active Directory–related roles the server will be performing
(such as global catalog, operations master, and so on). Keep the
following questions in mind:
-
How many domain controllers are required, and which ones will fulfill which roles? -
Which domains must be present at which sites? -
Where should global catalogs be placed? -
What remote offices (if any) will use RODCs?
-
DNS server DNS is
an integral part of a Windows network, with many important features
(such as Active Directory) relying on it. Accordingly, DNS servers are
now a required element of your suite of network services. Plan for
enough DNS servers to service client requests, with adequate redundancy
for fault tolerance and performance, and plan to have them distributed
throughout your network to be available to all clients. Factor in remote
sites with slow links to the main corporate network and those that
might be only intermittently connected by dial-up. Be sure to do the
following:
-
Define both internal and external namespaces. -
Plan the name-resolution path (forwarders and so on). -
Determine the storage of DNS information (zone files, Active Directory–integrated, application partitions). -
Determine whether you need read-only DNS services at remote offices with RODCs. -
Determine whether you need secure DNS (DNSSEC).
Note
Microsoft DNS is
the recommended method of providing domain name services on a network
with Active Directory deployed, although some other DNS servers provide
the required functionality. In practice, however, the intertwining of
Active Directory and DNS, along with the complexity of the DNS records
used by Active Directory, has meant that Microsoft DNS is the one most often used with Active Directory.
Note
DNS information can be stored in traditional zone files, Active Directory–integrated zones, or application partitions, which are new to Windows Server
2012. An application partition contains a subset of directory
information used by a single application. In the case of DNS, this
partition is replicated only to domain controllers that are also
providing DNS services, minimizing network traffic for DNS replication.
There is one application partition for the forest (ForestDnsZones) and another for each domain (DomainDnsZones).
-
DHCP server
DHCP simplifies the
management of the IP address pool used by both server and client
systems. A number of operational factors regarding the use of DHCP
should be considered:
-
Determine whether DNS servers are going to act as DHCP servers also
and, if so, will all of them or only a subset of them be used in this
way? -
Define server configuration factors such as DHCP scopes and the
assignment of scopes to servers, as well as client settings such as the
DHCP lease length. -
Determine whether failover scopes are needed to increase fault tolerance and provide redundancy.
-
WINS server
First, determine
whether you still need WINS on your network. If you have legacy
applications in your network environment, WINS might be required to
translate NetBIOS names to IP addresses. If so, consider the following:
-
Network Policy and Access Services
Network Policy and
Access Services provides integrated protection, routing, and
remote-access services that facilitate secure, protected access by
remote users. Consider the following:
-
Do you need protection policies? -
Do you need to provide routing between networks? -
Do you want to replace existing routers? -
Do you have external users who need access to the internal network?
-
Hyper-V server
Hyper-V provides infrastructure for virtualizing applications and workloads. Use Hyper-V to
-
Consolidate servers and workloads onto fewer, more powerful servers and reduce requirements for power and space. -
Implement a centralized desktop strategy by combining Hyper-V technology with Remote Desktop Virtualization Host technology. -
Create a private cloud for shared resources that you can adjust as demand changes.
-
Application server
A Windows Server
2012 application server hosts distributed applications built using
ASP.NET, Enterprise Services, and .NET Framework. It includes more than a
dozen role services, which are discussed in detail in Internet Information Services (IIS) 7.0 Administrator’s Pocket Consultant (Microsoft Press, 2007). -
File and storage services
The File And Storage Services role provides essential services for
managing files and the way they are made available and replicated on the
network. A number of server roles require some type of file service. -
Print and document services
The Print And Document Services role fulfills the needed role of
managing printer operations on the network. Windows Server 2012 enables
publishing printers in Active Directory, connecting to network printers
using a Uniform Resource Locator (URL), and enhanced printer control
through Group Policy. -
Remote Desktop Services The Remote Desktop Services role supports virtual desktops, enabling a single server
to pool virtual desktops centrally and, in this way, host network
access for many users. A client with a web browser, a Windows thin
client, or a Remote Desktop client can access the Remote Desktop server to gain access to network resources. -
Web server Web
servers host websites and web-based applications. Websites hosted on a
web server can have both static content and dynamic content. You can
build web applications hosted on a web server using ASP.NET and.NET
Framework.
Designing the Active Directory namespace
The Active Directory tree is based on a DNS
domain structure, which must be implemented prior to, or as part of,
installing the first Active Directory server in the forest. Each domain
in the Active Directory tree is both a DNS and Windows domain, with the
associated security and administrative functionality. DNS is thoroughly
integrated with Active Directory, providing location services (also
called name resolution services)
for domains, servers, sites, and services, as well as constraining the
structure of the Active Directory tree. It is wise to keep Active
Directory in mind as you are designing the DNS namespace, and vice
versa, because they are immutably linked.
Note
Active Directory trees exist within a forest, which is a collection of one or more domain trees. The first domain installed in an Active Directory forest functions as the forest root.
The interdependence of Active Directory and DNS
brings some special factors into play. For example, if your
organization has outward-facing DNS servers, you must decide whether you
will be using your external DNS name or another DNS domain name for Active
Directory. Many organizations choose not to use their external DNS name
for Active Directory, unless they want to expose the directory to the
Internet for a business reason, such as an Internet service provider
(ISP) that uses Active Directory logon servers.
Within a domain, another sort of hierarchy exists in the form of container objects called organizational units (OUs),
which are used to organize and manage users, network resources, and
security. An OU can contain related users, groups, or computers, as well
as other OUs.
Important
Designing the Active Directory namespace
requires the participation of multiple levels of business and IT
management, so be sure to provide adequate time for a comprehensive
review and sign-off on domain architecture.
Domain trusts allow automatic authentication and access to resources across domains. Active Directory automatically configures trust relationships such that each domain in an Active Directory forest trusts every other domain within that forest.
Active Directory domains are linked by a series of such transitive
trust relationships between all domains in a domain tree, and between
all domain trees in the forest. By using Windows Server 2012, you can
also configure transitive trust relationships between forests.
Identifying the domain and forest functional level
Active Directory now has multiple domain and forest functional levels, each constraining the types of domain controllers that can be in use and the available feature set.
The domain functional levels are as follows:
-
Windows Server 2003 mode
When the domain is
operating in Windows Server 2003 mode, the directory supports domain
controllers running Windows Server 2003 and later. A domain operating in
Windows Server 2003 mode can use universal groups, group nesting, group
type conversion, easy domain controller renaming, update logon time
stamps, and Kerberos KDC key version numbers. -
Windows Server 2008 mode
When the domain is
operating in Windows Server 2008 mode, the directory supports Windows
Server 2008 and later domain controllers. Windows
Server 2003 domain controllers are no longer supported. A domain
operating in Windows Server 2008 mode can use additional Active
Directory features, including the DFS replication service for enhanced
intersite and intrasite replication, and Advanced Encryption Services
(AES) 128-bit or AES 256-bit encryption for the Kerberos protocol. This
level also supports the display of the last interactive logon details
for users and fine-grained password policies for applying separate
password and account lockout policies to users and groups. -
Windows Server 2008 R2 mode
When the domain is
operating in Windows Server 2008 R2 mode, the directory supports Windows
Server 2008 R2 and later domain controllers. Windows Server 2003 and Windows
Server 2008 domain controllers are no longer supported. A domain
operating in Windows Server 2008 R2 mode can use Active Directory
Recycle Bin, managed service accounts, Authentication Mechanism
Assurance, and other important Active Directory enhancements. -
Windows Server 2012 mode When the domain is operating in Windows Server 2012 mode, the directory supports only Windows Server 2012 domain controllers. Windows Server 2003, Windows Server 2008, and Windows
Server 2008 R2 domain controllers are no longer supported. Active
Directory schema for Windows Server 2012 includes many enhancements, but
only the Kerberos with Armoring feature requires this mode.
The forest functional levels are as follows:
-
Windows Server 2003 Supports domain controllers running Windows Server 2003 and later -
Windows Server 2008 Supports domain controllers running Windows Server 2008 and later -
Windows Server 2008 R2 Supports domain controllers running Windows Server 2008 R2 and Windows Server 2012 -
Windows Server 2012
Supports domain controllers running Windows Server 2012
When a forest is operating at the Windows Server 2003 or higher
functional level, key Active Directory features, including the
following, are enabled:
-
Replication enhancements
Each changed value
of a multivalued attribute is now replicated separately—eliminating the
possibility for data conflict and reducing replication traffic.
Additional changes include enhanced global catalog replication and
application partitions (which segregate data, and thus the replication
of that data). -
Schema
Schema objects can be deactivated, and dynamic auxiliary classes are supported. -
Management Forest
trusts allow multiple forests to easily share resources. Active
Directory domains can be renamed, and thus the Active Directory tree can
be reorganized. -
User management
Last logon time is now tracked, and enhancements to InetOrgPerson password handling are enabled.
However, to take advantage of the latest Active Directory features,
your forests must operate at the Windows Server 2008 R2 or higher
function level. Selecting your domain and forest functional levels is generally a straightforward choice. Ultimately, the decision regarding the domain
and forest functional levels at which to operate mostly comes down to
choosing the one that supports the domain controllers you have in place
now and expect to have in the future. In most circumstances, you will
want to operate at the highest possible level because it enables more
functionality. Also, keep in mind that all changes to the functional
level are one-way and cannot be reversed.
Defining Active Directory server roles
In addition to serving as domain controllers, a number of domain
controllers fulfill special roles within Active Directory. Some of these
roles provide a service to the entire forest, although others are
specific to a domain or site. The Active Directory setup routine assigns
and configures these roles, although you can change them later.
The Active Directory server roles are as follows:
-
Operations masters
A number of Active
Directory operations must be carefully controlled to maintain the
integrity of the directory structure and data. A specific domain
controller serves as the operations master for each of these functions.
That server is the only one that can perform certain operations related
to that area. For example, you can make schema changes only on the domain controller serving as the schema master; if that server is unavailable, no changes can be made to the schema. There are two categories of operations masters:
-
Forest-level operations masters
The schema master manages the schema and enforces schema consistency throughout the directory.
The domain-naming master controls domain creation and deletion, guaranteeing that each domain is unique within the forest. -
Domain-level operations masters The RID master manages the pool of relative identifiers (RIDs). (A RID is a numeric string used to construct SIDs for security principals.)
The infrastructure master handles user-to-group mappings, changes in group membership, and replication of those changes to other domain controllers.
The PDC emulator
is responsible for processing password changes and replicating password
changes to other domain controllers. The PDC emulator must be available
to reset and verify external trusts.
-
Global catalogs A global catalog server provides a quick index of Active Directory objects, which is used by a variety of network clients and processes to locate directory objects. Global
catalog servers can be heavily used, yet they must be highly available
to clients, especially for user logons because the global catalog
provides membership information for universal groups. Accordingly, each
site in the network should have at least one global catalog server, or
you should have a Windows Server 2003 or later domain controller with
universal group caching enabled. -
Bridgehead servers
Bridgehead servers manage intersite replication over low-bandwidth WAN links. Each site replicating with other sites
usually has at least one bridgehead server, although a single site can
have more than one if that’s required for performance reasons.
Note
Active Directory replication depends on the concept of sites, which are defined
as a collected set of subnets with good interconnectivity. Replication
differs depending on whether it is within a site or between sites;
intrasite replication occurs automatically every 15 seconds, while
intersite replication is scheduled and usually quite a bit slower.
|
