Active Directory Domain Services Overview

42 out of 53 rated this helpful - Rate this topic

Updated: April 25, 2007
Applies To: Windows Server 2008, Windows Server 2008 R2
By using the Active Directory Domain Services (AD DS) server role, you can
create a scalable, secure, and manageable infrastructure for user and
resource management, and you can provide support for directory-enabled
applications, such as Microsoft Exchange Server.
In the following sections, learn more about AD DS, features in AD DS, and
software and hardware considerations. For more information about planning,
deploying, and operating the AD DS server role, see Active Directory Domain
Services (http://go.microsoft.com/fwlink/?LinkID=48547).
What is the AD DS server role?
AD DS provides a distributed database that stores and manages information
about network resources and application-specific data from directory-enabled
applications. Administrators can use AD DS to organize elements of a
network, such as users, computers, and other devices, into a hierarchical
containment structure. The hierarchical containment structure includes the
Active Directory forest, domains in the forest, and organizational units (OUs)
in each domain. A server that is running AD DS is called a domain controller.
Organizing network elements into a hierarchical containment structure
provides the following benefits:

The forest acts as a security boundary for an organization and defines

the scope of authority for administrators. By default, a forest contains
a single domain, which is known as the forest root domain.

Additional domains can be created in the forest to provide partitioning

of AD DS data, which enables organizations to replicate data only
where it is needed. This makes it possible for AD DS to scale globally
over a network that has limited available bandwidth. An
Active Directory domain also supports a number of other core functions
that are related to administration, including network-wide user identity,
authentication, and trust relationships.

OUs simplify the delegation of authority to facilitate the management

of large numbers of objects. Through delegation, owners can transfer
full or limited authority over objects to other users or groups.
Delegation is important because it helps to distribute the management
of large numbers of objects to a number of people who are trusted to
perform management tasks.

Features in AD DS

Security is integrated with AD DS through logon authentication and access

control to resources in the directory. With a single network logon,
administrators can manage directory data and organization throughout their
network. Authorized network users can also use a single network logon to
access resources anywhere in the network. Policy-based administration eases
the management of even the most complex network.
Additional AD DS features include the following:

A set of rules, the schema, that defines the classes of objects and
attributes that are contained in the directory, the constraints and limits
on instances of these objects, and the format of their names.

A global catalog that contains information about every object in the

directory. Users and administrators can use the global catalog to find
directory information, regardless of which domain in the directory
actually contains the data.

A query and index mechanism, so that objects and their properties can
be published and found by network users or applications.

A replication service that distributes directory data across a network.

All writable domain controllers in a domain participate in replication
and contain a complete copy of all directory information for their
domain. Any change to directory data is replicated to all domain
controllers in the domain.

Operations master roles (also known as flexible single master

operations or FSMO). Domain controllers that hold operations master
roles are designated to perform specific tasks to ensure consistency
and eliminate conflicting entries in the directory.

Identity Management for UNIX

Identity Management for UNIX is a role service of AD DS that can be installed
only on domain controllers. Two Identity Management for UNIX technologies,
Server for NIS and Password Synchronization, make it easier to integrate
computers running Microsoft Windows into your existing UNIX enterprise.
AD DS administrators can use Server for NIS to manage Network Information
Service (NIS) domains. Password Synchronization automatically synchronizes
passwords between Windows and UNIX operating systems.
New AD DS features in this version of Windows Server 2008
This version of Windows Server includes the new AD DS features that are
described in the following table.
Active Directory Administrative Center

Active Directory Administrative Center provides users and network

administrators with an improved data management experience and a rich
graphical user interface (GUI) to perform common Active Directory object
management tasks. Built on Windows PowerShell technology,
Active Directory Administrative Center makes it possible for users and
network administrators to administer directory service objects through both
data-driven navigation and task-oriented navigation.
Active Directory module for Windows PowerShell
The Active Directory module for Windows PowerShell is a command-line
interface that administrators can use to configure and diagnose all instances
of Active Directory Domain Services (AD DS) and Active Directory
Lightweight Directory Services (AD LDS) in their environments.
This feature includes a set of Windows PowerShell cmdlets and a provider.
The provider exposes the Active Directory database through a hierarchical
navigation system, which is very similar to the file system. As with drives in a
file system (C:, D:), you can connect Windows PowerShell drives to
Active Directory domains and AD LDS instances, as well as Active Directory
snapshots.
Active Directory Recycle Bin
Active Directory Recycle Bin minimizes directory service downtime by
improving the ability to preserve and restore accidentally deleted
Active Directory objects without having to restore Active Directory data from
backups, restart AD DS, or restart domain controllers. When Active Directory
Recycle Bin is enabled, all link-valued and non-link-valued attributes of the
deleted objects are preserved and the objects are restored in their entirety to
the same consistent logical state that they were in immediately before
deletion. For example, restored user accounts automatically regain all group
memberships and corresponding access rights that they had within and
across domains immediately before deletion. Active Directory Recycle Bin is
functional for both AD DS and AD LDS environments.
Active Directory Recycle Bin requires the Windows Server 2008 R2 forest
functional level, and it is disabled by default. To enable it, you can use
Ldp.exe or the Windows PowerShell Enable-ADOptionalFeature cmdle
Active Directory Web Services (ADWS)
ADWS is a Windows service that provides a Web service interface to AD DS
and AD LDS directory service instances and to Active Directory snapshots

that are running on the same Windows Server 2008 R2 server as ADWS.
ADWS is installed automatically when you add the AD DS or AD LDS server
roles to your Windows Server 2008 R2 server.
Authentication Mechanism Assurance
Authentication Mechanism Assurance packages information about the type of
logon method (smart card or user name/password) that is used to
authenticate domain users inside each users Kerberos token. When this
feature is enabled in a network environment that has deployed a federated
identity management infrastructure, such as Active Directory Federation
Services (AD FS), the information in the token can then be extracted
whenever a user attempts to access any claims-aware application that has
been developed to determine authorization based on a users logon method.
Authentication Mechanism Assurance requires the Windows Server 2008 R2
domain functional level.

Offline domain join

An offline domain join is a new process that computers running Windows 7

or Windows Server 2008 R2 can use to join a domain. The offline domain join
process can complete the domain join operation without network
connectivity.
Installing the AD DS server role
After you finish installing the operating system, you can use Initial
Configuration Tasks or Server Manager to install server roles. To install the
AD DS server role, click Add roles to start the Add Roles Wizard, and then
click Active Directory Domain Services. Follow the steps in the Add Roles
Wizard to install the files for the AD DS server role. After you complete the
Add Roles Wizard, click the link to start the Active Directory Domain Services
Installation Wizard.
Follow the steps in the Active Directory Domain Services Installation Wizard
to complete the installation and configuration of your domain controller. Most
wizard pages have a Help link for more information about the settings that
you can configure.
To automate domain controller installations, you can use an answer file or
you can specify unattended installation parameters at the command line. For
more information about installing AD DS, see the AD DS Installation and

Removal Step-by-Step Guide (http://go.microsoft.com/fwlink/?

LinkId=110897).
Managing the AD DS server role
You can manage server roles with Microsoft Management Console (MMC)
snap-ins. To manage a domain controller (that is, a server that is running
AD DS), click Start, click Control Panel, click Administrative Tools, and
then double-click the appropriate snap-in:

To manage Active Directory objects by using the newest GUI tool, with
improved options for viewing and managing Active Directory data,
click Active Directory Administrative Center.

To manage Active Directory objects by using a predefined set of

Windows PowerShell cmdlets and a provider, click Active Directory
Module for Windows PowerShell.

To manage user and computer accounts, click Active Directory Users

and Computers.

To manage Active Directory trusts, functional levels, and forest-wide

operations master roles, click Active Directory Domains and Trusts.

To manage Active Directory sites and site links, click Active Directory
Sites and Services.

As an alternative, you can double-click the appropriate snap-in on

the Active Directory Domain Services page in Server Manager.
Experienced programmers and system administrators can manage the
Active Directory schema, but the Active Directory Schema snap-in is not
installed by default. In addition, the Schmmgmt.dll file must be registered
before the snap-in can be installed.
To install the Active Directory Schema snap-in
1. Click Start, right-click Command Prompt, and then click Run as
administrator.
If the User Account Control dialog box appears, confirm that the
action it displays is what you want, and then click Yes.
2. At the command prompt, type the following command, and then press
ENTER:
regsvr32 schmmgmt.dll
3. Click OK to close the dialog box that confirms that the operation
succeeded.
4. Click Start, click Run, type mmc, and then click OK.
If the User Account Control dialog box appears, confirm that the
action it displays is what you want, and then click Yes.
5. On the File menu, click Add/Remove Snap-in.

6. Under Available snap-ins, click Active Directory Schema,

click Add, and then click OK.
7. To save this console, on the File menu, click Save.
8. In the Save As dialog box, do one of the following:
o To place the snap-in on the Administrative Tools menu, in File
name, type a name for the snap-in, and then click Save.
o To save the snap-in to a location other than the Administrative
Tools folder, in Save in, navigate to a location for the snap-in.
In File name, type a name for the snap-in, and then click Save.

Active Directory Structure

12 out of 27 rated this helpful - Rate this topic
Document your Active Directory site names and locations. Active Directory is
the directory service for Windows 2000 and Windows Server 2003 family of
products. It stores information about objects on the network. An Active
Directory site is defined as one or more well-connected TCP/IP subnets. A
well-connected TCP/IP subnet has a fast, reliable network connection.
The logical structure of your organization is represented by the following
Active Directory components:
Organizational units
Domains
Trees
Forests
The physical structure of your organization is represented by the following
Active Directory components:
Active Directory sites (physical subnets)
Domain controllers
When planning your SMS hierarchy design, consider your Active Directory
logical layout (hierarchical forest arrangement and domain structure), and its
physical structure (Active Directory site topology). Later, when planning your
SMS deployment and configuration, become familiar with the more granular
details of the logical structure, such as organizational units, because these
can help determine how you organize collections, distribute software, and
perform queries in SMS.
Document your physical Active Directory structure and domain structure
before you begin the planning phase. You might also include a diagram
similar to that in Figure 7.3 if your environment includes mixed-mode
domains.

Figure 7.3 Sample Active Directory structure depicting domain

modes and operating systems

Domain Controller Roles

A domain controller is a server that is running a version of the Windows Server operating
system and has Active Directory Domain Services installed. When you install
Windows Server on a computer, you can choose to configure a specific server role for that
computer. When you want to create a new forest, a new domain, or an additional domain
controller in an existing domain, you configure the server with the role of domain controller
by installing AD DS.

By default, a domain controller stores one domain directory partition consisting of

information about the domain in which it is located, plus the schema and configuration
directory partitions for the entire forest. A domain controller that runs Windows
Server 2008 R2, Windows Server 2008, or Windows Server 2003 can also store one or more
application directory partitions. There are also specialized domain controller roles that
perform specific functions in an AD DS environment. These specialized roles include global
catalog servers and operations masters.

The role of the global

catalog
A global catalog is a domain controller that stores a copy of all Active Directory objects in a
forest. The global catalog stores a full copy of all objects in the directory for its host domain
and a partial copy of all objects for all other domains in the forest, as shown in the following
figure.

The partial copies of all domain objects included in the global catalog are those most
commonly used in user search operations. These attributes are marked for inclusion in the
global catalog as part of their schema definition. Storing the most commonly searched upon
attributes of all domain objects in the global catalog provides users with efficient searches
without affecting network performance with unnecessary referrals to domain controllers.

You can manually add or remove other object attributes to the global catalog by using the
Active Directory Schema snap-in. For more information, see Customizing the global catalog.
A global catalog is created automatically on the initial domain controller in the forest. You
can add global catalog functionality to other domain controllers or change the default
location of the global catalog to another domain controller. For more information, see Enable
or disable a global catalog.
A global catalog performs the following directory roles:

Finds objects
A global catalog enables user searches for directory information throughout all
domains in a forest, regardless of where the data is stored. Searches within a forest
are performed with maximum speed and minimum network traffic.
When you search for people or printers from the Start menu or choose the Entire
Directory option within a query, you are searching a global catalog. Once you enter
your search request, it is routed to the default global catalog port 3268 and sent to a
global catalog for resolution. For more information, see Finding directory
information and "Finding information in Active Directory" at the Microsoft Windows
Resource Kits Web site.

Supplies user principal name authentication

A global catalog resolves user principal names (UPNs) when the authenticating
domain controller does not have knowledge of the account. For example, if a users
account is located in example1.microsoft.com and the user decides to log on with a
user principal name of user1@example1.microsoft.com from a computer located in
example2.microsoft.com, the domain controller in example2.microsoft.com will be
unable to find the users account, and will then contact a global catalog to complete
the logon process. For more information, see Active Directory naming.

Supplies universal group membership information in a multiple domain

environment
Unlike global group memberships, which are stored in each domain, universal group
memberships are only stored in a global catalog. For example, when a user who
belongs to a universal group logs on to a domain that is set to the Windows 2000
native domain functional level or higher, the global catalog provides universal group
membership information for the users account at the time the user logs on to the
domain.
If a global catalog is not available when a user logs on to a domain set to the
functional level of Windows 2000 native or higher, the computer will use cached
credentials to log on the user if the user has logged on to the domain previously. If
the user has not logged on to the domain previously, the user can only log on to the
local computer. However, if a user logs on as the Administrator in the domain (Builtin
Administrator account), the user can always log on to the domain, even when a
global catalog is not available.

For more information about universal groups, see Group scope. For more information
about universal groups and replication, see Global catalog replication and Global
catalogs and sites.
Note
o

When there is only one domain in a forest, it is not necessary for users to
obtain universal group memberships from a global catalog when logging on.
This is because Active Directory can detect that there are no other domains in
the forest and will prevent a query to the global catalog for this information.

Validates object references within a forest

A global catalog is used by domain controllers to validate references to objects of
other domains in the forest. When a domain controller holds a directory object with
an attribute containing a reference to an object in another domain, this reference is
validated using a global catalog.

What Are Domains?

Domains are logical directory components that you create to manage the administrative
requirements of your organization. The logical structure is based on the administrative
requirements of an organization, such as the delegation of administrative authority, and
operational requirements, such as the need to control replication. In general, domains are
used to control where in the forest replication of domain data occurs and organizational units
are used to further organize network objects into a logical hierarchy and delegate control to
appropriate administrative support personnel.
A domain is a partition in an Active Directory forest. Partitioning data enables organizations
to replicate data only to where it is needed. In this way, the directory can scale globally over
a network that has limited available bandwidth. Domains can also be defined as:

Containers within a forest

Units of Policy

Units of Replication

Authentication and Authorization Boundaries

Units of Trust

Each domain has a domain administrators group. Domain administrators have full control
over every object in the domain. These administrative rights are valid within the domain
only and do not propagate to other domains.

Domains as Containers Within a Forest

Within the scope of a forest, a domain is a container. Objects in that container inherently
trust each other and the security services located in that same container. Each time you
create a new domain container in a forest, a two-way, transitive trust relationship is
automatically created between the new domain and its parent domain. Trusts are logical
relationships established between domains to allow pass-through authentication in which a
trusting domain honors the logon authentications of a trusted domain. Because all domain
containers within a forest are joined together by two-way transitive trusts, objects within one
domain container also inherently trust all other objects and security services located in
every domain container located in that forest.
Domain containers are used to store and manage Active Directory objects, some of which
have a physical representation. All of the objects within the domain container are stored in a
central database that stores only objects created within that domain. Some objects
represent people or groups of people, while others represent computers or network servers.
Examples of Active Directory objects that have a physical representation are user, computer,
and group objects.
While domains contain objects that represent physical things, they also contain objects that
are used to help self-regulate domain operations such as trusted domain objects (TDOs) and
site link objects. Domain containers can also hold subordinate containers such as
organizational units. The following figure shows where objects are stored within the logical
structure of a domain.
Domain Containment Structure Within a Forest

Organizational Units and Objects

Organizational units are used to group objects, including accounts and resources in a
domain, for administrative purposes, such as the application of Group Policy or delegation of
authority. Control over an organizational unit, including the objects within it, is determined
by the access control lists (ACLs) on the organizational unit and on the objects in the
organizational unit.

Organizational Units
The organizational unit is a particularly useful type of directory object contained within
domains. Each organizational unit is an Active Directory container within a domain into
which users, groups, computers, and other organizational units of the domain can be placed.
An organizational unit cannot contain objects from other domains.
An organizational unit is the smallest scope or unit to which Group Policy settings can be
assigned or to which administrative authority can be delegated. A hierarchy of
organizational units can be extended as necessary to model the hierarchy of an organization
within a domain. The administrative model of the organizational unit can be scaled to any
size. For more information about Group Policy, see How Core Group Policy Works.
Administrative authority can be delegated for individual organizational units or for multiple
organizational units. Organizational units can be nested to create a hierarchy within a
domain and form logical administrative units for users, groups, and resource objects, such as
printers, computers, applications, and file shares. The organizational unit hierarchy within a
domain is independent of the structure of other domains: Each domain can implement its
own hierarchy. Likewise, domains that are managed by the central authority can implement
similar organizational unit hierarchies. The structure is flexible, which allows organizations to
create an environment that mirrors the administrative model, whether it is centralized or
decentralized.

Objects
Active Directory objects represent the physical entities that make up a network. An object
stores an instance of a class. A class is defined in the Active Directory schema as a specific
set of mandatory and optional attributes that is, an attribute can be present in an object
in Active Directory only when that attribute is permitted by the objects class. Classes also
contain rules that determine which classes of objects can be superior to (parents of) a
particular object of the class. Each attribute is also defined in the directory schema. The
attribute definitions determine the syntax for the values the attribute can have.
Creation of an Active Directory object requires specification of values for the attributes of the
object in its particular class, consistent with the rules of the directory schema. For example,
creating a user object requires specification of alphanumeric values for the users first and
last names and the logon identifier, which are mandatory according to the directory schema.
Other non-mandatory values can also be specified, such as telephone number and address.

Applications that create or modify objects in Active Directory use the directory schema to
determine what attributes the object must and might have, and what those attributes can
look like in terms of data structures and syntax constraints. The directory schema is
maintained forest-wide so that all objects created in the directory conform to the same
values.
Objects are either container objects or leaf objects. A container object stores other objects,
and as such occupies a specific level in a subtree hierarchy. An object class is a container if
at least one other class specifies it as a possible superior, so any object class defined in the
schema can become a container. A leaf object does not store other objects, so it occupies
the endpoint of a subtree. For more information about Active Directory Objects, see How
Domains and Forests Work and How the Active Directory Schema Works.

Domains as Units of Policy

A domain defines a scope or unit of policy within a forest. Some policy settings apply only to
the scope of a domain, that is, the policy settings are domain-wide. Account policies, for
example, apply uniformly to all user accounts in the domain. Although a domain is not the
smallest unit of policy that can be assigned (policies can be assigned to organizational units)
it is the most commonly used unit when splitting administrative duties between departments
and subsidiaries located in different geographical locations. As shown in the following figure,
you might need to create multiple domains to provide for policy variance among domains
throughout a forest. A domain is also considered a unit of access control, in that it can be
used for business groups requiring general autonomy.
Delegation of Domains to Domain Admins that Require Different Policies or
Autonomy

You cannot define different account policies for different organizational units in the same
domain. Policy settings are stored as Group Policy objects (GPOs) in Active Directory. A GPO
establishes how domain resources can be accessed, configured, and used. The policies
associated with a GPO are applied only within the domain and not across domains. A GPO
can be associated with one or more Active Directory containers, such as a site, domain, or
organizational unit.
Account policies and Public Key policies have domain-wide scope and are set at the domain
GPO level. All other policies can be specified at the level of the organizational unit. Some
policies that can be applied only at the domain container level include:

Password policy. Determines the rules, such as password length, that must be met
when a user sets a password.

Account lockout policy. Defines rules for intruder detection and account deactivation.

Kerberosticket policy. Determines the lifetime of a Kerberos ticket. A Kerberos ticket is

obtained during the logon process and is used for network authentication. A
particular ticket is only valid for the lifetime specified in the policy.

Because organizational units provide multiple levels of administrative authority, you can use
them to systematically apply Group Policy settings and delegate administrative control.

Delegation simplifies the task of managing these objects and enables you to structure Active
Directory to fit the requirements of your organization. Using delegated authority in
conjunction with GPOs and group memberships allows one or more administrators to be
assigned rights and permissions to manage objects in an entire domain or in one or more
organizational units within the domain.
For more information about Group Policy, see How Core Group Policy Works.

Domains as Units of Replication

The physical significance of a domain is that it is a unit of replication. In fact, with the
exception of application partitions, which replicate only non-security principal objects, the
domain is the smallest unit of replication that can be administered within an Active Directory
forest. This is because all objects that are located within a domain container, also referred to
as domain data, are replicated to other domain controllers within that same domain,
regardless of whether those domain controllers are located over a local area network (LAN)
or wide area network (WAN) connection.
As shown in the following figure, Active Directory multi-master replication manages the
transfer of domain objects to the appropriate domain controllers automatically, keeping
domain data up-to-date among all domain controllers in the domain, regardless of location.
Replication of Domain Data Within Each Domain in the Forest

All domain controllers in the forest are also updated with changes to forest-wide data. For
more information about replication at the Forest level, see Forests as Units of Replication
later in this section Domain-wide replication relies on three components of the Active
Directory physical structure to be in place for optimal performance, these include:

Domain Controllers
The physical domain controller contains the domain partition data that is replicated to other
domain controllers in that same domain. A domain partition stores only the information
about objects located in that domain. All domain controllers in a domain receive changes
and replicate those changes to the domain partition stored on all other domain controllers in
the domain. In this way, all domain controllers are peers in the domain and manage
replication as a unit.

Domain controllers also have two non-domain directory partitions that store forest-wide
data, which includes the directory schema and configuration data. Optionally, domain
controllers, application partitions can be configured to be located on designated domain
controllers anywhere in a forest. Unlike the schema and configuration partitions, application
partitions are not located on every domain controller in a forest. For more information about
the replication of forest-wide data, see Forests as Units of Replication later in this section.
Partitioning Active Directory data into three physical partitions on each domain controller
helps to control replication so that data is replicated only to where it is needed. In this way,
Active Directory can scale globally over a network that has limited available bandwidth.

Sites
Within the scope of a forest, sites are a representation of the physical network topology. This
includes physical subnet and site definitions. Replication of updates to domain data occurs
between multiple domain controllers to keep replicas synchronized. Multiple domains are
common in large organizations, as are multiple sites in disparate locations. In addition,
domain controllers for the same domain are commonly placed in more than one site.
Therefore, replication must often occur both within sites and between sites to keep domain
and forest data consistent among domain controllers that store the same directory
partitions. Replication within sites generally occurs at typical LAN speeds between domain
controllers that are on the same network segment. Replication between sites usually occurs
over WAN links that might be costly in terms of bandwidth. To accommodate the differences
in distance and cost of replication within a site and between sites, the intrasite replication
topology is used to optimize speed, and the intersite replication topology is used to minimize
cost based on a configurable replication schedule.
The Knowledge Consistency Checker (KCC) is a distributed application that runs on every
domain controller and is responsible for creating the connections between domain
controllers that collectively form the replication topology. The KCC uses Active Directory data
to determine where to create connections between source domain controllers and
destination domain controllers.
Intersite replication is optimized for bandwidth efficiency, and directory updates between
sites occur automatically based on a configurable schedule.

Domain-Wide Operations Masters

Active Directory supports multi-master replication of the directory data store between all
domain controllers in the domain. However, some changes are impractical to perform in
multi-master fashion, so only a single domain controller, called the operations master,
accepts requests for such changes. Because these roles can be transferred to other domain
controllers within the domain or forest, they are sometimes referred to as operations master
roles.

There are three operations master roles per domain. These include the Relative Identifier
(RID) Master, Primary Domain Controller (PDC) emulator, and Infrastructure Master. These
three roles must be unique in each domain, so each domain can have only one RID master,
one PDC emulator, and one Infrastructure Master. For information about forest-wide roles,
see Forest-Wide Operations Master Roles later in this section. For more information about
replication, see How Active Directory Replication Topology Works.

Domains as Authentication and Authorization Boundaries

By default, a domain provides authentication and authorization services for all its accounts
in order to facilitate logons and single sign-on access control to shared resources within the
boundaries of the domain. The process of authentication ensures that users are who they
claim to be. Once identified, the user can be authorized access to a specific set of network
resources based on permissions.Authorization takes place through the mechanism of access
control, using access control lists (ACLs) that define permissions on file systems, network file
and print shares, and entries in Active Directory.
Authorization is determined not only by the identity of the user but also the membership of
the user in one or more security groups. In fact, the preferred method of controlling domainwide resources is to grant access to groups rather than to individuals, adjusting the level of
authorization for a group according to the needs of its members. This method of controlling
access makes it easier to keep ACLs up-to-date on domains that have thousands of users
and objects. Group membership can be managed centrally by anyone with the appropriate
administrative credentials. You can change the level of authorization a particular user has to
many resources simply by adding or removing the user from a group. The following figure
shows when authentication and authorization for a user in a given domain occur.
Authentication and Authorization of a User Within the Same Domain

Authentication is not limited to users. Computers and services are also authenticated when
they make network connections to other servers. For example, domain joined computers
connect Active Directory in their domain for policy information during startup. Computers
and services also prove their identity to clients that request mutual authentication. Mutual
authentication prevents an intruder from adding another computer as an imposter between
the client and the real network server. The Kerberos version 5 authentication protocol is a
technology for single sign-on to network resources. Kerberos V5 protocol is used to provide
single sign-on to network services within a domain, and to services residing in trusted
domains. The Kerberos V5 protocol verifies both the identity of the user and of the network
services, providing mutual authentication.
Authentication and authorization services in one domain can be extended to accounts that
are located in trusted domains. This can be done by using trusts. Trusts are logical
relationships established between domains to allow pass-through authentication in which a
trusting domain honors the logon authentications of a trusted domain. Consequently, trust
relationships inherently allow domain-specific authentication and authorization services to
be extended, thereby enabling single sign-on access control capabilities throughout a forest.
Because the domain trust relationships between all domains in the forest are bidirectional by
default, authentication in one domain is sufficient for referral or pass-through authentication
to resources in other domains in the forest.

Domains as Units of Trust

A domain is the smallest container within Active Directory that can be used in a trust
relationship. All domains within a forest are connected by Kerberos-based trusts. Kerberosbased trusts are two-way and transitive in nature. Trusts act as authentication pipelines that
must be present in order for users in one domain to access resources in another domain. All
authentication requests made between domains located inside or outside of a forest must
occur over trusts. Trust relationships within a forest are created as implicit two-way
transitive trusts.
Note

Access to resources in any discussion of trust relationships always assumes the

limitations of access control.

Within a forest, trust relationships are automatically created between the forest root domain
and any tree root domains on the one hand, and all child domains that are subordinate to
the forest root domain on the other. Because trust relationships are two-way and transitive
by default, users and computers can be authenticated between any domain containers in
the forest, as shown in the following figure.
Domains as Units of Trust and the Authentication Paths they Provide

In accordance with DNS naming standards, Active Directory domains within a single forest
are created in an inverted tree structure, with the forest root domain at the top. This tree
structure requires that trusts exist between domains to facilitate security of
communications. Adding a domain tree to a forest requires specification of the forest root
domain, which results in the establishment of a trust relationship between the root domain
of the new tree and the forest root domain. For more information about trusts and root
domains, see Forests as Collections of Domain Containers that Trust Each Other later in
this section.

What Domains Are Not

Domains are not security boundaries within the scope of Active Directory and do not provide
complete isolation in the face of possible attacks by malicious service administrators who
might manage that forest. This is because a malicious service administrator, such as a
member of the Domain Admins group, can use nonstandard tools and procedures to gain full
access to any domain in the forest or to any computer in the forest. For example, service

administrators in a non-root domain can make themselves members of the Enterprise

Admins or Schema Admins group.
However, administrative rights do not flow across domain boundaries, nor do they flow down
through a domain tree. For example, if you have a domain tree with domains A, B, and C,
where A is the parent domain of B and B is the parent domain of C, users with administrative
rights in domain A do not have administrative rights in B, nor do users with administrative
rights in domain B have administrative rights in domain C. For a user to obtain
administrative rights in a given domain, a higher authority must grant them. This does not
mean, however, that an administrator cannot have administrative rights in multiple
domains; it simply means that all rights must be explicitly defined.
For more information about isolation, see Forests as Security Boundaries later in this
section.

What Are Forests?

At its highest level, a forest is a single instance of Active Directory. Therefore, a forest is
synonymous with Active Directory, meaning that the set of all directory partitions in a
particular Active Directory instance (which includes all domain, configuration, schema and
optional application information) makes up a forest. This means that when you have multiple
forests in an enterprise they will, by default, act separately from each other as if they were
the only directory service in your organization.
This behavior, however, is easily be modified so that multiple forests can share Active
Directory responsibilities across an enterprise. This is done by creating external or forest
trust relationships between the forests. In this way, each forest can be connected with every
other forest to form a collaborative directory service solution for any enterprise with
business needs that include multiple forest collaboration.
Forests can also be defined as:

Collections of Domain Containers that Trust Each Other

Units of Replication

Security Boundaries

Units of Delegation

Forests as Collections of Domain Containers that Trust Each Other

Within the scope of Active Directory, a forest is a collection of domain containers that
inherently trust each other and other security services that are located in that same forest.

All domain containers in a forest share a common global catalog, directory schema, and
directory configuration, as well as automatic two-way transitive trust relationships. Because
all of the domain containers are inherently joined through two-way transitive trusts, all
authentication requests made from any domain in the forest to any other domain in the
same forest will be granted. In this way, all security principals that are located in domain
containers within a forest inherently trust each other.
Forests can be used to segregate domain containers into one or more unique DNS
namespace hierarchies known as domain trees. Although each domain tree consists of a
unique namespace the schema and configuration data for the forest are shared throughout
all the domain containers in a forest irrespective of namespace. Each domain container in a
forest must adhere to DNS naming schemes and all domains are organized in a root and
subordinate domain hierarchy. Root domains, such as forest root and tree root domains,
define the DNS namespace for their subordinate domains. Although a forest can consist of
multiple domain trees, it represents one organization. However, an organization can have
multiple forests. For more information about multiple forests, see Forests as Units of
Delegation later in this section. As shown in the following figure, the namespace for each
root domain must be unique.
Domain Containers, Root Domains and DNS Namespaces Within a Forest

Forest Root Domain

Although trees in a forest do not share the same DNS namespace, a forest does have a
single root domain, called the forest root domain. The forest root domain is, by definition,
the first domain created in the forest. The Enterprise Admins and Schema Admins groups are
located in this domain. By default, members of these two groups have forest-wide
administrative credentials. In Windows 2000 Active Directory, the forest root domain cannot
be deleted, changed, or renamed. In Windows Server 2003 and later versions of Active
Directory, the forest root domain cannot be deleted, but it can be restructured or renamed.
Objects are located within Active Directory domains according to a hierarchical path, which
includes the labels of the Active Directory domain name and each level of container objects.
The full path to the object is defined by the distinguished name (also known as a DN). The
distinguished name is unambiguous (identifies one object only) and unique (no other object
in the directory has this name). By using the full path to an object, including the object name
and all parent objects to the root of the domain, the distinguished name uniquely and
unambiguously identifies an object within a domain hierarchy.
The distinguished name of the forest root domain is used to locate the configuration and
schema directory partitions in the namespace. The distinguished names for the
Configuration and Schema containers in Active Directory always show these containers as
child objects in the forest root domain. For example, in the child domain
Noam.wingtiptoys.com (where Wingtiptoys.com is the name of the forest root domain), the
distinguished name of the Configuration container is
cn=configuration,dc=wingtiptoys,dc=com. The distinguished name of the Schema container
is cn=schema,cn=configuration,dc=wingtiptoys,dc=com. However, this naming convention
provides only a logical location for these containers.
These containers do not exist as child objects of the forest root domain, nor is the schema
directory partition actually a part of the configuration directory partition: They are separate
directory partitions. Every domain controller in a forest stores a copy of the configuration
and schema directory partitions, and every copy of these partitions has the same
distinguished name on every domain controller.

Tree Root Domain

A domain tree represents a unique DNS namespace: it has a single root domain, known as
the tree root domain, and is built as a strict hierarchy: Each domain above the tree root
domain has exactly one superior, or parent, domain (the forest root domain). The
namespace created by this hierarchy, therefore, is contiguous each level of the hierarchy
is directly related to the level above it and to the level below it. In other words, the names of
domains created beneath the tree root domain (child domains) are always contiguous with
the name of the tree root domain. The DNS names of the child domains of the root domain
of a tree reflect this organization; therefore, the children of a root domain called
Somedomain are always children of that domain in the DNS namespace (for example,
Child1.somedomain, Child2.somedomain, and so forth).

Multiple domain trees can belong to a single forest and do not form a contiguous
namespace; that is, they have noncontiguous DNS domain names. Although the roots of the
separate trees have names that are not contiguous with each other, the trees share a single
overall namespace because names of objects can still be resolved by the same Active
Directory instance. A forest exists as a set of cross-reference objects and trust relationships
that are known to the member trees. Transitive trusts at the root domain of each namespace
provide mutual access to resources.
The domain hierarchy in a forest determines the transitive trust links that connect each
domain. Each domain has a direct trust link with its parent and each of its children. If there
are multiple trees in a forest, the forest root domain is at the top of the trust tree and, from a
trust perspective, all other tree roots are children. That means authentication traffic between
any two domains in different trees must pass through the forest root.

Forests as Units of Replication

Unlike domains, forests are the largest unit of replication that can be administered in an
Active Directory environment. To efficiently synchronize data between domain controllers
throughout a forest, Active Directory replication transfers updates according to directory
partition. Directory partitions are used to help organize how replication occurs within a
forest. Active Directory uses four distinct directory partition types to store and copy four
different types of data.
One directory partition contains domain data; the other three are forest-wide partitions, and
contain configuration, schema, and application data. This storage and replication design
provides directory information to users and administrators throughout the domain. Each
domain controller receives directory updates to the data stored in its domain only, as well as
updates to the data in the two directory partitions that store configuration and schema data
for the forest. As shown in the following figure, schema and configuration data must be
replicated to all domain controllers that exist in a forest, while optional Application data is
replicated only to domain controllers within the same forest that are specified as replication
partners.
Forest-Wide Replication Scope

The following table describes each of the three forest-wide partitions in more detail.
Forest-Wide Directory Partitions

Partition

Description

Schema

The schema partition contains the forest-wide schema. Each forest has one schema so that the d
all object and attribute data that can be stored in the directory. Active Directory domain control
computer accounts, groups, domains, organization units, and security policies. Administrators a
attributes or by adding new attributes for existing objects. Schema objects are protected by acce
schema partition is replicated to each domain controller in the forest.

Configuratio
n

The configuration partition describes the topology of the forest as well as other forest, domain a
domains, trees, and forests and the locations of the domain controllers and global catalogs. The

Application

Applications and services can use application directory partitions to store application-specific d
where information needs to be replicated but not necessarily on a global scale. Application dire
Application directory partitions are usually created by the applications that will use them to sto
that, for redundancy, availability, or fault tolerance, the data in it can be replicated to different d
controller or any set of domain controllers anywhere in the forest. This differs from a domain d
domain.

Only domain controllers running Windows Server 2003 or higher can host a replica of an applic
and managed by the administrator.

All forest replication is Multi-Master with the exception of the three domain-wide and two
forest-wide operations master roles. Forest-wide replication requires domain controllers and
three other components of the Active Directory physical structure to be in place for optimal
performance. These components are forest-wide operations master roles, sites, and global
catalogs.

Forest-Wide Operations Master Roles

There are two operations master roles assigned for the entire forest. These include the
domain naming master and the schema master. Each forest must have one and only one
schema master and one domain naming master, so these two roles must remain in the
forest root domain. The other three operations master roles are assigned to each domain in
the forest. These three roles must be unique in each domain, so each domain can have only
one relative ID master, one PDC emulator, and one infrastructure master.
In an Active Directory forest with only one domain and one domain controller, that domain
controller has all the operations master roles. For more information about operations master
roles, see How Operations Masters Work.

Sites
Sites in Active Directory represent the physical structure, or topology, of the network. Within
the scope of a forest, sites are a representation of the physical network topology, including
physical subnet and site definitions. When you establish sites, domain controllers within a
single site communicate frequently. This communication minimizes the latency within the
site; that is, the time required for a change that is made on one domain controller to be
replicated to other domain controllers. You create sites to optimize use of the bandwidth
between domain controllers in different locations. For more information about sites, see
How Active Directory Replication Topology Works.

Global Catalogs
The global catalog stores a full copy of all Active Directory objects in the directory for its host
domain and a partial copy of all objects for all other domains in the forest. Users in a forest
do not need to be aware of directory structure because all users see a single directory
through the global catalog. Applications and clients can query the global catalog to locate
any object in a forest. The global catalog is hosted on one or more domain controllers in the
forest. It contains a partial replica of every domain directory partition in the forest. These
partial replicas include replicas of every object in the forest, including the attributes most
frequently used in search operations and the attributes required to locate a full replica of the
object. A global catalog is created automatically on the first domain controller in the forest.
Optionally, other domain controllers can be configured to serve as global catalogs.
A global catalog serves the following roles:

Enables user searches for directory information about objects throughout all domains
in the forest

Resolves user principal names (UPNs) during authentication, when the authenticating
domain controller does not have information about the account

Supplies universal group membership information in a multiple domain environment

Validates references to objects in other domains in the forest

For more information about global catalogs and their roles, see How the Global Catalog
Works.

Forests as Security Boundaries

Each forest is a single instance of the directory, the top-level Active Directory container, and
a security boundary for all objects that are located in the forest. This security boundary
defines the scope of authority of the administrators. In general, a security boundary is
defined by the top-level container for which no administrator external to the container can
take control away from administrators within the container. As shown in the following figure,

no administrators from outside a forest can control access to information inside the forest
unless first given permission to do so by the administrators within the forest.
Enterprise Administrators Outside of a Forest Can Administer Only Within Their
Own Forest

A forest is the only component of the Active Directory logical structure that is a security
boundary. By contrast, a domain is not a security boundary because it is not possible for
administrators from one domain to prevent a malicious administrator from another domain
within the forest from accessing data in their domain. A domain is, however, the
administrative boundary for managing objects, such as users, groups, and computers. In
addition, each domain has its own individual security policies and trust relationships with
other domains.

Forests as Units of Delegation

The forest is the largest management unit of Active Directory as well as the ultimate unit of
autonomy and isolation of authority. Members of the Enterprise Admins and forest root
Domain Admins security groups are known as enterprise administrators. Enterprise
administrators control the Active Directory objects in the configuration container that do not
belong to any one domain, including Enterprise Certification Authority objects and other
configuration data that affects all domains in the forest.
Because enterprise administrators have authority over all domains in the forest, the domain
administrators in each domain must trust the enterprise administrators. You cannot truly
restrict enterprise administrators from managing objects in any domain in the forest.
Enterprise administrators can always regain control over objects. Some organizations with
political challenges, such as those frequently encountered in mergers and acquisitions,
might find the scope of this enterprise authority too great and require more than one forest.

If your organization requires strict isolation of authority between domains, you must deploy
multiple forests with manually created trusts between domains in the different forests.
Because each forest is administered separately, adding additional forests to your
organization increases the management overhead of the organization. The number of forests
that you need to deploy is based on the autonomy and isolation requirements of each group
within your organization. Reasons to create multiple forests in your organization include:

To secure data within each forest. Sensitive data can be protected so that only users
within that forest can access it.

To isolate directory replication within each forest. Schema changes, configuration

changes, and the addition of new domains to a forest have forest-wide impact only
within that forest, not on a trusting forest.

Because the forest is a security boundary, each forest does not trust or allow access from
any other forest by default. However, in Windows Server 2003 and higher Active Directory,
transitive trust relationships can be manually established between forests to establish crossforest access to resources, so that users in one forest can access resources in another forest.
Forest trusts help you to manage a segmented Active Directory infrastructure within your
organization by providing support for accessing resources and other objects across multiple
forests. By using forest trusts, you can link two different Windows Server 2003 or higher
forests to form a one-way or two-way transitive trust relationship. A forest trust allows
administrators to federate two Active Directory forests with a single trust relationship to
provide a seamless authentication and authorization experience across the forests.
When two forests are connected by a forest trust, authentication requests made using the
Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources
in both forests. Trust security settings and firewalls can be configured between domains in
different forests that are joined by trust relationships to limit cross-forest connectivity to
specific users or applications. For more information about trust security settings, see
Security Considerations for Trusts.
A forest trust can be created only between a forest root domain in one Windows Server 2003
or higher forest and a forest root domain in another Windows Server 2003 or higher forest.
Forest trusts can be created between two forests only and cannot be implicitly extended to a
third forest. This means that if a forest trust is created between Forest 1 and Forest 2, and
another forest trust is created between Forest 2 and Forest 3, Forest 1 does not have an
implicit trust with Forest 3. The following figure shows two separate forest trust relationships
between three forests in a single organization.
Two Forest Trusts Between Three Windows Server 2003 Forests

Organizational units
A particularly useful type of directory object contained within domains is the organizational
unit. Organizational units are Active Directory containers into which you can place users,
groups, computers, and other organizational units. An organizational unit cannot contain
objects from other domains.
An organizational unit is the smallest scope or unit to which you can assign Group Policy
settings or delegate administrative authority. Using organizational units, you can create
containers within a domain that represent the hierarchical, logical structures within your
organization. You can then manage the configuration and use of accounts and resources
based on your organizational model. For more information about Group Policy settings,
see Group Policy (pre-GPMC).

As shown in the figure, organizational units can contain other organizational units. A
hierarchy of containers can be extended as necessary to model your organization's
hierarchy within a domain. Using organizational units will help you minimize the number of
domains required for your network.
You can use organizational units to create an administrative model that can be scaled to any
size. A user can have administrative authority for all organizational units in a domain or for a
single organizational unit. An administrator of an organizational unit does not need to have

administrative authority for any other organizational units in the domain. For more
information about delegating administrative authority, see Delegating administration.

Group Policy definition

Group Policy is a hierarchical infrastructure that allows a network administrator
in charge of Microsoft's Active Directory to implement specific configurations
for users and computers. Group Policy can also be used to define
user, security and networking policies at the machine level. Group Policy
allows administrators to define options for what users can do on a network
including what files, folders and applications they can access. The collections
of user and computer settings are referred to as Group Policy Objects (GPOs),
which are administered from a central interface called the Group Policy
Management Console. Group Policy can also be managed with command-line
tools such as gpresult and gpupdate. In Windows Server 2008, setting
extensions known as Group Policy preferences were added to provide
administrators with better targeting and flexibility.

Fsmo roles

Operations master roles

162 out of 180 rated this helpful - Rate this topic
Updated: October 24, 2011
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1,
Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

Operations master roles

Active Directory supports multimaster replication of the directory data store between all
domain controllers (DC) in the domain, so all domain controllers in a domain are essentially

peers. However, some changes are impractical to perform in using multimaster replication,
so, for each of these types of changes, one domain controller, called the operations master,
accepts requests for such changes.
In every forest, there are at least five operations master roles that are assigned to one or
more domain controllers. Forest-wide operations master roles must appear only once in
every forest. Domain-wide operations master roles must appear once in every domain in the
forest.
Note

The operations master roles are sometimes called flexible single master operations
(FSMO) roles.

Forest-wide operations master roles

Every forest must have the following roles:

Schema master

Domain naming master

These roles must be unique in the forest. This means that throughout the entire forest there
can be only one schema master and one domain naming master.

Schema master

The schema master domain controller controls all updates and modifications to the schema.
To update the schema of a forest, you must have access to the schema master. There can be
only one schema master in the entire forest.

Domain naming master

The domain controller holding the domain naming master role controls the addition or
removal of domains in the forest. There can be only one domain naming master in the entire
forest.
Note

Any domain controller running Windows Server 2003 can hold the role of the domain
naming master. A domain controller running Windows 2000 Server that holds the role
of domain naming master must also be enabled as a global catalog server.

Domain-wide operations master roles

Every domain in the forest must have the following roles:

Relative ID (RID) master

Primary domain controller (PDC) emulator master

Infrastructure master

These roles must be unique in each domain. This means that each domain in the forest can
have only one RID master, PDC emulator master, and infrastructure master.

RID master
The RID master allocates sequences of relative IDs (RIDs) to each of the various domain
controllers in its domain. At any time, there can be only one domain controller acting as the
RID master in each domain in the forest.
Whenever a domain controller creates a user, group, or computer object, it assigns the
object a unique security ID (SID). The SID consists of a domain SID, which is the same for all
SIDs created in the domain, and a RID, which is unique for each SID created in the domain.
To move an object between domains (using Movetree.exe), you must initiate the move on
the domain controller acting as the RID master of the domain that currently contains the
object.

PDC emulator master

The PDC emulator master processes password changes from client computers and replicates
these updates to all domain controllers throughout the domain. At any time, there can be
only one domain controller acting as the PDC emulator master in each domain in the forest.
The PDC emulator role is used in the following ways:

To provide consistent password experience for users across sites (can be turned off
with AvoidPdcOnWan registry parameter) - The PDC emulator is used as a reference
DC to double-check incorrect passwords and it also receives new password changes.
When the PDC is reachable, users can use a new password immediately and
consistently across the environment. For more information about AvoidPdcOnWan
see, New Password Change and Conflict Resolution Functionality in
Windows (http://go.microsoft.com/fwlink/?LinkId=202451)

As a preferred point of administration for services (examples are Group Policy and
Distributed File System, DFS) - For more information about DFS see, DFS
Management (http://go.microsoft.com/fwlink/?LinkId=202456). For more information
about DCs and Group Policy see, Specifying a Domain Controller for Editing Group
Policy (http://go.microsoft.com/fwlink/?LinkId=202457).

As a point of contact for applications hard-coded to the PDC (often written for
Windows NT 4.0 and older domains) - The legacy API often used for this is
NetGetDcName. It is strongly suggested to change applications to use the new API to
locate DCs. DsGetDcName by default does not target the PDC, and has more options
that allows you to pick the type of DC needed to perform the operation. For more
information about locating DCs from applications see, DSGetDcName
Function (http://go.microsoft.com/fwlink/?LinkId=202455).

As a default time server for all other DCs in the domain - The time server
configuration of a PDC requires manual consideration and should be reviewed when
you change the owner of the PDC role.

The domain controller configured with the PDC emulator role supports two authentication
protocols:

The Kerberos V5 protocol

The NTLM protocol

Infrastructure master
At any time, there can be only one domain controller acting as the infrastructure master in
each domain. The infrastructure master is responsible for updating references from objects
in its domain to objects in other domains. The infrastructure master compares its data with
that of a global catalog. Global catalogs receive regular updates for objects in all domains
through replication, so the global catalog data will always be up to date. If the infrastructure
master finds data that is out of date, it requests the updated data from a global catalog. The
infrastructure master then replicates that updated data to the other domain controllers in
the domain.
Important

Unless there is only one domain controller in the domain, the infrastructure master
role should not be assigned to the domain controller that is hosting the global
catalog. If the infrastructure master and global catalog are on the same domain
controller, the infrastructure master will not function. The infrastructure master will
never find data that is out of date, so it will never replicate any changes to the other
domain controllers in the domain.
In the case where all of the domain controllers in a domain are also hosting the global
catalog, all of the domain controllers will have the current data and it does not matter
which domain controller holds the infrastructure master role.

The infrastructure master is also responsible for updating the group-to-user references
whenever the members of groups are renamed or changed. When you rename or move a
member of a group (and that member resides in a different domain from the group), the
group may temporarily appear not to contain that member. The infrastructure master of the
group's domain is responsible for updating the group so it knows the new name or location
of the member. This prevents the loss of group memberships associated with a user account
when the user account is renamed or moved. The infrastructure master distributes the
update via multimaster replication.
There is no compromise to security during the time between the member rename and the
group update. Only an administrator looking at that particular group membership would
notice the temporary inconsistency.
For information about transferring operations master roles, see Transferring operations
master roles. For information about what to do when an operations master fails,
see Responding to operations master failures.

What Is DHCP?
349 out of 381 rated this helpful - Rate this topic

Applies To: Windows Server 2008

Dynamic Host Configuration Protocol (DHCP) is a client/server protocol that automatically
provides an Internet Protocol (IP) host with its IP address and other related configuration
information such as the subnet mask and default gateway. RFCs 2131 and 2132 define DHCP
as an Internet Engineering Task Force (IETF) standard based on Bootstrap Protocol (BOOTP),
a protocol with which DHCP shares many implementation details. DHCP allows hosts to
obtain required TCP/IP configuration information from a DHCP server.
Windows Server 2008 includes the DHCP Server service, which is an optional networking
component. All Windows-based clients include the DHCP client as part of TCP/IP, including
Windows Vista, the Windows Server2003 operating system, the Windows XP
Professional operating system, Microsoft Windows2000 Professional operating system,
Microsoft WindowsNT Workstation4.0 operating system, Microsoft Windows Millennium
Edition operating system, and the Microsoft Windows98 operating system.

Why use DHCP?

Every device on a TCP/IP-based network must have a unique unicast IP address to access the
network and its resources. Without DHCP, IP addresses for new computers or computers that
are moved from one subnet to another must be configured manually; IP addresses for
computers that are removed from the network must be manually reclaimed.
With DHCP, this entire process is automated and managed centrally. The DHCP server
maintains a pool of IP addresses and leases an address to any DHCP-enabled client when it
starts up on the network. Because the IP addresses are dynamic (leased) rather than static
(permanently assigned), addresses no longer in use are automatically returned to the pool
for reallocation.
The network administrator establishes DHCP servers that maintain TCP/IP configuration
information and provide address configuration to DHCP-enabled clients in the form of a lease
offer. The DHCP server stores the configuration information in a database that includes:

Valid TCP/IP configuration parameters for all clients on the network.

Valid IP addresses, maintained in a pool for assignment to clients, as well as excluded

addresses.

Reserved IP addresses associated with particular DHCP clients. This allows consistent
assignment of a single IP address to a single DHCP client.

The lease duration, or the length of time for which the IP address can be used before
a lease renewal is required.

A DHCP-enabled client, upon accepting a lease offer, receives:

A valid IP address for the subnet to which it is connecting.

Requested DHCP options, which are additional parameters that a DHCP server is
configured to assign to clients. Some examples of DHCP options are Router (default
gateway), DNS Servers, and DNS Domain Name. For a full list of DHCP options,
see DHCP Tools and Options.

Benefits of DHCP
In Windows Server 2008, the DHCP Server service provides the following benefits:

Reliable IP address configuration. DHCP minimizes configuration errors caused by

manual IP address configuration, such as typographical errors, or address conflicts
caused by the assignment of an IP address to more than one computer at the same
time.

Reduced network administration. DHCP includes the following features to reduce

network administration:
o

Centralized and automated TCP/IP configuration.

The ability to define TCP/IP configurations from a central location.

The ability to assign a full range of additional TCP/IP configuration values by

means of DHCP options.

The efficient handling of IP address changes for clients that must be updated
frequently, such as those for portable computers that move to different
locations on a wireless network.

The forwarding of initial DHCP messages by using a DHCP relay agent, which
eliminates the need for a DHCP server on every subnet.

Interactions between client and server

DHCP servers and DHCP clients communicate through a series of DHCP messages. To obtain
a lease, the DHCP client initiates a conversation with a DHCP server using a series of these
DHCP messages.

DHCP messages
The following list includes the eight types of messages that can be sent between DHCP
clients and servers.

DHCPDiscover
Broadcast by a DHCP client when it first attempts to connect to the network. The
DHCPDiscover message requests IP address information from a DHCP server.

DHCPOffer
Broadcast by each DHCP server that receives the client DHCPDiscover message and has an
IP address configuration to offer to the client. The DHCPOffer message contains an unleased

IP address and additional TCP/IP configuration information, such as the subnet mask and
default gateway. More than one DHCP server can respond with a DHCPOffer message. The
client accepts the best offer, which, for a Windows DHCP client, is the first DHCPOffer
message that it receives.

DHCPRequest
Broadcast by a DHCP client after it selects a DHCPOffer. The DHCPRequest message contains
the IP address from the DHCPOffer that it selected. If the client is renewing or rebinding to a
previous lease, this packet might be unicast directly to the server.

DHCPAck
Broadcast by a DHCP server to a DHCP client acknowledging the DHCPRequest message. At
this time, the server also forwards any options. Upon receipt of the DHCPAck, the client can
use the leased IP address to participate in the TCP/IP network and complete its system
startup. This message is typically broadcast, because the DHCP client does not officially
have an IP address that it can use at this point. If the DHCPAck is in response to a
DHCPInform, then the message is unicast directly to the host that sent the DHCPInform
message.

DHCPNack
Broadcast by a DHCP server to a DHCP client denying the clients DHCPRequest message.
This might occur if the requested address is incorrect because the client moved to a new
subnet or because the DHCP clients lease has expired and cannot be renewed.

DHCPDecline
Broadcast by a DHCP client to a DHCP server, informing the server that the offered IP
address is declined because it appears to be in use by another computer.

DHCPRelease
Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the
remaining lease. This is unicast to the server that provided the lease.

DHCPInform
Sent from a DHCP client to a DHCP server, asking only for additional local configuration
parameters; the client already has a configured IP address. This message type is also used
by DHCP servers running Windows Server 2008 to detect unauthorized DHCP servers.

DHCP lease process

A DHCP-enabled client obtains a lease for an IP address from a DHCP server. Before the lease
expires, the DHCP client must renew the lease or obtain a new lease. Leases are retained in
the DHCP server database for a period of time after expiration. By default, this grace period
is four hours and cleanup occurs once an hour for a DHCP server running Windows
Server 2008. This protects a clients lease in case the client and server are in different time
zones, the internal clocks of the client and server computers are not synchronized, or the
client is off the network when the lease expires.

DHCP Lease Process Overview

1. The DHCP client requests an IP address by broadcasting a DHCPDiscover message to

the local subnet.
2. The client is offered an address when a DHCP server responds with a DHCPOffer
message containing an IP address and configuration information for lease to the
client. If no DHCP server responds to the client request, the client sends
DHCPDiscover messages at intervals of 0, 4, 8, 16, and 32 seconds, plus a random
interval of between -1 second and 1 second. If there is no response from a DHCP
server after one minute, the client can proceed in one of two ways:
o

If the client is using the APIPA alternate configuration, the client selfconfigures an IP address for its interface.

If the client does not support alternate configuration, such as APIPA, or if IP

auto-configuration has been disabled, the client network initialization fails.

In both cases, the client begins a new cycle of DHCPDiscover messages in the
background every five minutes, using the same intervals as before (0, 4, 8, 16, and
32 seconds), until it receives a DHCPOffer message from a DHCP server.
3. The client indicates acceptance of the offer by selecting the offered address and
broadcasting a DHCPRequest message in response.
4. The client is assigned the address and the DHCP server broadcasts a DHCPAck
message in response, finalizing the terms of the lease.

When the client receives acknowledgment, it configures its TCP/IP properties by using the
DHCP option information in the reply, and completes its initialization of TCP/IP.
In rare cases, a DHCP server might return a negative acknowledgment to the client. This can
happen if a client requests an address that is not valid or a duplicate. If a client receives a
negative acknowledgment (DHCPNack), the client must begin the entire lease process again.
When the DHCP client and the DHCP server are on the same IP broadcast subnet, the
DHCPDiscover, DHCPOffer, DHCPRequest, and DHCPAck messages are sent to identify clients
by means of IP-level broadcasts sent to the limited broadcast address and the media access
control (MAC) broadcast address.
When the DHCP server and DHCP client are not on the same subnet, either a router or a host
on the DHCP clients subnet must act as a DHCP relay agent to support the forwarding of
DHCP messages between the DHCP client and the DHCP server.

DHCP server responsibilities

The DHCP servers maintain scopes, reservations, and options as set by the administrator.

Scopes
A scope must be properly defined and activated before DHCP clients can use the DHCP
server for automatic TCP/IP configuration. A DHCP scope is an administrative collection of IP
addresses and TCP/IP configuration parameters that are available for lease to DHCP clients
of a specific subnet. The network administrator creates a scope for each subnet.
A scope has the following properties:

A scope name, assigned when the scope is created.

A range of possible IP addresses from which to include or exclude addresses used in

DHCP lease offers.

A unique subnet mask, which determines the network ID for an IP address in the
scope.

Lease duration values.

Each DHCP scope can have a single continuous range of IP addresses. To use several
address ranges within a single scope, you must first define the entire address range for the
scope, and then set exclusion ranges.

Lease durations
When a scope is created, the lease duration is set to eight days by default. However, there
are situations when the administrator might want to change the lease duration. The

following are examples of adjusting the lease duration due to individual network
consideration:

An organization has a large number of IP addresses available and client

configurations rarely change. The administrator increases the lease duration to
reduce the frequency of lease renewal exchanges between clients and the DHCP
server. Because the DHCP clients are renewing their leases less frequently, DHCPrelated network traffic is reduced.

An organization has a limited number of IP addresses available and client

configurations change frequently or clients move often in or out of the network. The
administrator reduces the lease duration to increase the rate at which unused
addresses are returned to the available address pool for reassignment.

For example, consider the ratio between connected computers and available IP addresses. If
40 computers share 254 available addresses, the demand for reusing addresses is low. A
long lease time, such as a few months, might be appropriate in such a situation. However, if
230 computers must share the same address pool, demand for available addresses is higher,
and a shorter lease time (for example, a few days), is more appropriate.

Exclusion ranges
When you create a new scope, immediately exclude the addresses of existing statically
configured computers. By using exclusion ranges, you can exclude specific IP address ranges
within a scope so that those addresses are not offered to clients. Assign IP addresses within
exclusion ranges to computers or devices that must have a static IP address, such as
servers, firewalls, or routers.
You can use excluded IP addresses on your network by manually configuring these addresses
at computers that do not use DHCP to obtain an address, or by configuring reservations for
these addresses.

Reservations
You can reserve IP addresses for assignment to specified computers or devices on the
network. Reservations ensure that a specified hardware device on a subnet always receives
the same IP address lease. Use reservations for DHCP-enabled devices that must always
have the same IP address on your network, such as servers that do not support Domain
Name System (DNS) dynamic update.

When the DHCP server is deployed in a network, it allows the users to either exclude a
range of IP addresses from being assigned to the DHCP client computers, or reserve
some particular IP addresses for the mission-critical computers only. The detailed
information about the DHCP exclusion and DHCP reservation is given below:

DHCP Reservation
DHCP reservation is a feature in the DHCP server that allows the DHCP administrators
to reserve one or more IP addresses for particular mission-critical computers only. In
order to configure DHCP reservation, the administrators are required to know the
physical addresses a.k.a. MAC addresses of the target computers for which the
particular IP addresses are to be reserved. Once the MAC addresses are known, the
administrators can then reserve the appropriate IP addresses by mapping them with
the MAC addresses.
For example, if computer A is playing the role of a print server, and has MAC address of
00:A1:FB:12:45:4C and you want that the computer should always get 192.168.0.7 as
its IP address, you can map the MAC address of the computer A with the IP address to
configure reservation.
When an IP address is reserved for a particular computer, the IP address remains in the
DHCP address pool, even if it is the only address available for the assignment and any
other client computer is requesting for the address. The reserved IP address will only be
assigned to the computer whose MAC address is used to map with it. In this example,
as soon as the print server boots up and requests for a dynamic IP address from the
DHCP server, the DHCP server assigns the 192.168.0.7 IP address to the server as
configured.

DHCP Exclusion
DHCP exclusion, on the other hand, is a configuration in the DHCP server using which
you, as a DHCP administrator, exclude a single IP address or a range of IP addresses
from being assigned automatically to the DHCP client computers.
DHCP exclusion range is specified while configuring the DHCP server if you have
assigned a few static IP addresses to the mission-critical computers in order to avoid
latency in the network.
For example, if you have assigned the IP addresses from 192.168.0.2 to 192.168.0.5 to
the DNS server, DHCP server, Active Directory domain controller, and the WDS server
respectively, you must exclude the said IP addresses from the DHCP address pool.
When an IP address or range of IP addresses is excluded from the DHCP server, the
excluded IP addresses are never assigned automatically to the requesting DHCP client
computers whatsoever.

DHCP Reservations and Exclusions

When configuring a DHCP server I have often seen people interchange the
words reservation and exclusion. These are two incredibly different
concepts.
I have seen people interchange the words reservation and exclusion many
times when talking about the configuration of a DHCP server. These two
concepts sound similar at first but they are actually quite different and serve
their own purpose.
An exclusion is an address or range of addresses taken from a DHCP
scope that the DHCP server is not allowed to hand out. For example, if you
have set a DHCP server to exclude the address range 192.168.0.1192.168.0.10 then the only way a computer on your network would get an
address of 192.168.0.4 would be if you assigned it statically on that
machine. This is because DHCP knows NOT to give this range of IP
addresses out.
A reservation is a specific IP addresses that is tied to a certain device
through its MAC address. For example, if we have a workstation on the
network that requires a certain IP address, but we dont want to go through
to trouble of assigning it statically, then we can create a reservation for it.
So if the MAC address of the NIC on the computer is AA-BB-00-FF-CC-AA
and we want it to maintain the IP address of 192.168.0.100 then we would
create a DHCP reservation under that particular scope saying that the IP
address 192.168.0.100 is reserved only for the MAC address AA-BB-00FF-CC-AA.

80/20 Rule

You will probably install more than one DHCP server so that the failure of any individual
server will not prevent DHCP clients from starting. However, DHCP does not provide a way
for DHCP servers to cooperate in ensuring that assigned addresses are unique. Therefore,
you must carefully divide the available address pool among the DHCP servers to prevent
duplicate address assignment.
For balancing DHCP server usage, use the 80/20 rule to divide scope addresses between
DHCP servers. Figure 4.11 is an example of the 80/20 rule.

Figure 4.11 80/20 Rule Model

DHCP Server 2 is configured to lease most (about 80 percent) of the available addresses.
DHCP Server 1 is configured to lease the remaining addresses (about 20 percent).
This scenario allows the local DHCP server (DHCP Server 2) to respond to requests from local
DHCP clients most of the time. The remote or backup DHCP server (DHCP Server 1) assigns
addresses to clients on the other subnet only when the local server is not available or is out
of addresses. This same rule can be used in a multiple-subnet scenario to ensure the
availability of a DHCP server when a client requests a lease.

The Cable GuyThe DHCPv6 Protocol

Joseph Davies

The Dynamic Host Configuration Protocol (DHCP) was

designed to take care of assigning IP addresses and other
networking information to computers so they can
communicate on the network automatically. With an IPv6
network, you don't actually need DHCP to configure
addresses, but there can be good reasons to use it. DHCP for
IPv6 (DHCPv6) can
provide stateful address configuration or stateless configuration settings to IPv6 hosts. IPv6 hosts can
use several methods to configure addresses:
Stateless Address Autoconfiguration is used to configure both link-local addresses and
additional non-link-local addresses by exchanging Router Solicitation and Router Advertisement
messages with neighboring routers.
Stateful Address Autoconfiguration is used to configure non-link-local addresses through
the use of a configuration protocol such as DHCP.

An IPv6 host performs stateless address autoconfiguration automatically and uses a

configuration protocol such as DHCPv6 based on the following flags in the Router
Advertisement message sent by a neighboring router:
Managed Address Configuration Flag, which is also known as the M flag. When set to 1,
this flag instructs the host to use a configuration protocol to obtain stateful addresses.
Other Stateful Configuration Flag , which is also known as the O flag. When set to 1, this
flag instructs the host to use a configuration protocol to obtain other configuration settings.

Combining the values of the M and O flags can yield the following:
Both M and O Flags are Set to 0. This combination corresponds to a network without a
DHCPv6 infrastructure. Hosts use router advertisements for non-link-local addresses and other
methods (such as manual configuration) to configure other settings.
Both M and O Flags are Set to 1. DHCPv6 is used for both addresses and other configuration
settings. This combination is known as DHCPv6 stateful, in which DHCPv6 is assigning stateful
addresses to IPv6 hosts.
The M Flag is Set to 0 and the O Flag is Set to 1. DHCPv6 is not used to assign
addresses, only to assign other configuration settings. Neighboring routers are configured to advertise
non-link-local address prefixes from which IPv6 hosts derive stateless addresses. This combination is
known as DHCPv6 stateless: DHCPv6 is not assigning stateful addresses to IPv6 hosts, but stateless
configuration settings.
The M Flag is Set to 1 and the O Flag is Set to 0. In this combination, DHCPv6 is used
for address configuration but not for other settings. Because IPv6 hosts typically need to be configured
with other settings, such as the IPv6 addresses of Domain Name System (DNS) servers, this is an
unlikely combination.

Like DHCP for IPv4, the components of a DHCPv6 infrastructure consist of DHCPv6
clients that request configuration, DHCPv6 servers that provide configuration, and
DHCPv6 relay agents that convey messages between clients and servers when clients
are on subnets that do not have a DHCPv6 server.

DHCPv6 Messages
As with DHCP for IPv4, DHCPv6 uses User Datagram Protocol (UDP) messages. DHCPv6
clients listen for DHCP messages on UDP port 546. DHCPv6 servers and relay agents
listen for DHCPv6 messages on UDP port 547. The structure for DHCPv6 messages is
much simpler than for DHCP for IPv4, which had its origins in the BOOTP protocol to

support diskless workstations. Figure 1 shows the structure of DHCPv6 messages sent
between client and server.

Figure 1 DHCPv6 messages between client and server (Click the image for a larger
view)
The 1-byte Msg-Type field indicates the type of DHCPv6 message. The 3-byte
Transaction-ID field is determined by a client and used to group the messages of a
DHCPv6 message exchange together. Following the Transaction-ID field, DHCPv6 options
are used to indicate client and server identification, addresses, and other configuration
settings. For the list of defined DHCPv6 options, see RFC 3315, as referenced in the
"DHCPv6 RFC Resources" sidebar.
DHCPv6 options are formatted with the type-length-value (TLV) format. Figure 2 shows
the structure of DHCPv6 options.
The 2-byte Option-Code field indicates a specific option. The 2-byte Option-Len field
indicates the length of the Option-Data field in bytes. The Option-Data field contains the
data for the option.
There is a separate message structure for the messages exchanged between relay
agents and servers to record additional information. Figure 3 shows the structure of
these kinds of messages.

Figure 2 Structure of DHCPv6 options (Click the image for a larger view)
The 1-byte Hop-Count field indicates the number of relay agents that have received the
message. A receiving relay agent can discard the message if it exceeds a configured
maximum hop count. The 16-byte Link-Address field contains a non-link-local address
that is assigned to an interface connected to the subnet on which the client is located.
From the Link-Address field, the server can determine the correct address scope from
which to assign an address. The 16-byte Peer-Address field contains the IPv6 address of
the client that originally sent the message or the previous relay agent that relayed the
message. Beyond the Peer-Address field are DHCPv6 options that include the Relay
Message option, which contains the message being relayed and other options. The
Relay Message option provides an encapsulation of the messages being exchanged
between the client and the server.
There are no broadcast addresses defined for IPv6. Therefore, the use of the limited
broadcast address for some DHCPv4 messages has been replaced with the use of the
All_DHCP_Relay_Agents_and_Servers address of FF02::1:2 for DHCPv6. For example, a
DHCPv6 client attempting to discover the location of the DHCPv6 server on the network
sends a Solicit message from its link-local address to FF02::1:2. If there is a DHCPv6
server on the host's subnet, it receives the Solicit message and sends an appropriate
reply. More typically, a DHCPv6 relay agent on the host's subnet receives the Solicit

message and forwards it to a DHCPv6 server.

Figure 3 Structure of messages between relay and server (Click the image for a
larger view)

Stateful Message Exchange

A DHCPv6 stateful message exchange to obtain IPv6 addresses and configuration
settings-when both M and O flags in a received router advertisement are set to 1typically consists of the following messages:

A Solicit message sent by the client to locate the servers.

An Advertise message sent by a server to indicate that it can provide addresses

and configuration settings.

A Request message sent by the client to request addresses and configuration

settings from a specific server.

A Reply message sent by the requested server that contains addresses and
configuration settings.
If there is a relay agent between the client and the server, the relay agent sends the
server Relay-Forward messages containing the encapsulated Solicit and Request
messages from the client. The server sends the relay agent Relay-Reply messages
containing the encapsulated Advertise and Reply messages for the client. For a
complete list of DHCPv6 messages, see Figure 4.
Figure 4 DHCPv6 messages

DHCPv6
Message

Description

Equivalent DHCP
for IPv4 Message

Solicit

Sent by a client to locate servers.

DHCPDiscover

Advertise

Sent by a server in response to a Solicit

message to indicate availability.

DHCPOffer

Request

Sent by a client to request addresses or

configuration settings from a specific
server.

DHCPRequest

Confirm

Sent by a client to all servers to determine

if a client's configuration is valid for the
connected link.

DHCPRequest

Renew

Sent by a client to a specific server to

extend the lifetime of assigned addresses

DHCPRequest

and obtain updated configuration settings.

Rebind

Sent by a client to any server when a

response to the Renew message is not
received.

DHCPRequest

Reply

Sent by a server to a specific client in

response to a Solicit, Request, Renew,
Rebind, Information-Request, Confirm,
Release, or Decline message.

DHCPAck

Release

Sent by a client to indicate that the client is DHCPRelease

no longer using an assigned address.

Decline

Sent by a client to a specific server to

indicate that the assigned address is
already in use.

DHCPDecline

Reconfigure Sent by a server to a client to indicate that

the server has new or updated
configuration settings. The client then
sends either a Renew or InformationRequest message.

N/A

Information Sent by a client to request configuration

-Request
settings (but not addresses).

DHCPInform

RelayForward

Sent by a relay agent to forward a message N/A

to a server. Relay-Forward contains a client
message encapsulated as the DHCPv6
Relay-Message option.

Relay-Reply Sent by a server to send a message to a

N/A
client through a relay agent. Relay-Reply
contains a server message encapsulated as
the DHCPv6 Relay-Message option.
Stateless Message Exchange
A DHCPv6 stateless message exchange to obtain only configuration settings-when the M
flag is set to 0 and the O flag is set to 1 in a received router advertisement-typically
consists of the following messages: an Information-Request message sent by the
DHCPv6 client to request configuration settings from a server and a Reply message sent
by a server containing the requested config settings.
For an IPv6 network that has routers configured to assign stateless address prefixes to
IPv6 hosts, the two-message DHCPv6 exchange can be used to assign DNS servers, DNS
domain names, and other configuration settings that are not included in the router
advertisement message.

DHCPv6 Support in Windows

Windows Vista and Windows Server 2008 include a DHCPv6 client. The DHCPv6
client attempts DHCPv6-based configuration depending on the values of the M and O

flags in received router advertisement messages. Therefore, to use DHCPv6, you must
configure DHCPv6 servers and relay agents to service each IPv6 subnet and then
configure your IPv6 routers to set these two flags to their appropriate values. If there
are multiple advertising routers for a given subnet, they should be configured to
advertise the same stateless address prefixes and values of the M and O flags. IPv6
hosts running Windows XP or Windows Server 2003 do not include a DHCPv6 client
and therefore ignore the values of the M and O flags in received router advertisements.
You can configure an IPv6 router that is running Windows Vista or Windows Server 2008
to set the M flag to 1 in router advertisements with the "netsh interface ipv6 set
interface InterfaceName managedaddress=enabled" command. Similarly, you can set
the O flag to 1 in router advertisements with the "netsh interface ipv6 set interface
InterfaceName otherstateful=enabled" command.
Windows Server 2008 supports a DHCPv6 relay agent and DHCPv6 stateless and
stateful configuration with the DHCP Server service. For stateless configuration ,you can
configure the DHCP Server service for DHCPv6 options to be distributed to all DHCPv6
clients in the two-message DHCPv6 message exchange previously described. For
stateful configuration, you can configure the DHCP Server service for DHCPv6 scopes
and options

DNS
Short for Domain Name System (or Service or Server), anInternet service that
translates domain names into IP addresses. Because domain names are alphabetic,
they're easier to remember. The Internet however, is really based on IP addresses.
Every time you use a domain name, therefore, a DNS service must translate the name
into the corresponding IP address. For example, the domain
name www.example.com might translate to198.105.232.4.
The DNS system is, in fact, its own network. If one DNS server doesn't know how to
translate a particular domain name, it asks another one, and so on, until the correct IP
address is returned.
Short for Domain Name System (or Service or Server), anInternet service that
translates domain names into IP addresses. Because domain names are alphabetic,

they're easier to remember. The Internet however, is really based on IP addresses.

Every time you use a domain name, therefore, a DNS service must translate the name
into the corresponding IP address. For example, the domain
name www.example.com might translate to198.105.232.4.
The DNS system is, in fact, its own network. If one DNS server doesn't know how to
translate a particular domain name, it asks another one, and so on, until the correct IP
address is returned.

DNS domain names

Domain Name System (DNS) was originally defined in Request for Comments (RFCs) 1034
and 1035. These documents specify elements common to all implementations of DNSrelated software, including:

A DNS domain namespace, which specifies a structured hierarchy of domains used to

organize names.

Resource records, which map DNS domain names to a specific type of resource
information for use when the name is registered or resolved in the namespace.

DNS servers, which store and answer name queries for resource records.

DNS clients, also known as resolvers, which query servers to look up and resolve
names to a type of resource record specified in the query.

For more information about Requests for Comments (RFCs), see DNS RFCs.

Understanding the DNS domain namespace

The DNS domain namespace, as shown in the following figure, is based on the concept of a
tree of named domains. Each level of the tree can represent either a branch or a leaf of the
tree. A branch is a level where more than one name is used to identify a collection of named
resources. A leaf represents a single name used once at that level to indicate a specific
resource.

The previous figure shows how Microsoft is assigned authority by the Internet root servers
for its own part of the DNS domain namespace tree on the Internet. DNS clients and servers
use queries as the fundamental method of resolving names in the tree to specific types of
resource information. This information is provided by DNS servers in query responses to DNS
clients, who then extract the information and pass it to a requesting program for resolving
the queried name.
In the process of resolving a name, keep in mind that DNS servers often function as DNS
clients, querying other servers in order to fully resolve a queried name. For more
information, see How DNS query works.

How the DNS domain namespace is

organized
Any DNS domain name used in the tree is technically a domain. Most DNS discussions,
however, identify names in one of five ways, based on the level and the way a name is
commonly used. For example, the DNS domain name registered to Microsoft
(microsoft.com.) is known as a second-level domain. This is because the name has two parts
(known as labels) that indicate it is located two levels below the root or top of the tree. Most
DNS domain names have two or more labels, each of which indicates a new level in the tree.
Periods are used in names to separate labels.

In addition to second-level domains, other terms used to describe DNS domain names by
their function in the namespace are described in the following table.

The domain root

This is the top of the tree, representing an unnamed level; it is sometimes shown as two
empty quotation marks (""), indicating a null value. When used in a DNS domain name, it is
stated by a trailing period (.) to designate that the name is located at the root or highest
level of the domain hierarchy. In this instance, the DNS domain name is considered to be
complete and points to an exact location in the tree of names. Names stated this way are
called fully qualified domain names (FQDNs).
Eg. A single period (.) or a period used at the end of a name, such as
"example.microsoft.com.".

Top-level domain
A name of two or three letters used to indicate a country/region or the type of organization
using a name. For more information, see Top-level domains.
".com", which indicates a name registered to a business for commercial use on the Internet.

Second-level domain
Variable-length names registered to an individual or organization for use on the Internet.
These names are always based upon an appropriate top-level domain, depending on the
type of organization or geographic location where a name is used.
"microsoft.com.", which is the second-level domain name registered to Microsoft by the
Internet DNS domain name registrar.

Subdomain
Additional names that an organization can create that are derived from the registered
second-level domain name. These include names added to grow the DNS tree of names in
an organization and divide it into departments or geographic locations.
"example.microsoft.com.", which is a fictitious subdomain assigned by Microsoft for use in
documentation example names.

Host or resource name

Names that represent a leaf in the DNS tree of names and identify a specific resource.
Typically, the leftmost label of a DNS domain name identifies a specific computer on the

network. For example, if a name at this level is used in a host (A) RR, it is used to look up the
IP address of computer based on its host name.
"host-a.example.microsoft.com.", where the first label ("host-a") is the DNS host name for a
specific computer on the network.

Understanding Zones
34 out of 35 rated this helpful - Rate this topic
Applies To: Windows Server 2008, Windows Server 2008 R2
In addition to dividing your Domain Name System (DNS) namespace into domains, you can
also divide your DNS namespace into zones that store name information about one or more
DNS domains. A zone is the authoritative source for information about each DNS domain
name that is included in the zone.
A zone starts with a single DNS domain name. If other domains are added below the initial
domain, these domains can either be part of the same zone or belong to another zone. That
is, when you add a subdomain, you can either include it as part of the original zone, or you
can delegate it away to another zone that you create to support the subdomain.
For example, the following illustration shows the microsoft.com domain, which contains
domain names for Microsoft. When the microsoft.com domain is first created at a single
server, it is configured as a single zone for all of the Microsoft DNS namespace. If, however,
the microsoft.com domain must use subdomains, those subdomains must be included in the
zone or delegated away to another zone.

In this illustration, the example.microsoft.com domain has a new subdomainthe

example.microsoft.com domaindelegated away from the microsoft.com zone and managed
in its own zone. However, the microsoft.com zone must contain a few resource records to
provide the delegation information that references the DNS servers that are authoritative for
the delegated example.microsoft.com subdomain.
If the microsoft.com zone does not use delegation for a subdomain, any data for the
subdomain remains part of the microsoft.com zone. For example, the subdomain
dev.microsoft.com is not delegated away, but it is managed by the microsoft.com zone.

Zone replication and transfers

Because of the important role that zones play in DNS, they must be available from more
than one DNS server on the network so that they can provide availability and fault tolerance.
Otherwise, if only a single server is available and that server is not responding, queries for
names in the zone can fail. So that additional servers can host a zone, zone transfers are
required for replication and synchronization of all copies of the zone that are used at each
server that is configured to host the zone.
When a new DNS server is added to the network and it is configured as a new secondary
server for an existing zone, it performs a full initial transfer of the zone to obtain and
replicate a full copy of resource records for the zone. Most earlier DNS server
implementations use this same method of full transfer for a zone when the zone requires
updating after changes are made to the zone. For DNS servers running
Windows Server 2003 and Windows Server 2008, the DNS Server service supports
incremental zone transfer, a revised DNS zone transfer process for intermediate changes.
Incremental transfers provide a more efficient method of propagating zone changes and

updates. Unlike in earlier DNS implementations in which any request for an update of zone
data required a full transfer of the entire zone database, with incremental transfer the
secondary server can pull only those zone changes that it needs to synchronize its copy of
the zone with its source, either a primary or secondary copy of the zone that is maintained
by another DNS server.

Understanding Zone Types

133 out of 188 rated this helpful - Rate this topic
Applies To: Windows Server 2008, Windows Server 2008 R2
The DNS Server service provides for three types of zones:

Primary zone

Secondary zone

Stub zone

Primary zone
When a zone that this DNS server hosts is a primary zone, the DNS server is the primary
source for information about this zone, and it stores the master copy of zone data in a local
file or in AD DS. When the zone is stored in a file, by default the primary zone file is
named zone_name.dns and it is located in the %windir%\System32\Dns folder on the server.

Secondary zone
When a zone that this DNS server hosts is a secondary zone, this DNS server is a secondary
source for information about this zone. The zone at this server must be obtained from
another remote DNS server computer that also hosts the zone. This DNS server must have
network access to the remote DNS server that supplies this server with updated information
about the zone. Because a secondary zone is merely a copy of a primary zone that is hosted
on another server, it cannot be stored in AD DS.

Stub zone
When a zone that this DNS server hosts is a stub zone, this DNS server is a source only for
information about the authoritative name servers for this zone. The zone at this server must
be obtained from another DNS server that hosts the zone. This DNS server must have
network access to the remote DNS server to copy the authoritative name server information
about the zone.
You can use stub zones to:

Keep delegated zone information current. By updating a stub zone for one of its child
zones regularly, the DNS server that hosts both the parent zone and the stub zone
will maintain a current list of authoritative DNS servers for the child zone.

Improve name resolution. Stub zones enable a DNS server to perform recursion using
the stub zone's list of name servers, without having to query the Internet or an
internal root server for the DNS namespace.

Simplify DNS administration. By using stub zones throughout your DNS infrastructure,
you can distribute a list of the authoritative DNS servers for a zone without using
secondary zones. However, stub zones do not serve the same purpose as secondary
zones, and they are not an alternative for enhancing redundancy and load sharing.

There are two lists of DNS servers involved in the loading and maintenance of a stub zone:

The list of master servers from which the DNS server loads and updates a stub zone.
A master server may be a primary or secondary DNS server for the zone. In both
cases, it will have a complete list of the DNS servers for the zone.

The list of the authoritative DNS servers for a zone. This list is contained in the stub
zone using name server (NS) resource records.

When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the
master servers, which can be in different locations, for the necessary resource records of the
authoritative servers for the zone widgets.tailspintoys.com. The list of master servers may
contain a single server or multiple servers, and it can be changed anytime.

Understanding Reverse
Lookup
18 out of 24 rated this helpful - Rate this topic

Applies To: Windows Server 2008, Windows Server 2008 R2

In most Domain Name System (DNS) lookups, clients typically perform a
forward lookup, which is a search that is based on the DNS name of another
computer as it is stored in a host (A) resource record. This type of query
expects an IP address as the resource data for the answered response.
DNS also provides a reverse lookup process, in which clients use a known IP
address and look up a computer name based on its address. A reverse

lookup takes the form of a question, such as "Can you tell me the DNS name
of the computer that uses the IP address 192.168.1.20?"
DNS was not originally designed to support this type of query. One problem
in supporting the reverse query process is the difference in how the DNS
namespace organizes and indexes names and how IP addresses are
assigned. If the only method to answer the previous question is to search in
all domains in the DNS namespace, a reverse query would take too long and
require too much processing to be useful.
To solve this problem, a special domain, the in-addr.arpa domain, was
defined in the DNS standards and reserved in the Internet DNS namespace to
provide a practical and reliable way to perform reverse queries. To create the
reverse namespace, subdomains within the in-addr.arpa domain are formed,
using the reverse ordering of the numbers in the dotted-decimal notation of
IP addresses.
This reversed ordering of the domains for each octet value is necessary
because, unlike DNS names, when IP addresses are read from left to right,
they are interpreted in the opposite manner. When an IP address is read from
left to right, it is viewed from its most generalized information (an IP network
address) in the first part of the address to the more specific information (an
IP host address) that is contained in the last octets.
For this reason, the order of IP address octets must be reversed when the inaddr.arpa domain tree is built. The IP addresses of the DNS in-addr.arpa tree
can be delegated to organizations as they are assigned a specific or limited
set of IP addresses within the Internet-defined address classes.
Finally, the in-addr.arpa domain tree, as it is built into DNS, requires an
additional resource record typethe pointer (PTR) resource recordto be
defined. This resource record creates a mapping in the reverse lookup zone
that typically corresponds to a named host (A) resource record for the DNS
computer name of a host in its forward lookup zone.
The in-addr.arpa domain applies to all TCP/IP networks that are based on
Internet Protocol version 4 (IPv4) addressing. The New Zone Wizard
automatically assumes that you are using this domain when you create a
new reverse lookup zone.
If you are installing DNS and configuring reverse lookup zones for an Internet
Protocol version 6 (IPv6) network, you can specify an exact name in the New
Zone Wizard. This way, you can create reverse lookup zones in DNS Manager
that can support IPv6 networks, which use a different special domain name,
the ip6.arpa domain.

Additional information is available about IPv6 and DNS, including examples of

how to create and use ip6.arpa domain names, in Request for Comments
(RFC) 3596, "DNS Extensions to support IP version 6." For more information,
refer directly to this RFC, which you can find on the RFC Editor Web site
(http://go.microsoft.com/fwlink/?LinkId=240).
Example: reverse query (for IPv4 networks)
The following illustration shows an example of a reverse query that is
initiated by a DNS client to learn the name of another host (host-a) based on
its IP address: 192.168.1.20.

The reverse query process follows these steps:

1. The client queries the DNS server for a pointer (PTR) resource record
that maps to the IP address of 192.168.1.20 for host-a.
Because the query is for pointer (PTR) resource records, the resolver
reverses the address and appends the in-addr.arpa domain to the end
of the reverse address. This forms the fully qualified domain name
(FQDN) (20.1.168.192.in-addr.arpa.) to be searched in a reverse lookup
zone.
2. After it is located, the authoritative DNS server for 20.1.168.192.inaddr.arpa can respond with the pointer (PTR) resource record
information. This includes the DNS domain name for host-a, which
completes the reverse lookup process.
Remember that, if the queried reverse name is not answerable from the DNS
server, normal DNS resolution (either recursion or iteration) can be used to
locate a DNS server that is authoritative for the reverse lookup zone and that
contains the queried name. In this sense, the name resolution process that is
used in a reverse lookup is identical to that of a forward lookup.
Inverse queries
Use of inverse queries is an outdated practice, originally proposed as part of
the DNS standard to look up a host name based on its IP address. They use a

nonstandard DNS query operation, and their use is limited to some of the
earlier versions of Nslookup, a command-line utility for troubleshooting and
testing the DNS Server service.
The DNS Server service recognizes and accepts inverse query messages,
answering them with a fake inverse query response. For DNS servers running
in Windows NT Server 4.0, this support is available by default if the server
computer has been updated to Service Pack 4 (SP4) or later.

What Are DNS Records?

DNS stands for Domain Name System, which is the largest digital database in the
world, containing information about every web site on the internet. Every web site online
has an IP address that is its actual internet location, and this number is used to locate
the web site within the database. The data that tells the web server how to respond to
your input is known as the DNS records, or zone files. These records play a vital role in
the functionality of the internet, and any aspiring internet technology expert should learn
the following facts about DNS records and how they are used.
DNS Records Explained
DNS records are basically mapping files that tell the DNS server which IP address each
domain is associated with, and how to handle requests sent to each domain. When
someone visits a web site, a request is sent to the DNS server and then forwarded to
the web server provided by a web hosting company, which contain the data contained
on the site.
Various strings of letters are used as commands that dictate the actions of the DNS
server, and these strings of commands are called DNS syntax. Some DNS records
syntax that are commonly used in nearly all DNS record configurations are A, AAAA,
CNAME, MX, PTR, NS, SOA, SRV, TXT, and NAPTR. The following paragraph details
the meaning and usage of each of these syntax.
DNS Syntax Types Explained
An A record, which stands for address is the most basic type of syntax used in DNS
records, indicating the actual IP address of the domain. The AAAA record is an IPV6
address record that maps a hostname to a 128-bit Ipv6 address. Regular DNS
addresses are mapped for 32-bit IPv4 addresses.
The CNAME record stands for canonical name and serves to make one domain an
alias of another domain. CNAME is often used to associate new subdomains with an
existing domain's DNS records.

The MX record stands for mail exchange and is basically a list of mail exchange
servers that are to be used for the domain.
The PTR record stands for pointer record and maps an Ipv4 address to the CNAME
on the host.
The NS record stands for name server and indicates which Name Server is
authoritative for the domain.
An SOA record stands for State of Authority and is easily one of the most essential
DSN records because it stores important information like when the domain was last
updated and much more.
An SRV record stands for service and is used to define a TCP service on which the
domain operates.
A TXT record lets the administrator insert any text they'd like into the DNS record, and
it is often used for denoting facts about the domain.
Conclusion
DNS records are an important, yet unseen aspect of how the internet works. If you're
studying internet technology or training to become a server administrator, you will
definitely need to learn more information about all of the aforementioned DNS record
types and their uses.

Resource Record Types

29 out of 44 rated this helpful - Rate this topic
Different types of resource records can be used to provide DNSbased data about computers on a TCP/IP network. This section
describes the following resource records:
SOA
NS
A
PTR
CNAME

 MX
SRV
Next, it lists some of the other resource records specified by RFC
standards. Finally, it lists resource records that are specific to the
Windows 2000 implementation and one resource record specified
by the ATM Forum.
SOA Resource Records
Every zone contains a Start of Authority (SOA) resource record at
the beginning of the zone. SOA resource records include the
following fields:
The Owner , TTL , Class , and Type fields, as described in
"Resource Record Format" earlier in this chapter.
The authoritative server field shows the primary DNS
server authoritative for the zone.
The responsible person field shows the e-mail address of
the administrator responsible for the zone. It uses a period
(.) instead of an at symbol (@).
The serial number field shows how many times the zone
has been updated. When a zone's secondary server contacts
the master server for that zone to determine whether it
needs to initiate a zone transfer, the zone's secondary server
compares its own serial number with that of the master. If
the serial number of the master is higher, the secondary
server initiates a zone transfer.
The refresh field shows how often the secondary server for
the zone checks to see whether the zone has been changed.
The retry field shows how long after sending a zone transfer
request the secondary server for the zone waits for a
response from the master server before retrying.

 The expire field shows how long after the previous zone
transfer the secondary server for the zone continues to
respond to queries for the zone before discarding its own
zone as invalid.
The minimum TTL field applies to all the resource records in
the zone whenever a time to live value is not specified in a
resource record. Whenever a resolver queries the server, the
server sends back resource records along with the minimum
time to live. Negative responses are cached for the minimum
TTL of the SOA resource record of the authoritative zone.
The following example shows the SOA resource record:
noam.reskit.com. IN SOA (
noamdc1.noam.reskit.com. ; authoritative server for the
zone
administrator.noam.reskit.com. ; zone admin e-mail
; (responsible person)
5099 ; serial number
3600 ; refresh (1 hour)
600 ; retry (10 mins)
86400 ; expire (1 day)
60 ) ; minimum TTL (1 min)
Top Of Page
NS Resource Records
The name server (NS) resource record indicates the servers
authoritative for the zone. They indicate primary and secondary
servers for the zone specified in the SOA resource record, and

they indicate the servers for any delegated zones. Every zone
must contain at least one NS record at the zone root.
For example, when the administrator on reskit.com delegated
authority for the noam.reskit.com subdomain to
noamdc1.noam.reskit.com., the following line was added to the
zones reskit.com and noam.reskit.com:
noam.reskit.com. IN NS noamdc1.noam.reskit.com.
Top Of Page
A Resource Records
The address (A) resource record maps an FQDN to an IP address,
so the resolvers can request the corresponding IP address for an
FQDN. For example, the following A resource record, located in
the zone noam.reskit.com, maps the FQDN of the server to its IP
address:
noamdc1 IN A 172.16.48.1
Top Of Page
PTR Records
The pointer (PTR) resource record , in contrast to the A resource
record, maps an IP address to an FQDN. For example, the
following PTR resource record maps the IP address of
noamdc1.noam.reskit.com to its FQDN:
1.48.16.172.in-addr.arpa. IN PTR
noamdc1.noam.reskit.com.
Top Of Page
CNAME Resource Records
The canonical name (CNAME) resource record creates an alias
(synonymous name) for the specified FQDN. You can use CNAME
records to hide the implementation details of your network from

the clients that connect to it. For example, suppose you want to
put an FTP server named ftp1.noam.reskit.com on your
noam.reskit.com subdomain, but you know that in six months you
will move it to a computer named ftp2.noam.reskit.com, and you
do not want your users to have to know about the change. You
can just create an alias called ftp.noam.reskit.com that points to
ftp1.noam.reskit.com, and then when you move your computer,
you need only change the CNAME record to point to
ftp2.noam.reskit.com. For example, the following CNAME resource
record creates an alias for ftp1.noam.reskit.com:
ftp.noam.reskit.com. IN CNAME ftp1.noam.reskit.com.
Once a DNS client queries for the A resource record for
ftp.noam.reskit.com, the DNS server finds the CNAME resource
record, resolves the query for the A resource record for
ftp1.noam.reskit.com, and returns both the A and CNAME
resource records to the client.
Note
According to RFC 2181, there must be only one canonical name
per alias.
Top Of Page
MX Resource Records
The mail exchange (MX) resource record specifies a mail
exchange server for a DNS domain name. A mail exchange server
is a host that will either process or forward mail for the DNS
domain name. Processing the mail means either delivering it to
the addressee or passing it to a different type of mail transport.
Forwarding the mail means sending it to its final destination
server, sending it using Simple Mail Transfer Protocol (SMTP) to
another mail exchange server that is closer to the final
destination, or queuing it for a specified amount of time.
Note
Only mail exchange servers use MX records.

If you want to use multiple mail exchange servers in one DNS

domain, you can have multiple MX resource records for that
domain. The following example shows MX resource records for the
mail servers for the domain noam.reskit.com.:
*.noam.reskit.com. IN MX 0 mailserver1.noam.reskit.com.
*.noam.reskit.com. IN MX 10
mailserver2.noam.reskit.com.
*.noam.reskit.com. IN MX 10
mailserver3.noam.reskit.com.
The first three fields in this resource record are the standard
owner, class, and type fields. The fourth field is the mail server
priority , or preference value. The preference value specifies the
preference given to the MX record among MX records. Lower
priority records are preferred. Thus, when a mailer needs to send
mail to a certain DNS domain, it first contacts a DNS server for
that domain and retrieves all the MX records. It then contacts the
mailer with the lowest preference value.
For example, suppose Jane Doe sends an e-mail message to
JohnDoe@noam.reskit.com on a day that mailserver1 is down, but
mailserver2 is working. Her mailer tries to deliver the message to
mailserver1, because it has the lowest preference value, but it
fails because mailserver1 is down. This time, Jane's mailer can
choose either mailserver2 or mailserver3, because their
preference values are equal. It successfully delivers the message
to mailserver2.
To prevent mail loops, if the mailer is on a host that is listed as an
MX for the destination host, the mailer can deliver only to an MX
with a lower preference value than its own host.
Note
The sendmail program requires special configuration if a CNAME
is not referenced in the MX record.
Top Of Page

SRV Records
With MX records, you can have multiple mail servers in a DNS
domain, and when a mailer needs to send mail to a host in the
domain, it can find the location of a mail exchange server. But
what about other applications, such as the World Wide Web or
telnet?
Service (SRV) resource records enable you to specify the location
of the servers for a specific service, protocol, and DNS domain.
Thus, if you have two Web servers in your domain, you can create
SRV resource records specifying which hosts serve as Web
servers, and resolvers can then retrieve all the SRV resource
records for the Web servers.
The format of an SRV record is as follows:
_Service._Proto.Name TTL Class SRV Priority Weight
Port Target
The _ Service field specifies the name of the service, such
as http or telnet. Some services are defined in the standards,
and others can be defined locally.
The _ Proto field specifies the protocol, such as TCP or UDP.
The Name field specifies the domain name to which the
resource record refers.
The TTL and Class fields are the same as the fields defined
earlier in this chapter.
The Priority field specifies the priority of the host. Clients
attempt to contact the host with the lowest priority.
The Weight field is a load balancing mechanism. When the
priority field is the same for two or more records in the same
domain, clients should try records with higher weights more
often, unless the clients support some other load balancing
mechanism.

 The Port field shows the port of the service on this host.
The Target field shows the fully qualified domain name for
the host supporting the service.

Exchange Server roles

With Exchange Server Setup, you can deploy servers with specific roles
throughout the enterprise. Prior to setup and configuration, you need to
decide how you will use Exchange Server 2010, what roles you will deploy,
and where you will locate those roles. Afterward, you can plan for your

deployment and then roll out Exchange Server.

Exchange Server 2010 implementations have three layers in their
architecture: a network layer, a directory layer, and a messaging layer. The
messaging layer is where you define and deploy the Exchange Server roles.
The Exchange servers at the core of the messaging layer can operate in the
following roles:
Mailbox Server This is a back-end server that hosts mailboxes, public
folders, and related messaging data, such as address lists, resource
scheduling, and meeting items. For high availability of mailbox databases,
you can use database availability groups.
Client Access Server This is a middle-tier server that accepts connections
to Exchange Server from a variety of clients. This server hosts the protocols
used by all clients when checking messages. On the local network, Outlook
MAPI clients are connected directly to the Client Access server to check mail.
Remote users can check their mail over the Internet by using Outlook
Anywhere, Outlook Web App, Exchange ActiveSync, POP3, or IMAP4.
Unified Messaging Server This is a middle-tier server that integrates a
private branch exchange (PBX) system with Exchange Server 2010, allowing
voice messages and faxes to be stored with e-mail in a users mailbox.
Unified messaging supports call answering with automated greetings and
message recording, fax receiving, and dial-in access. With dial-in access,
users can use Outlook Voice Access to check voice mail, e-mail, and calendar
information; to review or dial contacts; and to configure preferences and
personal options. Note that to receive faxes, you need an integrated solution
from a Microsoft partner.
Hub Transport Server This is a mail routing server that handles mail flow,
routing, and delivery within the Exchange organization. This server
processes all mail that is sent inside the organization before it is delivered to
a mailbox in the organization or routed to users outside the organization.
Processing ensures that senders and recipients are resolved and filtered as
appropriate, content is filtered and has its format converted if necessary, and
attachments are screened. To meet any regulatory or organizational
compliance requirements, the Hub Transport server can also record, or
journal, messages and add disclaimers to them.

Edge Transport Server This serves as an additional mail routing server

that routes mail into and out of the Exchange organization. This server is
designed to be deployed in an organizations perimeter network and is used
to establish a secure boundary between the organization and the Internet.
This server accepts mail coming into the organization from the Internet and
from trusted servers in external organizations, processes the mail to protect
against some types of spam messages and viruses, and routes all accepted
messages to a Hub Transport server inside the organization.
These five roles are the building blocks of an Exchange organization. Note
that you can combine all of the roles except for the Edge Transport server
role on a single server. One of the most basic Exchange organizations you
can create is one that includes a single Exchange server that provides the
Mailbox server, Client Access server, and Hub Transport server roles. These
three roles are the minimum required for routing and delivering messages to
both local and remote messaging clients. For added security, you could
deploy the Edge Transport server role in a perimeter network on one or more
separate servers.

Exchange 2013 mailflow explained

Ive been playing with Exchange 2013 for a while now and overall I love all
the new features.

Lets take a closer look at mailflow architecture in Exchange 2013

The Exchange team calls the overall mailflow happening through a transport
pipeline. A transport pipeline is nothing but a collection of windows services,
some connections and some components and messages queues that act
together to make the overall email flow through the categorizer in the Hub
transport Service which now reside on the Mailbox server.
I thought of creating a chart to help you understand various services, where
they are homed and their function:
Server role
Service Name
Functions
Mailbox Server Hub Transport service Handles all incoming and outgoing SMTP email
Role
messages
Message content inspection
Message Categorization
Acts as a middle man and routes messages between
Mailbox
Transport service and the Front End Transport service
Is identical to the Hub Transport Server role in
Exchange 2010
Never contacts the mailbox databases directly
Accepts external messages from the front end
transport service
Mailbox Server Mailbox Transport
2 services treated like one Mailbox Transport
Role
service
Submission
service and Mailbox Transport Delivery service
The Mailbox Transport Delivery service receives
SMTP
messages from the Hub Transport service, and
connects to the mailbox database using an
Exchange remote procedure call (RPC) to deliver the
message
The Mailbox Transport Submission service connects
to the mailbox database using RPC to
retrieve messages, and submits the messages
over SMTP to the Hub Transport service

CAS Server
Role

Mailbox Transport service doesnt queue any

messages locally
Communicates directly with mailbox databases
Front End Transport Runs on all Client Access servers
service
Acts like a proxy for all inbound and outbound
external SMTP traffic
Can filter messages based on connections, domains,
senders, and recipients
Cannot read the message content
Only communicates with the Hub Transport service
Accepts external messages through a receive
connector

Messages inside the organization enter the Hub Transport service on a

Mailbox server in one of the following ways:

Through a Receive connector.

From the Pickup directory or the Replay directory.
From the Mailbox Transport service.
Through agent submission.
Every message thats sent or received in an Exchange 2013 Preview
organization must be categorized in the Hub Transport service on a Mailbox
server before it can be routed and delivered. After a message has been
categorized, its put in a delivery queue for delivery to the destination
mailbox database, the destination database availability group (DAG), Active
Directory site, or Active Directory forest, or to the destination domain outside
the organization.
The Hub Transport service on a Mailbox server consists of the following
components and processes:
SMTP Receive:
When messages are received by the Hub Transport service, message content
inspection is performed, transport rules are applied, and anti-spam and antimalware inspection is performed if they are enabled. The SMTP session has a
series of events that work together in a specific order to validate the
contents of a message before its accepted. After a message has passed

completely through SMTP Receive and isnt rejected by receive events, or by

an anti-spam and anti-malware agent, its put in the Submission queue.
Submission:
Submission is the process of putting messages into the Submission queue.
The categorizer picks up one message at a time for categorization.
Submission happens in three ways:
Through an SMTP Receive connector.
Through the Pickup directory or the Replay directory. These directories exist
on the Mailbox server. Correctly formatted message files that are copied into
the Pickup directory or the Replay directory are put directly into the
Submission queue.
Through an agent.
Categorizer:
The categorizer picks up one message at a time from the Submission queue.
The categorizer completes the following steps:
Recipient resolution, which includes top-level addressing, expansion, and
bifurcation.
Routing resolution.
Content conversion.
Additionally, mail flow rules that are defined by the organization are applied.
After messages have been categorized, theyre put into a delivery queue
thats based on the destination of the message. Messages are queued by the
destination mailbox database, DAG, Active Directory site, Active Directory
forest or external domain.
SMTP Send: How messages are routed from the Hub Transport service
depends on the location of the message recipients relative to the Mailbox
server where categorization occurred. The message could be routed to the
Mailbox Transport service on the same Mailbox server, the Mailbox Transport
service on a different Mailbox server thats part of the same DAG, the Hub
Transport service on a Mailbox server in a different DAG, Active Directory
site, or Active Directory forest, or to the Front End Transport service on a

Client Access server for delivery to the Internet.

Mail flow and the transport

pipeline
Understanding the transport pipeline
The transport pipeline consists of the following services:

Front End Transport service on Mailbox servers This service acts as a stateless
proxy for all inbound and (optionally) outbound external SMTP traffic for the
Exchange 2016 organization. The Front End Transport service doesn't inspect
message content, doesn't communicate with the Mailbox Transport service, and
doesn't queue any messages locally.

Transport service on Mailbox servers This service is virtually identical to the

Hub Transport server role in Exchange Server 2010. The Transport service handles all
SMTP mail flow for the organization, performs message categorization, and performs
message content inspection. Unlike Exchange 2010, the Transport service never
communicates directly with mailbox databases. That task is now handled by the
Mailbox Transport service. The Transport service routes messages among the Mailbox
Transport service, the Transport service, the Front End Transport service, and
(depending on your configuration) the Transport service on Edge Transport servers.
The Transport service on Mailbox servers is described in more detail later in this topic.

Mailbox Transport service on Mailbox servers This service consists of two

separate services:
o

Mailbox Transport Submission service This service connects to the local

mailbox database using an Exchange remote procedure call (RPC) to retrieve
messages. The service submits the messages over SMTP to the Transport
service on the local Mailbox server, or on other Mailbox servers. The Mailbox
Transport Submission service has access to the same routing topology
information as the Transport service.

Mailbox Transport Delivery service This service receives SMTP messages

from the Transport service on the local Mailbox server or on other Mailbox
servers, and connects to the local mailbox database using RPC to deliver the
messages.

The Mailbox Transport service doesn't communicate with the Front End Transport
service, doesn't communicate with the Mailbox Transport service or mailbox
databases on other Mailbox servers, and doesn't queue any messages locally.

Transport service on Edge Transport servers This service is very similar to the
Transport service on Mailbox servers. If you have an Edge Transport server installed in
the perimeter network, all mail coming from the Internet or going to the Internet
flows through the Transport service Edge Transport server. This service is described in
more detail later in this topic.

The following diagram shows the relationships among the components in the Exchange 2016
transport pipeline.
Overview of the transport pipeline in Exchange 2016.

Return to top

How messages from external senders enter the

transport pipeline
How messages from outside the Exchange organization enter the transport pipeline depends
on whether you have a subscribed Edge Transport server deployed in your perimeter
network.

Inbound mail flow (no Edge Transport servers)

Inbound mail flow with only Exchange 2016 Mailbox servers is described in the following
diagram and list.

1. A message from outside the organization enters the transport pipeline through the
default Receive connector named "Default Frontend <Mailbox server name>" in the
Front End Transport service.
2. The message is sent to the Transport service on the local Mailbox server, or on a
different Mailbox server. The Transport service listens for messages on the default
Receive connector named "Default<Mailbox server name>".
3. The message is sent from the Transport service to the Mailbox Transport Delivery
service on the local Mailbox server, or on a different Mailbox server.

4. The Mailbox Transport Delivery service uses RPC to deliver the message to the local
mailbox database.

Inbound mail flow with Edge Transport servers

Inbound mail flow with an Edge Transport server installed in the perimeter network is
described in the following diagram and list.

1. A message from outside the Exchange organization enters the transport pipeline
through the default Receive connector named "Default internal Receive

connector <Edge Transport server name>" in the Transport service on the Edge
Transport server.
2. In the Transport service on the Edge Transport server, the default Send connector
named "EdgeSync - Inbound to <Active Directory site name>" sends the message to
a Mailbox server in the subscribed Active Directory site.
3. In the Front End Transport service on the Mailbox server, the default Receive
connector named "Default Frontend <Mailbox server name>" accepts the message.
4. The message is sent from the Front End Transport service to the Transport service on
the local Mailbox server, or on a different Mailbox server. The Transport service listens
for messages on the default Receive connector named "Default <Mailbox server
name>".
5. The message is sent from the Transport service to the Mailbox Transport Delivery
service on the local Mailbox server, or on a different Mailbox server.
6. The Mailbox Transport Delivery service uses RPC to deliver the message to the local
mailbox database.
Return to top

How messages from internal senders enter the

transport pipeline
SMTP messages from inside the organization enter the transport pipeline through the
Transport service on a Mailbox server in one of the following ways:

Through a Receive connector.

From the Pickup directory or the Replay directory.

From the Mailbox Transport Submission service.

Through agent submission.

The message is routed based on the routing destination or delivery group.

Outbound mail flow (no Edge Transport servers)

By default, in a new Exchange 2016 organization, there's no Send connector that's
configured to send messages to the Internet. You need to create the Send connector
yourself. After you do that, Outbound mail flow is described in the following diagram and list.

1. The Mailbox Transport Submission service uses RPC to retrieve the outbound
message from the local mailbox database.
2. The Mailbox Transport Submission service uses SMTP to send the message to the
Transport service on the local Mailbox server, or on a different Mailbox server.
3. In the Transport service, the default Receive connector named "Default <Mailbox
server name>" accepts the message.

4. What happens next depends on the configuration of the Send connector:

o

Default The Transport service uses the Send connector you created to send
the message to the Internet.

Outbound proxy The Transport service uses the Send connector you
created to send the message to the Front End Transport service on the local
Mailbox server, or on a remote Mailbox server. In the Front End Transport
service, the default Receive connector named "Outbound Proxy
Frontend <Mailbox server name>" accepts the message. The Front End
Transport services sends the message to the Internet.

Outbound mail flow with Edge Transport servers

If you have an Edge Transport server installed in the perimeter network, outbound mail
never flows through the Front End Transport service. Outbound mail flow with an Edge
Transport server is described in the following diagram and list.

1. The Mailbox Transport Submission service uses RPC to retrieve the outbound
message from the local mailbox database.
2. The Mailbox Transport Submission service uses SMTP to send the message to the
Transport service on the local Mailbox server, or on a different Mailbox server.
3. In the Transport service on a Mailbox server in the subscribed Active Directory site,
the default Receive connector named "Default <Mailbox server name>" accepts the
message.
4. The message is sent to the Edge Transport server using the implicit and invisible
intra-organization Send connector that automatically sends mail between Exchange
servers in the same organization.

5. In the Transport service on the Edge Transport server, the default Receive connector
named "Default internal Receive connector <Edge Transport server name>" accepts
the message.
6. In the Transport service on the Edge Transport server, the default Send connector
named "EdgeSync - <Active Directory site name> to Internet" sends the message to
the Internet.
Return to top

Understanding the Transport service on Mailbox

servers
Every message that's sent or received in an Exchange 2016 organization must be
categorized in the Transport service on a Mailbox server before it can be routed and
delivered. After a message has been categorized, it's put in a delivery queue for delivery to
the destination mailbox database, the destination database availability group (DAG), Active
Directory site, or Active Directory forest, or to the destination domain outside the
organization.
The Transport service on a Mailbox server consists of the following components and
processes:

SMTP Receive When messages are received by the Transport service, message
content inspection is performed, transport rules are applied, and anti-spam and antimalware inspection is performed if they are enabled. The SMTP session has a series
of events that work together in a specific order to validate the contents of a message
before it's accepted. After a message has passed completely through SMTP Receive
and isn't rejected by receive events, or by an anti-spam or anti-malware agent, it's
put in the Submission queue.

Submission Submission is the process of putting messages into the Submission

queue. The categorizer picks up one message at a time for categorization.
Submission happens in three ways:

From SMTP Receive through a Receive connector.

Through the Pickup directory or the Replay directory. These directories exist on
Mailbox servers and Edge Transport servers. Correctly formatted message files
that are copied into the Pickup directory or the Replay directory are put
directly into the Submission queue.

Through a transport agent.

Categorizer The categorizer picks up one message at a time from the Submission
queue. The categorizer completes the following steps:

Recipient resolution, which includes top-level addressing, distribution group

expansion, and message bifurcation.

Routing resolution.

Content conversion.

Additionally, mail flow rules that are defined by the organization are applied. After
messages have been categorized, they're put into a delivery queue that's based on
the destination of the message. Messages are queued by the destination mailbox
database, DAG, Active Directory site, Active Directory forest, or external domain.

SMTP Send How messages are routed from the Transport service depends on the
location of the message recipients relative to the Mailbox server where categorization
occurred. The message could be routed to one of the following locations:
o

To the Mailbox Transport Delivery service on the same Mailbox server.

To the Mailbox Transport Delivery service on a different Mailbox server that's

part of the same DAG.

To the Transport service on a Mailbox server in a different DAG, Active

Directory site, or Active Directory forest.

For delivery to the Internet through:

A Send connector on the same Mailbox server.

The Transport service on a different Mailbox server.

The Front End Transport service on the same Mailbox server or a

different Mailbox server (if outbound proxy is configured).

The Transport service on an Edge Transport server in the perimeter

network.

Return to top

Understanding the Transport service on Edge

Transport servers
The components of the Transport service on Edge Transport servers are identical to the
components of the Transport service on Mailbox servers. However, what actually happens
during each stage of processing on Edge Transport servers is different. The differences are
described in the following list.

SMTP Receive When an Edge Transport server is subscribed to an internal Active

Directory site, the default Receive connector named "Default <Edge Transport server
name>" is automatically configured to accept mail from internal Mailbox servers and
from the Internet. When Internet messages arrive at the Edge Transport server, antispam agents filter connections and message contents, and help identify the sender
and the recipient while the message is being accepted into the organization. The
anti-spam agents are installed and enabled by default. Additional attachment filtering
and connection filtering features are available, but built-in malware filtering is not.
Also, transport rules are controlled by the Edge Rule agent. Compared to the
Transport Rule agent on Mailbox servers, only a small subset of transport rule
conditions are available on Edge Transport servers. But, there are unique transport
rule actions related to SMTP connections that are available only on Edge Transport
servers.

Submission On an Edge Transport server, messages typically enter the Submission

queue through a Receive connector. However, the Pickup directory and the Replay
directory are also available.

Categorizer On an Edge Transport server, categorization is a short process in which

the message is put directly into a delivery queue for delivery to internal or external
recipients.

SMTP Send When an Edge Transport server is subscribed to an internal Active

Directory site, two Send connectors are automatically created and configured. One
named "EdgeSync - <Active Directory site name> to Internet" is responsible for
sending outbound mail to Internet recipients; the other named "EdgeSync - Inbound
to <Active Directory site name>" is responsible for sending inbound mail from the
Internet to internal recipients. Inbound mail is sent to the Front End Transport service
on an available Mailbox server in the subscribed Active Directory site.

Troubleshooting outlook Email Issues

1. Double Check your Outlook/Outlook Express Settings:

- Open Outlook/Outlook Express

- Click on Tools -> Accounts
- Click on Mail tab - you'll see the list of email accounts that are setup

- to view info and settings for each email account, double click on an
email account.

- Click (highlight) the extra or duplicate email accounts that you are
not using and click on Remove button (on the right)

- Click on General tab, Servers tab, Advanced tab, accordingly and

check your Outlook settings against the following examples:
(Click to enlarge)

2. Check the Spelling of account settings

- Double Check the spelling of each account setting, domain name,

account name (is the email address complete), Outgoing Mail, Incoming
Mail, etc.

3. Passwords are case sensitive

- Make sure that you do not have CAP LOCK on - passwords are
case sensitive.

4. Do you have an email with a problem recipient stuck in your

Outbox?

- Click on your Outbox and see if there are any email messages stuck
in there. If so, either click and move the message(s) to the Draft folder or
right click and delete the message(s) that are left in your Outbox.

5. Make sure to click on Send/Recv button:

- Our mail server requires you to login to check your email before
sending email (for spam protection) and clicking on Send/Recv button
just does that.

6. If you can receive but can not send:

- Double Check your Outgoing Mail (SMTP) setting - use the above
instructions (1.)

- Which company is your Internet connection provider? You usually

use your Internet connection provider's Outgoing Mail (SMTP) setting
when sending email.

- You'll need to contact your Internet connection provider to verify

your Outgoing Mail (SMTP) setting.

- For an example of Outgoing Mail (SMTP) setting for Outlook

Express for users who are using the SBC DSL connection, click here
7. If you can send but can not receive:

- Double Check your Incoming Mail (POP3) settings (Use the above
instructions)

- A common mistake: For Servers setting (Servers tab), -> Account

Name make sure that you use the full email address and not just the first
part of the email address - for example: janedoe@comentum.com and
not just "janedoe"

- Login to your Web Mail and Delete any suspicious email that can
block your Mailbox. (emails that have no "From" or corrupted spam
emails can cause Outlook/Outlook Express to hang.
8. Double check your Internet connection:

- Double Check your Internet connection. Make sure you can browse
web sites.

9. Restart your computer:

- Sometimes, just restarting your computer may solve your email

problem.
(Outlook/Outlook Express uses a special file to connect/send/receive
email. Sometimes the file will need to be rebuilt and restarting the
computer may simply rebuild the problem Outlook files.)

10. Check your domain's expiration date:

- Click here to check your domain name's expiration. Some of the

domain name registrar companies will turn off your domain as soon as
your domain expires.

11. Did you just install a new Firewall/Anti-Virus/Anti-Spam Software

or change the settings on an existing Firewall/Anti-Virus/Anti-Spam
Software?

- There are many reported issues on newly installed or existing

Firewall/Anti-Virus/Anti-Spam softwares which are misconfigured and are
causing problems sending and receiving emails. You may want to disable
these types of software in your computer temporarily to see if your email
problems go away. If this fixes your issue, try updating/re-installing or reconfiguring your Firewall/Anti-Virus/Anti-Spam software correctly.

12. Write down the error message and number (error# example:
0x800ccc15) and do a Google/Yahoo/MSN search on the error#:

- If you type the error# or part of the error message in

Google/Yahoo/MSN search, you will find hundreds of results and
solutions to your specific email issues.

13. Email messages will stop downloading at a particular message or

keeps downloading the same messages over and over:

- This is an issue with the older version of Outlook/Outlook Express. A

corrupted message stuck in your Mailbox on our server will cause
Outlook/Outlook Express to hang or keep downloading the same

message. Login to your Web Mail and delete all of the suspicious
messages. Also try to upgrade your Outlook/Outlook Express.

Active Directory Federation Services (ADFS)

is a software component developed by Microsoft that can be installed on Windows

Server operating systems to provide users with single sign-on access to systems and
applications located across organizational boundaries. It uses a claims-based access
control authorization model to maintain application security and implement federated
identity.
Claims-based authentication is the process of authenticating a user based on a set of
claims about its identity contained in a trusted token.
In ADFS, identity federation is established between two organizations by establishing
trust between two security realms. A federation server on one side (the Accounts side)
authenticates the user through the standard means in Active Directory Domain Services
and then issues a token containing a series of claims about the user, including its
identity. On the other side, the Resources side, another federation server validates the
token and issues another token for the local servers to accept the claimed identity. This
allows a system to provide controlled access to its resources or services to a user that
belongs to another security realm without requiring the user to authenticate directly to
the system and without the two systems sharing a database of user identities or
passwords.
In practice this approach is typically perceived by the user as follows:
1.

The user logs into their local PC (as they typically would when commencing work
in the morning)

2.

The user needs to obtain information on a partner company's extranet website for example to obtain pricing or product details

3.

The user navigates to the partner company extranet site - for

example: http://example.com

4.

The partner website now does not require any password to be typed in - instead,
the user credentials are passed to the partner extranet site using AD FS

5.

The user is now logged into the partner website and can interact with the website
'logged in'