Configuring Active Directory Manual Authentication and SSO for BI4
Configuring the Active Directory Infrastructure
-
Upload
rodrigobenica -
Category
Documents
-
view
125 -
download
1
Transcript of Configuring the Active Directory Infrastructure
Configuring the Active Directory infrastructure
Configure a forest or a domain
Requirements for Installing AD DSUpdated: July 14, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
For Windows Server 2008 hardware requirements, see Installing Windows Server 2008 at http://go.microsoft.com/fwlink/?LinkId=111104.
The following software and hardware requirements apply to a full installation or a Server Core installation of the Windows Server 2008 or Windows Server 2008 R2 operating system. For information about configuring a Server Core installation, see Server Core Installation of Windows Server 2008 Step-By-Step Guide (http://go.microsoft.com/fwlink/?LinkId=87786).
Install Windows Server 2008 or Windows Server 2008 R2.
Verify that a Domain Name System (DNS) infrastructure is in place. Before you add
Active Directory Domain Services (AD DS) to create a domain or forest, be sure that a DNS
infrastructure is in place on your network. When you install AD DS, you can include DNS server
installation, if it is needed. When you create a new domain, a DNS delegation is created
automatically during the installation process.
If a DNS infrastructure is not in place when you install an additional domain controller in a
domain, then the option to install DNS server on that domain controller will not be available.
Configure appropriate TCP/IP and DNS server addresses.
Verify that Adprep.exe operations are complete. Before you can add AD DS to a server that is
running Windows Server 2008 or Windows Server 2008 R2 in an existing Active Directory
environment, you must prepare the environment by running Adprep.exe. For more information
about running Adprep.exe, see Running Adprep.exe.
Note
In Windows Server 2008, Adprep.exe is available in the /sources/adprep folder of the installation DVD. In Windows Server 2008 R2, Adprep.exe is located in the /support/adprep folder.
In order to install a read-only domain controller (RODC), there must be a writable domain
controller running Windows Server 2008 or Windows Server 2008 R2 in the domain. The Active
Directory Domain Services Installation Wizard makes a DC Locator call during forest
examination with specific options to find a writable domain controller (using the
DS_WRITABLE_REQUIRED flag) that runs Windows Server 2008 or Windows Server 2008 R2
(using the DS_DIRECTORY_SERVICE_6_REQUIRED flag). If the call succeeds and a domain
controller that matches these options is found, the check box to install an RODC is enabled. For
more information about these options, see DsGetDcName Function
(http://go.microsoft.com/fwlink/?LinkId=100509).
When you use an answer file to perform an unattended installation of AD DS, specify a
[DCINSTALL] section in the answer file with appropriate parameters. For a list of entries for the
[DCINSTALL] section of the answer file, see Appendix of Unattended Installation Parameters.
The drives that store the database, log files, and SYSVOL folder for Active Directory Domain
Services (AD DS) must be placed on a local fixed volume. SYSVOL must be placed on a volume
that is formatted with the NTFS file system. For security purposes, the Active Directory database
and log files should be placed on a volume that is formatted with NTFS.
Traditionally, the Active Directory database and log files are placed on disk drives that are
physically local to the domain controller computer. As an option, you can place the
Active Directory database and log files on a nonlocal storage device if the device appears to be
“local” to the GetDriveType function that Dcpromo.exe uses and it does not have advanced
rollback, undo, or snapshot features enabled. For more information about the GetDriveType
function, see GetDriveType Function (http://go.microsoft.com/fwlink/?LinkId=102448).
You must perform all backups and restores of AD DS, including rolling the contents of AD DS
“back in time,” by using system state backups that are created by supported backup application
programming interfaces (APIs) and methods.
Steps for Installing AD DSUpdated: January 5, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
The following sections provide step-by-step instructions for installing Active Directory Domain Services (AD DS) in all configurations, including instructions for installing it on a full installation or a Server Core installation of Windows Server 2008 or Windows Server 2008 R2. These sections provide the Windows interface, command-line, and answer file methods for performing installations.
The process for performing an unattended installation of AD DS is the same for a server that is running a full installation or a Server Core installation. The unattended method of installation is required for a Server Core installation.
Procedures for installing AD DS are provided for the following scenarios:
Installing a New Forest
Installing a New Child Domain
Installing a New Domain Tree
Installing an Additional Domain Controller
Performing a Staged RODC Installation
Installing AD DS from Media
Verifying an AD DS Installation
AD DS Installation and Removal Step-by-Step GuideUpdated: January 5, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
Active Directory® Domain Services (AD DS) is a server role of the Windows Server® 2008 and Windows Server 2008 R2 operating systems. AD DS provides a distributed directory service that you can use for centralized, secure management of your network.
This guide describes the installation and removal processes for the AD DS server role. You can use the procedures in this guide to install and remove AD DS on servers that are running Windows Server 2008 or Windows Server 2008 R2 in a test lab environment.
In this guide
What's New in AD DS Installation and Removal
Known Issues for Installing and Removing AD DS
Scenarios for Installing AD DS
Scenarios for Removing AD DS
Requirements for Installing AD DS
Steps for Installing AD DS
Steps for Removing AD DS
Appendix of Unattended Installation Parameters
Appendix of Functional Level Features
Windows Server 2008: Appendix of Changes to Adprep.exe to Support AD DS
Windows Server 2008 R2: Appendix of Changes to Adprep.exe to Support AD DS
Publication and revision history
The following table summarizes the revision history for this guide, including its original publication on Microsoft TechNet.
Date Revision
April 2006
Original publication on Technet
January 2009
This guide was amended to refer to Windows Server 2008 R2 in addition to
Windows Server 2008.
In Forcing the Removal of a Domain Controller, examples were added to show
how to forcefully remove AD DS in an unattended operation. This operation may
be required if you must forcefully remove AD DS from a Server Core installation of
Windows Server 2008 or Windows Server 2008 R2.
Steps for Removing AD DSUpdated: January 5, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
The following sections provide step-by-step instructions for removing Active Directory Domain Services (AD DS) in all configurations, including methods for removing the server role on both a full installation
and a Server Core installation. These instructions apply to Windows Server 2008 and Windows Server 2008 R2. These methods use the Windows interface, an answer file, and the command line.
The unattended methods of removing AD DS are required for Server Core installations. The process for performing an unattended removal of AD DS is the same for a server that is running a full installation or a Server Core installation.
Procedures for removing AD DS are provided for the following scenarios:
Removing a Domain Controller from a Domain
Removing the Last Domain Controller in a Domain
Removing the Last Domain Controller in a Forest
Forcing the Removal of a Domain Controller
Appendix of Unattended Installation ParametersUpdated: January 5, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
The tables in this appendix provide the information that you need to create an answer file for automating the installation or removal of AD DS:
Promotion Operation
CreateDCAccount Operation
UseExistingAccount Operation
Demotion Operation
Unattended Installation Return Codes
Dcpromo.exe accepts these parameters either directly from the command line or as entered in a text file that is formatted in standard .INI format. The text file must contain a section heading [DCINSTALL] followed by AD DS (domain controller) server role unattended installation parameters.
Create a text file that contains the [DCINSTALL] heading and in which each line in the file contains an option and its value in the form option=value. To use the options directly from the command line, precede each option:value pair with a forward slash (/) and separate each /option=value pair with a space. At the command line, you can also use a colon (:) to separate the option and the value (/option:value).
The following are example lines in an answer text file:
[DCINSTALL]
UserName=Jsmith
Password=*
SiteName=NorthRegion
The following is an example set of the same options as typed in the Dcpromo.exe command line:
dcpromo /unattend /username:Jsmith /password:* /sitename:NorthRegion ...
Scenarios for Installing AD DSUpdated: January 14, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
The following installation scenarios for Active Directory Domain Services (AD DS) are described in this guide. In these scenarios, the new domain controllers can be running Windows Server 2008 or Windows Server 2008 R2 and existing domain controllers can be running Windows Server 2003 or Windows 2000 Server.
Install a new forest
Install a new domain in an existing forest
Install a new domain controller in an existing domain
Performing a staged RODC installation
Install AD DS from media
Verify AD DS installations
Install a new forest
When you install AD DS to create the first domain controller in a new forest, keep the following considerations in mind:
You must make forest and domain functional level decisions that determine whether your forest
and domain can contain domain controllers that run Microsoft Windows® 2000 Server,
Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.
Domain controllers running the Microsoft Windows NT® Server 4.0 operating system are not
supported with Windows Server 2008 or Windows Server 2008 R2.
Servers running Windows NT Server 4.0 are not supported by domain controllers that are
running Windows Server 2008 or Windows Server 2008 R2.
The first domain controller in a forest must be a global catalog server and it cannot be an RODC.
Install a new domain in an existing forest
When you install AD DS to create the first domain controller in a new domain, keep the following considerations in mind:
Before you create a new Windows Server 2008 or Windows Server 2008 R2 domain in a
Windows 2000 Server or Windows Server 2003 forest, you must prepare the forest for Windows
Server 2008 or Windows Server 2008 R2 by extending the schema (that is, by running
adprep /forestprep).
Note
In Windows Server 2008, Adprep.exe is available in the /sources/adprep folder of the installation DVD. In Windows Server 2008 R2, Adprep.exe is located in the /support/adprep folder.
You must make domain functional level decisions that determine whether your domain can
contain domain controllers that run Windows 2000 Server, Windows Server 2003, Windows
Server 2008.
We recommend that you host the primary domain controller (PDC) emulator operations master role in the forest root domain on a domain controller that runs Windows Server 2008.
For procedures to install a new domain, see Installing a New Child Domain.
Install a new domain controller in an existing domain
When you install a new Windows Server 2008 or Windows Server 2008 R2 domain controller in an existing Windows 2000 Server or Windows Server 2003 domain, keep the following considerations in mind:
If this domain controller is the first Windows Server 2008 or Windows Server 2008 R2 domain
controller in the forest, you must prepare the forest for Windows Server 2008 or Windows
Server 2008 R2 by extending the schema (that is, by running adprep /forestprep) on the
schema operations master if this has not already been done.
Note
In Windows Server 2008, Adprep.exe is available in the /sources/adprep folder of the installation DVD. In Windows Server 2008 R2, Adprep.exe is located in the /support/adprep folder.
If this domain controller is the first Windows Server 2008 or Windows Server 2008 R2 domain
controller in a Windows 2000 Server domain, you must first prepare the domain by running
adprep /domainprep /gpprep on the infrastructure master.
Note
If you prepare a Windows Server 2003 domain by running adprep /domainprep /gpprep, you can safely disregard the error message that indicates that domain updates were not necessary.
If this domain controller is the first Windows Server 2008 or Windows Server 2008 R2 domain
controller in a Windows Server 2003 domain, you must prepare the domain by running
adprep /domainprep on the infrastructure master.
Before you can install an RODC in a Windows 2000 Server or Windows Server 2003 forest, you
must prepare the forest by running adprep /rodcprep. You can run adprep /rodcprep on any
computer in the forest. You can run it multiple times if necessary. If the operation is unable to
reach all the application partitions that must be updated to allow RODC installation, you receive
a message that says that not all application partitions have been updated. In this case, rerun
the adprep /rodcprep command.
The first Windows Server 2008 or Windows Server 2008 R2 domain controller in an existing
Windows 2000 Server or Windows Server 2003 domain cannot be created as an RODC. After a
Windows Server 2008 or Windows Server 2008 R2 domain controller exists in the domain,
additional Windows Server 2008 or Windows Server 2008 R2 domain controllers can be created
as RODCs.
After you have prepared the forest and the domain, you can install AD DS to create a new Windows Server 2008 or Windows Server 2008 R2 domain controller.
For procedures to install a new domain controller, see Installing an Additional Domain Controller.
Perform a staged RODC installation
AD DS provides a way for you to install an RODC in a branch office in two stages. First, you create an account for the RODC. When you create the account, you can choose who will install and administer the RODC. The delegated RODC administrator can complete the installation by attaching a server to the RODC account you created for it. This eliminates the need to use a staging site for building branch office domain controllers and also eliminates the need to use domain administrator credentials to build the RODC in the branch office.
When you install an RODC, keep the following considerations in mind:
The RODC must replicate domain data from a writeable domain controller that runs Windows
Server 2008 or Windows Server 2008 R2.
By default, the RODC does not cache the passwords of any domain users. This means that by
default, user and computer authentications that are handled by an RODC still require
connectivity to a writeable domain controller that runs Windows Server 2008 or Windows
Server 2008 R2. You must modify the default Password Replication Policy (PRP) for the RODC to
allow the RODC to authenticate users and their computers when the wide area network (WAN)
link to the writeable domain controller is offline.
For more information about how the authentication process works with an RODC, see Appendix
A: Technical Reference Topics (http://go.microsoft.com/fwlink/?LinkID=128273). For more
information about how to modify the PRP, see Administering the Password Replication Policy
(http://go.microsoft.com/fwlink/?LinkId=137087).
Install AD DS from media
You can use the install from media (IFM) option to install an additional domain controller in an existing domain and minimize replication traffic during the installation. Windows Server 2008 and Windows Server 2008 R2 include an improved version of Ntdsutil.exe that you can use to create the installation media.
You can also create installation media by using the Windows Server Backup tool in Windows Server 2008 or Windows Server 2008 R2. In this case, you need to use the wbadmin command-line tool option to create the system state backup and then you need to restore system state backup to an alternate location.
However, you should use Ntdsutil.exe because the system state backup includes data, such as the registry, that is not required for AD DS installation.
For the procedure to install a new domain controller from media that is created by using Ntdsutil.exe, see Installing AD DS from Media.
Verify AD DS installations
After you install a domain controller, you can take the following steps to verify the AD DS installation:
Check the Directory Service log in Event Viewer for errors.
Make sure that the SYSVOL folder is accessible to clients.
Verify DNS functionality.
Verify replication.
Appendix of Functional Level FeaturesUpdated: December 21, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
The following sections explain the sets of features that are available at the different functional levels, including new domain and forest functional levels for Windows Server 2008 R2.
Features that are enabled at domain functional levels
The following table shows which features are enabled at each domain functional level. It also shows the operating systems for domain controllers that are supported at each functional level.
Important
After you set the domain functional level to a certain value in Windows Server 2008 R2, you cannot roll back or lower the domain functional level, with one exception: when you raise the domain functional level to Windows Server 2008 R2 and if the forest functional level is Windows Server 2008 or lower, you have the option of rolling the domain functional level back to Windows Server 2008. You can lower the domain functional level only from Windows Server 2008 R2 to Windows Server 2008. If the domain functional level is set to Windows Server 2008 R2, it cannot be rolled back, for example, to Windows Server 2003. With versions of Windows Server that are earlier than Windows Server 2008 R2, you cannot roll back or lower a domain functional level under any circumstances.
Domain functional level Enabled features
Supported domain controller operating systems
Windows 2000 native
All default Active Directory features and the following features:
Universal groups are enabled for both distribution
groups and security groups.
Group nesting.
Group conversion is enabled, which makes conversion
between security groups and distribution groups
possible.
Security identifier (SID) history.
Windows Server 2008 R2Windows Server 2008Windows Server 2003Windows 2000
Windows Server 2003
All default Active Directory features, all features from the Windows 2000 native domain functional level, and the following features:
The availability of the domain management tool,
Netdom.exe, to prepare for domain controller rename.
Update of the logon time stamp. The
lastLogonTimestamp attribute will be updated with
the last logon time of the user or computer. This
attribute is replicated within the domain.
The ability to set the userPassword attribute as the
effective password on inetOrgPerson and user
objects.
The ability to redirect Users and Computers containers.
By default, two well-known containers are provided for
housing computer and user/group accounts: namely,
cn=Computers,<domain root> and cn=Users,<domain
root>. This feature makes possible the definition of a
new well-known location for these accounts.
Makes it possible for Authorization Manager to store its
Windows Server 2008 R2Windows Server 2008Windows Server 2003
authorization policies in Active Directory Domain
Services (AD DS).
Includes constrained delegation so that applications can
take advantage of the secure delegation of user
credentials by means of the Kerberos authentication
protocol. Delegation can be configured to be allowed
only to specific destination services.
Supports selective authentication, through which it is
possible to specify the users and groups from a trusted
forest who are allowed to authenticate to resource
servers in a trusting forest.
Windows Server 2008
All default Active Directory features, all features from the Windows Server 2003 domain functional level, and the following features:
Distributed File System (DFS) Replication support for
SYSVOL, which provides more robust and detailed
replication of SYSVOL contents.
Advanced Encryption Services (AES 128 and 256)
support for the Kerberos authentication protocol.
Last Interactive Logon Information, which for a
workstation that runs Windows Server 2008 or
Windows Vista or later, displays the times of the last
successful and failed logons, and the number of failed
logon attempts since the last successful logon. For more
information, see Active Directory Domain Services: Last
Interactive Logon (http://go.microsoft.com/fwlink/?
LinkId=180387).
Fine-grained password policies (FGPP), which make it
possible for password and account lockout policies to be
specified for users and global security groups in a
domain.
Windows Server 2008 R2Windows Server 2008
Windows Server 2008 R2
All default Active Directory features, all features from the Windows 2000 native, Windows Server 2003, and Windows Server 2008 functional levels, plus the following features:
Authentication mechanism assurance, which packages
information about the type of logon method (smart card
or user name/password) that is used to authenticate
domain users inside each user’s 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
Windows Server 2008 R2
determine authorization based on a user’s logon, and
the total number of failed logon attempts.
Automatic SPN management for services running on a
particular machine under the context of a Managed
Service Account when the name or DNS host name of
the machine computer account changes.
Features that are enabled at forest functional levels
The following table shows which features are enabled at each forest functional level. It also shows the operating systems for domain controllers that are supported at each functional level.
Important
After you set the forest functional level to a certain value in Windows Server 2008 R2, you cannot roll back or lower the forest functional level, with one exception: when you raise the forest functional level to Windows Server 2008 R2 and if Active Directory Recycle Bin is not enabled, you have the option of rolling the forest functional level back to Windows Server 2008. For more information about the Active Directory Recycle Bin, see What's New in AD DS: Active Directory Recycle Bin (http://go.microsoft.com/fwlink/?LinkId=141392). You can lower the forest functional level only from Windows Server 2008 R2 to Windows Server 2008. If the forest functional level is set to Windows Server 2008 R2, it cannot be rolled back, for example, to Windows Server 2003. With versions of Windows Server that are earlier than Windows Server 2008 R2, you cannot roll back or lower a forest functional level under any circumstances.
Forest functional level Enabled features
Supported domain controllers
Windows 2000 All default Active Directory features. Windows Server 2008 R2Windows Server 2008Windows Server 2003Windows 2000
Windows Server 2003
All default Active Directory features, and the following features:
Forest trust.
Domain rename.
Linked-value replication (changes in group
membership store and replicate values for individual
members instead of replicating the entire membership
as a single unit). This change results in lower network
bandwidth and processor usage during replication and
eliminates the possibility of lost updates when
different members are added or removed concurrently
at different domain controllers.
The ability to deploy a read-only domain controller
(RODC) that runs Windows Server 2008.
Windows Server 2008 R2Windows Server 2008Windows Server 2003
Improved Knowledge Consistency Checker (KCC)
algorithms and scalability. The Intersite Topology
Generator (ISTG) uses improved algorithms that scale
to support forests with a greater number of sites than
can be supported at the Windows 2000 forest
functional level. The improved ISTG election algorithm
is a less intrusive mechanism for choosing the ISTG at
the Windows 2000 forest functional level.
An improved ISTG algorithm (better scaling of the
algorithm that the ISTG uses to connect all sites in the
forest).
The ability to create instances of the dynamic auxiliary
class called dynamicObject in a domain directory
partition.
The ability to convert an inetOrgPerson object
instance into a User object instance, and the reverse.
The ability to create instances of the new group types,
called application basic groups and Lightweight
Directory Access Protocol (LDAP) query groups, to
support role-based authorization.
Deactivation and redefinition of attributes and classes
in the schema.
Windows Server 2008
All the features that are available at the Windows Server 2003 forest functional level, but no additional features. All domains that are subsequently added to the forest, however, will operate at the Windows Server 2008 domain functional level by default.
Windows Server 2008 R2Windows Server 2008
Windows Server 2008 R2
All the features that are available at the Windows Server 2003 forest functional level, plus the following feature:
Active Directory Recycle Bin, which provides the ability
to restore deleted objects in their entirety while
Active Directory Domain Services (AD DS) is running.
All domains that are subsequently added to the forest will operate at the Windows Server 2008 R2 domain functional level by default.If you plan to include only domain controllers that run Windows Server 2008 R2 in the entire forest, you might choose this forest functional level for administrative convenience. If you do, you will never have to raise the domain functional level for each domain that you create in the forest.
Windows Server 2008 R2
Configure trusts
Managing TrustsYou can use Active Directory Domains and Trusts to manage domain trusts.
Understanding Trusts
Trusts A trust is a relationship, which you establish between domains, that makes it possible for users
in one domain to be authenticated by a domain controller in the other domain. Trusts in Windows NT In the Windows NT 4.0 operating system, trusts are limited to two domains, and the trust
relationship is nontransitive and one-way. In the following illustration, the nontransitive, one-way trust is shown by the straight arrow pointing to the trusted domain.
Trusts in Windows 2000 Server, Windows Server 2003, and Windows Server 2008 operating systems
All trusts in Windows 2000 Server, Windows Server 2003, and Windows Server 2008 forests are transitive, two-way trusts. Therefore, both domains in a trust relationship are trusted. As shown in the following illustration, this means that if Domain A trusts Domain B and Domain B trusts Domain C, users from Domain C can access resources in Domain A (when they are assigned the proper permissions). Only members of the Domain Admins group can manage trust relationships.
Trust protocols A domain controller running Windows Server 2008 authenticates users and applications using
one of two protocols: the Kerberos version 5 (V5) protocol or NTLM. The Kerberos V5 protocol is the default protocol for computers running Windows 2000, Windows XP Professional, Windows Server 2003, or Windows Server 2008. If any computer in a transaction does not support the Kerberos V5 protocol, the NTLM protocol is used.
With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account domain to the server in the trusting domain. This ticket is issued by an intermediary that is trusted by the client and the server. The client presents this trusted ticket to the server in the trusting domain for authentication. For more information, see Kerberos V5 authentication (http://go.microsoft.com/fwlink/?LinkId=81795).
When a client tries to access resources on a server in another domain using NTLM authentication, the server that contains the resource must contact a domain controller in the client account domain to verify the account credentials.
Trusted domain objects Trusted domain objects (TDOs) are objects that represent each trust relationship within a
particular domain. Each time that a trust is established, a unique TDO is created and stored in its domain (in the System container). Attributes such as trust transitivity, type, and the reciprocal domain names are represented in the TDO.
Forest trust TDOs store additional attributes to identify all the trusted namespaces from its partner forest. These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security identifier (SID) namespaces.
For more information about domain trusts, see Trust Technologies (http://go.microsoft.com/fwlink/?LinkId=92695). For more information about trust relationships, see Designing a Resource Authorization Strategy (http://go.microsoft.com/fwlink/?LinkId=92696).
Understanding Trust Types
Trust Types
You can use the New Trust Wizard or the Netdom command-line tool to create four types of trusts: external trusts, realm trusts, forest trusts, and shortcut trusts. The following table describes these trust types.
Trust type Transitivity Direction Description
External Nontransitive One-way or two-way
Use external trusts to provide access to resources that are located on a Windows NT 4.0 domain or a domain that is located in a separate forest that is not joined by a forest trust. For more information, see Understanding When to Create an External Trust.
Realm Transitive or nontransitive
One-way or two-way
Use realm trusts to form a trust relationship between a non-Windows Kerberos realm and a Windows Server 2008 domain. For more information, see Understanding When to Create a Realm Trust.
Forest Transitive One-way or two-way
Use forest trusts to share resources between forests. If a forest trust is a two-way trust, authentication requests that are made in either forest can reach the other forest. For more information, see Understanding When to Create a Forest Trust.
Shortcut Transitive One-way or two-way
Use shortcut trusts to improve user logon times between two domains within a Windows Server 2008 forest. This is useful when two domains are separated by two domain trees. For more information, see Understanding When to Create a Shortcut Trust.
When you create external trusts, shortcut trusts, realm trusts, or forest trusts, you have the option to create each side of the trust separately or both sides of a trust simultaneously.
If you choose to create each side of the trust separately, you must run the New Trust Wizard twice—once for each domain. When you create trusts using the method, you must supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords. For more information, see Strong passwords (http://go.microsoft.com/fwlink/?LinkId=92697).
If you choose to create both sides of the trust simultaneously, you run the New Trust Wizard once. When you choose this option, a strong trust password is automatically generated for you. You must have the appropriate administrative credentials for the domains between which you are creating the trust.
For more information about trusts, see Understanding Trust Transitivity and Understanding Trust Direction.
Understanding Trust Direction
Trust Direction
The trust type and its assigned direction affect the trust path that is used for authentication. A trust path is a series of trust relationships that authentication requests must follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running Windows Server 2008 must determine whether the trusting domain (the domain that contains the resource that the user is trying to access) has a trust relationship with the trusted domain (the user's logon domain). To determine this, the security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. In the following illustration, the trust path is indicated by an arrow that shows the direction of the trust.
All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain.
One-way trust
A one-way trust is a unidirectional authentication path that is created between two domains. This means that in a one-way trust between Domain A and Domain B, users in Domain A can access resources in Domain B. However, users in Domain B cannot access resources in Domain A. Some one-way trusts can be either a nontransitive trust or a transitive trust, depending on the type of trust that is created. For more information about trust types, see Understanding Trust Types.
Two-way trust
All domain trusts in a Windows Server 2008 forest are two-way, transitive trusts. When a new child domain is created, a two-way, transitive trust is automatically created between the new child domain and the parent domain. In a two-way trust, Domain A trusts Domain B and Domain B trusts Domain A. This means that authentication requests can be passed between the two domains in both directions. Some two-way relationships can be either nontransitive or transitive, depending on the type of trust that is created. For more information, see Understanding Trust Types.
A Windows Server 2008 domain can establish one-way or two-way trusts with the following domains and realms:
Windows Server 2008 domains in the same forest
Windows Server 2008 domains in a different forest
Windows Server 2003 domains in the same forest
Windows Server 2003 domains in a different forest
Windows Server 2000 domains in the same forest
Note
Support for Windows 2000 ends July 13, 2010. For more information see, Windows 2000 End-of-Support Solution Center (http://go.microsoft.com/fwlink/?LinkId=184536)
Windows Server 2000 domains in a different forest
Kerberos version 5 (V5) realms
For more information about the Kerberos V5 protocol, see Kerberos V5 authentication (http://go.microsoft.com/fwlink/?LinkId=92699).
Understanding Trust Transitivity
Trust transitivity
Transitivity determines whether a trust can be extended outside the two domains between which the trust was formed. You can use a transitive trust to extend trust relationships with other domains. You can use a nontransitive trust to deny trust relationships with other domains.
Transitive trust
Each time that you create a new domain in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. If child domains are added to the new domain, the trust path flows upward through the domain hierarchy, extending the initial trust path that is created between the new domain and its parent domain.
Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree.
Authentication requests follow these trust paths. Therefore, accounts from any domain in the forest can be authenticated at any other domain in the forest. With a single logon process, accounts with the proper permissions can access resources in any domain in the forest.
In addition to the default transitive trusts that are established in a Windows Server 2008 forest, by using the New Trust Wizard you can manually create the following transitive trusts:
Shortcut trust: A transitive trust between a domain in the same domain tree or forest that
shortens the trust path in a large and complex domain tree or forest.
Forest trust: A transitive trust between a forest root domain and a second forest root domain.
Realm trust: A transitive trust between an Active Directory domain and a Kerberos V5 realm.
For more information about Kerberos V5 realms, see Kerberos V5 authentication
(http://go.microsoft.com/fwlink/?LinkId=92699).
The following illustration shows a two-way, transitive trust relationship between the Domain A tree and the Domain 1 tree. All domains in the Domain A tree and all domains in the Domain 1 tree have transitive trust relationships by default. As a result, users in the Domain A tree can access resources in domains in the Domain 1 tree, and users in the Domain 1 tree can access resources in the Domain A tree when the proper permissions are assigned at the resource.
For more information about trust types, see Understanding Trust Types.
Nontransitive trust
A nontransitive trust is restricted by the two domains in the trust relationship. It does not flow to any other domains in the forest. A nontransitive trust can be a two-way trust or a one-way trust. Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-way trusts.
In summary, nontransitive domain trusts are the only form of trust relationship that is possible between the following:
A Windows Server 2008 domain and a Windows NT domain
A Windows Server 2008 domain in one forest and a domain in another forest (when the forests
are not joined by a forest trust)
You can use the New Trust Wizard to manually create the following nontransitive trusts:
External trust: A nontransitive trust between a Windows Server 2008 domain and a
Windows NT domain or a Windows 2000 domain, Windows Server 2003 domain, or Windows
Server 2008 domain in another forest.
Realm trust: A nontransitive trust between an Active Directory domain and a Kerberos
version 5 (V5) realm. For more information about Kerberos V5 realms, see Kerberos V5
authentication (http://go.microsoft.com/fwlink/?LinkId=92699).
Understanding When to Create an External Trust
When to create an external trust You can create an external trust to form a one-way or two-way, nontransitive trust with domains
that are outside your forest. External trusts are sometimes necessary when users need access to resources in a Windows NT 4.0 domain or in a domain that is located in a separate forest that is not joined by a forest trust, as shown in the following illustration.
When you establish a trust between a domain in a particular forest and a domain outside that forest, security principals from the external domain can access resources in the internal domain. Active Directory Domain Services (AD DS) creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside the forest.
Directory objects for foreign security principals are created by AD DS, and they should not be modified manually. You can view foreign security principal objects in the Active Directory Users and Computers snap-in by enabling advanced features. (On the View menu, click Advanced Features.)
For more information about how to create an external trust, see Create an External Trust.
Understanding When to Create a Shortcut Trust
When to create a shortcut trust
Shortcut trusts are one-way or two-way, transitive trusts that administrators can use to optimize the authentication process.
Authentication requests must first travel a trust path between domain trees. In a complex forest this can take time, which you can reduce with shortcut trusts. A trust path is the series of domain trust relationships that authentication requests must traverse between any two domains. Shortcut trusts effectively shorten the path that authentication requests travel between domains that are located in two separate domain trees. For more information about trust paths, see Understanding Trust Direction.
Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a forest. Using the following illustration as an example, you can form a shortcut trust between domain B and domain D, between domain A and domain 1, and so on.
For more information about how to create a shortcut trust, see Create a Shortcut Trust.
Using one-way trusts
A one-way, shortcut trust that is established between two domains in separate domain trees can reduce the time that is necessary to fulfill authentication requests—but in only one direction. For example, when a one-way, shortcut trust is established between domain A and domain B, authentication requests that are made in domain A to domain B can use the new one-way trust path. However, authentication requests that are made in domain B to domain A must still travel the longer trust path.
Using two-way trusts
A two-way, shortcut trust that is established between two domains in separate domain trees reduces the time that is necessary to fulfill authentication requests that originate in either domain. For example, when a two-way trust is established between domain A and domain B, authentication requests that are made from either domain to the other domain can use the new, two-way trust path.
Understanding When to Create a Realm Trust
When to create a realm trust You can establish a realm trust between any non-Windows Kerberos version 5 (V5) realm and a
Windows Server 2008 domain. This trust relationship allows cross-platform interoperability with security services that are based on other versions of the Kerberos V5 protocol, for example, UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive and back. Realm trusts can also be either one-way or two-way.
For information about how to create a realm trust, see Create a Realm Trust.
Create a Shortcut Trust
You can use Active Directory Domains and Trusts to create shortcut trusts.
Membership in Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
Creating a shortcut trust
Using the Windows interface
Using a command line
To create a shortcut trust using the Windows interface1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click
Start, click Administrative Tools, and then click Active Directory Domains and Trusts.
2. In the console tree, right-click the domain node for the domain that you want to establish a
shortcut trust with, and then click Properties.
3. On the Trusts tab, click New Trust, and then click Next.
4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of
the domain, and then click Next.
5. On the Direction of Trust page, do one of the following:
To create a two-way shortcut trust, click Two-way.
Users in this domain and users in the specified domain will be able to use this trust
path.
To create a one-way incoming shortcut trust, click One-way:incoming.
Users in the specified domain will not be able to use this trust path.
To create a one-way outgoing shortcut trust, click One-way:outgoing.
Users in this domain will not be able to use this trust path.
6. Continue to follow the instructions in the wizard.
Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or Enterprise
Admins group in Active Directory Domain Services (AD DS), or you must have been delegated
the appropriate authority. As a security best practice, consider using Run as to perform this
procedure. For more information, search for "using run as" in Help and Support.
If you have the appropriate administrative credentials for each domain, you can create both
sides of a shortcut trust at the same time by clicking Both this domain and the specified
domain on the Sides of Trust page.
Create an External Trust
You can use Active Directory Domains and Trusts to create external trusts.
Membership in Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
Creating an external trust
Using the Windows interface
Using a command line
To create an external trust using the Windows interface1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click
Start, click Administrative Tools, and then click Active Directory Domains and Trusts.
2. In the console tree, right-click the domain node for the domain that you want to establish a trust
with, and then click Properties.
3. On the Trusts tab, click the New Trust, and then click Next.
4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of
the domain, and then click Next.
5. On the Trust Type page, click External trust, and then click Next.
6. On the Direction of trust page, do one of the following:
To create a two-way, external trust, click Two-way.
Users in this domain and users in the specified domain will be able to access resources
in either domain.
To create a one-way, incoming external trust, click One-way:incoming.
Users in the specified domain will not be able to access any resources in this domain.
To create a one-way, outgoing external trust, click One-way:outgoing.
Users in this domain will not be able to access any resources in the specified domain.
7. Continue to follow the instructions in the wizard.
Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or the
Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been
delegated the appropriate authority. As a security best practice, consider using Run as to
perform this procedure. For more information, search for "using run as" in Help and Support.
If you have the appropriate administrative credentials for each domain, you can create both
sides of an external trust at the same time by clicking Both this domain and the specified
domain on the Sides of Trust page.
If you want to allow users from the specified domain to obtain access to all the resources in this
domain, click Allow authentication for all resources on the Outgoing Trust Properties
page. Use this option when both domains belong to the same organization.
If you want to restrict users in the specified domain from obtaining access to any of the
resources in this domain, click Allow authentication only for selected resources in the
local domain on the Outgoing Trust Propertiespage. Use this option when each domain
belongs to a separate organization.
Additional references
Managing Trusts
To create an external trust using a command line1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and
then click OK.
2. Type the following command, and then press ENTER:
Copy Code
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add
Parameter Description
netdom trust Manages or verifies the trust relationship between domains.
<TrustingDomainName> Specifies the DNS name (or NetBIOS name) of the trusting domain in the trust that is being created.
/d: Specifies that the DNS domain name that follows is a trusted domain.
<TrustedDomainName> Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created.
/add Specifies that a trust be created.
To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:
Copy Code
netdom trust | more Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or the
Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority.
As a security best practice, consider using Run as to perform this procedure. For more
information, search for "using run as" in Help and Support. You can verify trusts for shortcut,
external, and forest trusts but not realm trusts.
You can use other parameters to assign a password or determine the direction of the trust. For
example, to make a two-way, transitive trust, use the following syntax:
Copy Code
netdom trust <TrustingDomainName
Create a Realm Trust
You can use Active Directory Domains and Trusts to create realm trusts.
Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
Creating a realm trust
Using the Windows interface
Using a command line
To create a realm trust using the Windows interface1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click
Start, click Administrative Tools, and then click Active Directory Domains and Trusts.
2. In the console tree, right-click the domain that you want to administer, and then click
Properties.
3. On the Trusts tab, click New trust, and then click Next.
4. On the Trust Name page, type the realm name for the target realm, and then click Next.
5. On the Trust Type page, select the Realm trust option, and then click Next.
6. On the Transitivity of Trust page, do one of the following:
To form a trust relationship with the domain and the specified realm, click
Nontransitive, and then click Next.
To form a trust relationship with the domain and the specified realm and all trusted
realms, click Transitive, and then click Next.
7. On the Direction of Trust page, do one of the following:
To create a two-way, realm trust, click Two-way.
Users in this domain and users in the specified realm will be able to access resources in
either domain or realm.
To create a one-way, incoming realm trust, click One-way:incoming.
Users in the specified realm will not be able to access any resources in this domain.
To create a one-way, outgoing realm trust, click One-way:outgoing.
Users in this domain will not be able to access any resources in the specified realm.
8. Continue to follow the instructions in the wizard.
Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or Enterprise
Admins group in Active Directory Domain Services (AD DS), or you must have been delegated
the appropriate authority. As a security best practice, consider using Run as to perform this
procedure. For more information, search for "using run as" in Help and Support.
Additional references
Managing Trusts
To create a realm trust using a command line1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and
click OK.
2. Type the following command, and then press ENTER:
Copy Code
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add
/realm /PasswordT:<NewRealmTrustPassword>
Parameter Description
netdom trust Manages or verifies trust relationships between domains.
<TrustingDomainName> Specifies the Domain Name System (DNS) name of the trusting domain in the new realm trust.
/d: Specifies that the DNS domain name that follows is a trusted domain.
<TrustedDomainName> Specifies the DNS name of the domain that will be trusted in the new realm trust.
/add Specifies that a trust be created.
/realm Indicates that the trust is to be created to a non-Windows Kerberos realm.
/PasswordT: Specifies the new trust password. This parameter is valid only if one of the domains specified is a non-Windows Kerberos realm.
<NewRealmTrustPassword>
Specifies the trust password for the new realm trust. This password must match the password that is used in the Kerberos realm.
To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:
Copy Code
netdom trust | more Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or Enterprise
Admins group in AD DS, or you must have been delegated the appropriate authority. As a
security best practice, consider using Run as to perform this procedure. For more information,
search for "using run as" in Help and Support. You can verify shortcut trusts, external trusts, and
forest trusts but not realm trusts.
You can use other parameters to assign a password or determine the direction of the trust. For
example, to make the previous trust a two-way, transitive trust, use the following syntax:
Copy Code
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /add
/realm /twoway
Verify a Trust
You can use Active Directory Domains and Trusts to verify whether the newly added shortcut, external, and forest trusts were created successfully.
Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
Verifying a trust
Using the Windows interface
Using a command line
To verify a trust using the Windows interface1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click
Start, click Administrative Tools, and then click Active Directory Domains and Trusts.
2. In the console tree, right-click the domain that contains the trust that you want to verify, and
then click Properties.
3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts), click the trust to be verified, and then
click Properties.
4. Click Validate.
5. Do one of the following, and then click OK:
Click No, do not validate the incoming trust.
If you select this option, we recommend that you repeat this procedure for the
reciprocal domain.
Click Yes, validate the incoming trust.
If you select this option, you must type a user account and password with
administrative credentials for the reciprocal domain.
Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or the
Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been
delegated the appropriate authority. As a security best practice, consider using Run as to
perform this procedure. For more information, search for "using run as" in Help and Support.
You can verify trusts for shortcut trusts, external trusts, and forest trusts, but not realm trusts.
Additional references
Managing Trusts
To verify a trust using a command line1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and
then click OK.
2. Type the following command, and then press ENTER:
Copy Code
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /verify
Parameter Description
netdom trust Managers or verifies the trust relationship between domains.
<TrustingDomainName> Specifies the Domain Name System (DNS) name of the trusting domain in the trust that is being verified.
/d: Specifies that the DNS domain name that follows is the trusted domain.
<TrustedDomainName> Specifies the DNS name of the domain that is trusted in the trust that is being verified.
/verify Verifies that the trust is operating properly.
To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:
Copy Code
netdom trust | more Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or the
Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority.
As a security best practice, consider using Run as to perform this procedure. For more
information, search for "using run as" in Help and Support.
You can verify trusts for shortcut, external, and forest trusts but not realm trusts.
Remove a Trust
You can use Active Directory Domains and Trust to remove trusts.
Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
Removing a trust
Using the Windows interface
Using a command line
To remove a trust using the Windows interface1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click
Start, click Administrative Tools, and then click Active Directory Domains and Trusts.
2. In the console tree, right-click the domain that contains the trust that you want to remove, and
then click Properties.
3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts), click the trust to be removed, and then
click Remove.
4. Do one of the following, and then click OK:
Click No, remove the trust from the local domain only.
If you select this option, we recommend that you repeat this procedure for the
reciprocal domain.
Click Yes, remove the trust from both the local domain and the other domain.
If you select this option, you must type a user account and password with
administrative credentials for the reciprocal domain.
Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or the
Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been
delegated the appropriate authority. As a security best practice, consider using Run as to
perform this procedure. For more information, search for "using run as" in Help and Support.
It is not possible to revoke the default two-way, transitive trusts between domains in a forest. It
is possible to delete explicitly created shortcut trusts.
Additional references
Managing Trusts
To remove a trust using a command line1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and
then click OK.
2. Type the following command, and then press ENTER:
Copy Code
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /remove
/UserD:<User> /PasswordD:*<Password>
Parameter Description
netdom trust Manages or verifies trust relationships between domains.
<TrustingDomainName> Specifies the Domain Name System (DNS) name of the trusting domain in the trust that is being removed.
/d: Specifies that the DNS domain name that follows is a trusted domain.
<TrustedDomainName> Specifies the DNS name of the domain that is trusted in the trust that is being removed.
/remove Specifies that a trust be removed.
<User> Specifies the user account with administrative credentials for the reciprocal domain.
/UserD: Specifies the user account that is used to make the connection with the trusted domain.
/PasswordD:* The password of the user account that is specified by /UserD.
<Password> Specifies the password for the user account with administrative credentials for the reciprocal domain.
To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:
Copy Code
netdom trust | more Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or the
Enterprise Admins group in AD DS, or you must have been delegated the appropriate authority.
As a security best practice, consider using Run as to perform this procedure. For more
information, search for "using run as" in Help and Support. You can verify trusts for shortcut
trusts, external trusts, and forest trusts but not realm trusts.
Select the Scope of Authentication for Users
You can use Active Directory Domains and Trusts to specify the scope of authentication for users that are authenticating through external trusts or forest trusts.
Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To select the scope of authentication using the Windows interface1. Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts, click
Start, click Administrative Tools, and then click Active Directory Domains and Trusts.
2. In the console tree, right-click the domain node for the domain that you want to administer, and
then click Properties.
3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or
Domains that trust this domain (incoming trusts), do one of the following:
To select the scope of authentication for users that are authenticating through an
external trust, click the external trust that you want to administer, and then click
Properties. On the Authentication tab, click either Domain-wide authentication
or Selective authentication.
To select the scope of authentication for users that are authenticating through a forest
trust, click the forest trust that you want to administer, and then click Properties. On
the Authentication tab, click either Forest-wide authentication or Selective
authentication.
Additional considerations
To perform this procedure, you must be a member of the Domain Admins group or Enterprise
Admins group in Active Directory Domain Services (AD DS), or you must have been delegated
the appropriate authority. As a security best practice, consider using Run as to perform this
procedure. For more information, search for "using run as" in Help and Support.
For an external trust, if you select Selective authentication, you must enable permissions
manually on the local domain and on the resource to which you want users in the external
domain to have access.
For a forest trust, if you select Selective authentication, you must enable permissions
manually on each domain and resource in the local forest to which you want users in the second
forest to have access.
You can use selective authentication only on external trusts and forest trusts.
Configure sites
Overview of Active Directory Sites and ServicesUpdated: June 18, 2007
Applies To: Windows Server 2008
You can use the Active Directory Sites and Services snap-in to manage the site-specific objects that implement the intersite replication topology. These objects are stored in the Sites container in Active Directory Domain Services (AD DS).
Note
You can also use Active Directory Sites and Services to administer the replication of directory data among all sites in an Active Directory Lightweight Directory Services (AD LDS) configuration set.
In addition, Active Directory Sites and Services provides a view of the Services container, which you can use to view service-related objects that are published in AD DS.
The following sections provide detailed information about site management and service publication with Active Directory Sites and Services:
Site management
Service publication
Additional references
Site management
In your physical network, a site represents a set of computers that are connected by a high-speed network, such as a local area network (LAN). Typically, all computers in the same physical site reside in the same building or perhaps the same campus network.
In AD DS, a site object represents the aspects of the physical site that you can manage, specifically, replication of directory data between domain controllers. You can use Active Directory Sites and Services to manage the objects that represent the sites and the servers that reside in those sites.
Site objects and their related objects are replicated to all domain controllers in an AD DS forest. You can manage the following objects in Active Directory Sites and Services:
Sites
Subnets
Servers
NTDS Settings
Connections
Site links
IP and SMTP intersite transports
SitesSite objects are located in the Sites container. You can use site objects to accomplish the following tasks:
Create new sites
Delegate control over sites by using Group Policy and permissions
In every site, there is an NTDS Site Settings object. This object identifies the intersite topology generator (ISTG). The ISTG is the one domain controller in the site that generates connection objects from domain controllers in different sites. It also performs advanced replication management tasks.
For more information about sites and the NTDS Site Settings object, see Understanding Sites, Subnets, and Site Links.
SubnetsSubnet objects identify the ranges of IP addresses within a site. You can use subnet objects to accomplish the following tasks:
Create new subnets
Associate subnets with sites
Provide a location for a site that can be used by the printer location tracking feature in
Group Policy
For more information about subnets, see Understanding Sites, Subnets, and Site Links.
ServersServer objects are created automatically when you add the Active Directory Domain Services server role. Servers represent domain controllers in the replication topology.
You can use server objects to accomplish the following tasks:
Identify domain controllers that will act as preferred bridgehead servers. You can use preferred
bridgehead servers to control intersite replication so that it occurs only between those domain
controllers that you specify and not between domain controllers that might be less able to
handle intersite replication traffic.
Move servers between sites. If you create a new site and you have already installed domain
controllers with IP addresses that map to the new site, you can move the domain controllers to
the new site.
NTDS SettingsEvery server object contains an NTDS Settings object, which represents the domain controller in the replication system. The NTDS Settings object stores connection objects, which make replication possible between two or more domain controllers.
You can use NTDS Settings objects to accomplish the following tasks:
Generate the replication topology. The Check Replication Topology command for the NTDS
Settings object signals the ISTG to perform a check of all connections between domain
controllers and add or remove any connections that are needed.
Enable or disable the global catalog on a server. When you enable the global catalog, the
domain controller replicates the read-only directory partitions that make up the global catalog in
the forest.
For more information about the global catalog, see Understanding the Global Catalog.
ConnectionsReplication partners of servers in a site are identified by connection objects. Replication occurs in one direction. A connection object for a server contains information about the other server (the "from" server) that sends replication to the first server. Connection objects store schedules that control replication within a site. By default, they automatically poll a replication partner for new changes once every hour. For intersite replication, connection objects derive their schedule from the site link object. You do not have to manage schedules on connection objects. Connection objects are created automatically by the replication system.
You can use connection objects to accomplish the following tasks:
Identify replication partnerships of servers in the site
Force replication over a connection, when you do not want to wait for scheduled replication or to
test replication over a connection
Site linksSite links represent the flow of replication between sites. You can manage intersite replication by configuring site properties: over what time periods replication can occur, how often replication occurs within a certain time period, and the preferred routes between two sites.
You can use site link objects to accomplish the following tasks:
Add and remove sites that use the site link
Set the cost of replication over the site link, which determines the likelihood that replication
occurs over this site link when there are multiple routes that replication could take to reach a
destination site
Set the site link schedule, which determines the hours and days that replication is available (can
occur) over the site link
Set the replication interval, which determines how often replication occurs over the site link
when replication is available
For more information about using site links, see Scheduling Replication Between Sites.
IP and SMTP intersite transportsReplication uses remote procedure call (RPC) over either the IP transport or the Simple Mail Transfer Protocol (SMTP) transport. You can use SMTP to send replication within mail messages in environments where wide area network (WAN) links are not available. In this case, replication occurs according to the messaging schedule and not the site link schedule. By default, intersite replication uses the IP transport protocol to deliver replication packets. You can use the IP and SMTP Intersite Transport containers to accomplish the following tasks:
Create site links. You can add site links to the replication topology as needed to accommodate
new sites.
Create site link bridges. Site links are bridged by default in AD DS, and they are not necessary in
most deployments.
For more information about intersite transports, see Scheduling Replication Between Sites.
Service publication
Some services, such as Certificate Services, Message Queuing, and Exchange Server, publish information in the Sites container in AD DS automatically when they are installed. Other services can be published in the directory with programming interfaces.
Active Directory Sites and Services exposes published service-related objects in the Services node. This node is not visible by default. To view this node, open Active Directory Sites and Services, and then, on the View menu, click Show Services Node.
The objects in the Services node in Active Directory Sites and Services are published for use by the respective application administrators. For this reason, information about these objects is available in documentation for the service or application.
For more information about service publication in AD DS, see Service Publication (http://go.microsoft.com/fwlink/?LinkId=86230).
Additional references
Adding a Site to the Forest
Scheduling Replication Between Sites
Adding the Global Catalog to a Site
Checklist: Configure an Additional SiteUpdated: June 18, 2007
Applies To: Windows Server 2008
The tasks for configuring a new site include the following:
Creating the site
Mapping the correct IP addresses to the site by creating a subnet
Linking the site to another site or sites by creating a site link and adding the new site to it
Task Reference
(Optional) Review sites and replication concepts. Understanding Sites, Subnets, and Site Links
Create a new site object to represent the domain controllers in a geographic location.
Create a Site
Identify the range of IP addresses that domain controllers in this site use—and that identify the domain controllers as members of this site—by creating a subnet object and associating it with the new site.
Create a Subnet
Create a site link object that connects the new site with an existing site so that replication can occur between the two sites. You can use the site link object to manage the replication schedule.
Create a Site Link
Change the site link association of the new site from its existing site link to the new site link so that replication will begin with the new site link.
Add a Site to or Remove a Site from a Site Link
Changing Site Link PropertiesUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
To control which sites replicate directly with each other, and when, you can use the cost, schedule, and interval properties on the site link object in Active Directory Domain Services (AD DS). For information about how to design the site topology, see Designing the Site Topology for Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/?LinkId=89026).
These settings control intersite replication, as follows:
Schedule: The time during which replication can occur. The default setting allows replication at
all times.
Interval: The number of minutes between replication polling by intersite replication partners
within the open schedule window. The default setting is every 180 minutes.
Cost: The relative priority of the link. The default setting is 100. Lower relative cost increases
the priority of the link over other, higher-cost links.
Consult your design documentation for information about the values to set for site link properties.
Task requirements
The following is required to perform the procedures for this task:
Active Directory Sites and Services
To complete this task, perform the following procedures:
1. Configure the Site Link Schedule to Identify Times During Which Intersite Replication Can Occur
2. Configure the Site Link Interval to Identify How Often Replication Polling Can Occur During the
Schedule Window
3. Configure the Site Link Cost to Establish a Priority for Replication Routing
4. To generate the intersite topology, perform the following procedures:
a. Determine the ISTG Role Owner for a Site
b. Generate the Replication Topology on the ISTG
Creating a Site Link Bridge DesignUpdated: April 11, 2008
Applies To: Windows Server 2008, Windows Server 2008 R2
A site link bridge connects two or more site links and enables transitivity between site links. Each site link in a bridge must have a site in common with another site link in the bridge. The Knowledge Consistency Checker (KCC) uses the information on each site link to compute the cost of replication between sites in one site link and sites in the other site links of the bridge. Without the presence of a common site between site links, the KCC also cannot establish direct connections between domain controllers in the sites that are connected by the same site link bridge.
By default, all site links are transitive. We recommend that you keep transitivity enabled by not changing the default value of Bridge all site links (enabled by default). However, you will need to disable Bridge all site links and complete a site link bridge design if:
Your IP network is not fully routed. When you disable Bridge all site links, all site links are
considered nontransitive, and you can create and configure site link bridge objects to model the
actual routing behavior of your network.
You need to control the replication flow of the changes made in Active Directory Domain
Services (AD DS). By disabling Bridge all site links for the site link IP transport and configuring
a site link bridge, the site link bridge becomes the equivalent of a disjointed network. All site
links within the site link bridge can route transitively, but they do not route outside of the site
link bridge.
For more information about how to use the Active Directory Sites and Services snap-in to disable the Bridge all site links setting, see Enable or disable site link bridges (http://go.microsoft.com/fwlink/?LinkId=107073).
Controlling AD DS replication flow
Two scenarios in which you need a site link bridge design to control replication flow include controlling replication failover and controlling replication through a firewall.
Controlling replication failoverIf your organization has a hub-and-spoke network topology, you generally do not want the satellite sites to create replication connections to other satellite sites if all domain controllers in the hub site fail. In such scenarios, you must disable Bridge all site links and create site link bridges so that replication connections are created between the satellite site and another hub site that is just one or two hops away from the satellite site.
Controlling replication through a firewallIf two domain controllers representing the same domain in two different sites are specifically allowed to communicate with each other only through a firewall, you can disable Bridge all site links and create site link bridges for sites on the same side of the firewall. Therefore, if your network is separated by firewalls, we recommend that you disable transitivity of site links and create site link bridges for the network on one side of the firewall. For information about managing replication through firewalls, see Active Directory in Networks Segmented by Firewalls (http://go.microsoft.com/fwlink/?LinkId=107074).
Configure Active Directory replication
Introduction to Administering Intersite ReplicationUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
This guide explains how to administer intersite replication. These administration activities are part of the operations phase of the information technology (IT) life cycle. If you are not familiar with this guide, review the following sections of this introduction.
A site object in Active Directory Domain Services (AD DS) represents a collection of IP subnets, usually constituting a physical local area network (LAN). Multiple sites are connected for replication by site link objects.
Sites are used in AD DS to:
Make it possible for clients to discover network resources (published shares, domain controllers,
global catalog servers) that are close to the physical location of the client, reducing network
traffic over wide area network (WAN) links.
Optimize replication between domain controllers.
Managing sites in AD DS involves adding new subnet, site, and site link objects when the network grows, as well as configuring a schedule and cost for site links. You can modify the site link schedule, cost, or both to optimize intersite replication. When conditions no longer require replication to a site or clients no longer require the sites to discover network resources, you can remove the site and associated objects from AD DS.
Managing large hub-and-spoke topology is beyond the scope of this documentation. For information about managing branch sites, see the Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).
Optimizing replication between sites
The efficiency of replication between sites is optimized by cost settings on site links that favor replication routes between specific sites. The Knowledge Consistency Checker (KCC) uses site link configuration information to enable and optimize replication traffic by generating a least-cost replication topology. Within a site, for each directory partition, the KCC builds a ring topology that tries to set a maximum number of hops (three) between any two domain controllers. Between sites, the KCC on the domain controller that has the intersite topology generator (ISTG) role creates the topology based on site link cost.
Designing a simple replication topology is the best way to optimize replication. Adding sites and domains increases the processing that is required by the KCC. Before adding to the site topology, be sure to review the guidelines in Adding a New Site. For information about topology design, see Designing the Site Topology for Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/?LinkId=89026).
Effects of site link bridgingBy default, all site links are bridged. When site links are bridged, replication is transitive between sites and the costs that are assigned to site links are cumulative; the lowest-cost route between sites that have more than one site link is the route that replication takes. By default, site link costs are equal, with a cost of 100 on each new site link. For this reason, with no changes to the default site link cost, a hub-and-spoke topology favors the replication route between the hub site and each branch site, rather than between branch sites. The cost to replicate to and from two branch sites is always higher than the cost to replicate to and from the hub site. Therefore, replication between branch sites occurs only if no domain controller for the domain is available in the hub site.
Effects of disabling site link bridgingIf you disable the Bridge all site links setting in the properties of the IP container in Active Directory Sites and Services, the ability of the ISTG to create the topology on the basis of cost is disabled. In addition, Distributed File System (DFS) cannot compute the cost matrix for its site-costing functionality. Therefore, if you disable site link bridging and you are using File Replication Service (FRS) to replicate DFS replicas, which include the SYSVOL share, the DFS site-costing ability is also disabled.
Note
DFS Replication, which is available in domains that are at the Windows Server 2008 domain functional level, uses the replication topology that is defined by the administrator, which is independent of Active Directory site costing.
If you turn off site link bridging, you must create site link bridges manually. For information about using manual site link bridges, see Creating a Site Link Bridge Design (http://go.microsoft.com/fwlink/?LinkId=122678).
Note
When you use FRS to replicate DFS replicas, you can maintain DFS site-costing functionality with Bridge all site links turned off. When the forest functional level is at least Windows Server 2003 or Windows Server 2003 interim and the ISTG in a site is running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008, you can use a site option to turn off automatic site link bridging for KCC operation without hampering the ability of DFS to use Intersite Messaging to calculate the cost matrix. This site option is set when you run the command repadmin /siteoptions W2K3_BRIDGES_REQUIRED. For more information about the effects of disabling site link bridging, see How Active Directory Replication Topology Works (http://go.microsoft.com/fwlink/?LinkId=93526).
Do not disable Bridge all site links unless you are deploying a branch office environment. For information about branch office deployments, see “RODC Placement Considerations” in Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).
Optimizing domain controller location
Two new Group Policy settings are available on domain controllers that are running Windows Server 2008: Try Next Closest Site and Force Rediscovery Interval. These settings help Windows Vista and Windows Server 2008 clients in the domain to locate domain controllers in the next closest site if no domain controller in their own site is available. These settings improve domain controller discovery by controlling how the domain controller locator (DC Locator) process operates.
Finding the next closest siteBy default, when a client requests a domain controller, the DC Locator process locates a domain controller in the site of the client. If no domain controller is available in the site, DC Locator returns any domain controller in the domain. If the domain controller is located in another branch site instead of the hub site, communication with the domain controller might be significantly slow. The Try Next Closest Site Group Policy setting in the Default Domain Policy can improve the location of domain controllers by clients that are running Windows Server 2008 or Windows Vista.
The Try Next Closest Site Group Policy setting uses site link cost values to determine the next closest site to the site of the client. Try Next Closest Site can affect how you configure site link costs because it affects the order in which domain controllers are located. For enterprises that have many hub sites and branch offices, you can significantly reduce Active Directory traffic on the network by ensuring that clients fail over to the next closest hub site when they cannot find a domain controller in the closest hub site. For more information, see Enabling Clients to Locate the Next Closest Domain Controller (http://go.microsoft.com/fwlink/?LinkId=120711).
Forcing domain controller rediscoveryIn addition to finding a domain controller in the next closest site, a new Group Policy setting in Windows Server 2008 ensures that a client that is running Windows Vista or Windows Server 2008 finds a new domain controller that might be introduced since the last domain controller location. On domain controllers that are running Windows Server 2008, the Force Rediscovery Interval Group Policy setting forces a new domain controller location every 12 hours (43200 seconds) by default. You can change the time limit for rediscovery by enabling the setting and specifying a new time in seconds.
By default, clients cache the last domain controller that was returned by DC Locator. On clients that are running Windows XP or Windows Server 2003, even if the domain controller that was last located is in a distant site, DC Locator continues to return the cached domain controller on each subsequent request. The cache is updated only if the cached domain controller is unavailable or the client restarts.
For domain clients that are running Windows XP and Windows Server 2003, a hotfix is available that makes the registry setting available for this Group Policy setting. For information about downloading and using this hotfix, see article ID 939252 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=122681).
Improving the logon experience in branch sites
Branch sites often contain only a single domain controller that might not be a global catalog server. Perhaps replication of global catalog updates is considered to be prohibitive as a result of poor or unreliable bandwidth between the branch site and the nearest hub site. When the global catalog is required for domain logon and there is no global catalog server in the site, the domain controller must contact a global catalog server in another site.
The global catalog is required when a domain user logs on interactively to a domain under the following conditions:
The user's domain has a domain functional level of Windows 2000 native, Windows Server 2003,
or Windows Server 2008. In these cases, the user might belong to a universal group whose
object is stored in a different domain. Only the global catalog stores universal group
memberships for all domains in the forest.
The user’s logon name is a user principal name (UPN), which has the format
sAMAccountName@DNSDomainName. In this case, the Domain Name System (DNS) domain
suffix is not necessarily the user’s domain and the identity of the user’s domain must be
retrieved from a global catalog server.
In Windows Server 2008, the best solution to this branch site scenario is to deploy a read-only domain controller (RODC) that is a global catalog server. In this case, although the global catalog must be replicated to the site, access to universal group memberships is always local and logon experience is consistent. In addition, RODCs provide more security against compromise than regular domain controllers because they are not writable. For information about deploying RODCs that are global catalog
servers, see Planning and Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).
As an alternative to deploying the global catalog in the branch site, you can enable Universal Group Membership Caching, which means that the domain controller contacts the global catalog server only once for each user and that it caches all universal group memberships, rather than having to retrieve them at each logon. For more information about Universal Group Membership Caching, see How the Global Catalog Works (http://go.microsoft.com/fwlink/?LinkId=107063). For information about using Universal Group Membership Caching, see Enabling Universal Group Membership Caching in a Site.
Managing Intersite ReplicationThis section includes the following tasks for managing intersite replication:
Adding a New SiteApplies To: Windows Server 2008, Windows Server 2008 R2
Design teams or network architects might want to add site objects in Active Directory Domain Services (AD DS) as part of ongoing deployment. Although you typically create subnets to accommodate all address ranges in the network, you do not have to create sites for every location. Generally, sites are required for those locations that have domain controllers or other servers that run applications, such as Distributed File System (DFS), that depend on site topology.
When a site is needed, the design team typically provides details about the placement and configuration of site links for the new site, as well as subnet assignments or creation if subnets are needed.
If a new range of IP addresses is added to the network, create a subnet object in AD DS to correspond to the range of IP addresses. When you use Active Directory Sites and Services to create a new subnet object, you are required to associate the subnet with a site object. You can either associate the subnet with an existing site or create a new site first and then create the subnet and associate it with the new site. If a domain client has an IP address that does not map to a site, the client might be connected to a domain controller that is potentially far away from the client, causing slow responses for the client.
Note
When a domain client that has an IP address in a subnet that is not defined in AD DS connects to a domain controller, NETLOGON Event ID 5807 is generated in the System event log. The event indicates that clients have connected to the domain controller with IP addresses that do not map to a site. The text in the event provides instructions for determining the names and IP addresses of the client computers by searching the Netlogon.log file.
Task requirements
The following is required to perform the procedures for this task:
Active Directory Sites and Services
To complete this task, perform the following procedures:
1. Create a Site Object and Add it to an Existing Site Link
2. Associate a range of IP addresses with the site by using either of the following methods:
Create a Subnet Object or Objects and Associate them with a Site
Associate an Existing Subnet Object with a Site
3. If you are creating both a new site and a new site link, after you create the new site and add it
to an existing site link, Create a Site Link Object and Add the Appropriate Sites. Then, remove
the site from the first site link that you added it to when you created the site, if appropriate.
4. Remove a Site from a Site Link
Linking Sites for Replication
Linking sites is required for Active Directory replication to occur between sites. Plan your site topology and then implement the plan by creating sites and site links. For information about planning your site topology, see Designing the Site Topology for Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/?LinkId=89026).
Creating site links
To link sites for Active Directory replication, create a site link object in the IP transport container in Active Directory Domain Services (AD DS) and add two or more sites to the link. Use a naming convention that includes the sites that you are linking. For example, if you want to link the site named Seattle to the site named Boston, you might name the site link SEA-BOS.
After you add two or more site names to a site link object, the bridgehead servers in the respective sites replicate between the sites according to the replication schedule, cost, and interval settings on the site link object. For information about modifying the default settings, see Changing Site Link Properties.
At least two sites must exist when you create a site link. If you are adding a site link to connect a new site to an existing site, create the new site first and then create the site link. For information about creating a site, see Adding a New Site.
Selecting bridgehead servers
By default, the intersite topology generator (ISTG) selects bridgehead servers in a site automatically. We recommend that you allow the ISTG to perform bridgehead server selection. However, if you want to ensure that only certain domain controllers in the sites you are linking perform replication between sites, you can designate preferred bridgehead servers in the site.
Note
If you have selected one or more bridgehead servers, removing them all from the bridgehead servers list restores the automatic selection functionality to the ISTG.
Use the following guidelines when you select bridgehead servers:
Selecting preferred bridgehead servers limits the bridgehead servers that the Knowledge
Consistency Checker (KCC) can use to those bridgehead servers that you have selected. If you
use Active Directory Sites and Services to select any preferred bridgehead servers at all in a
site, you must select as many bridgehead servers as possible and you must select them for all
domains that must be replicated to a different site.
If a site contains a global catalog server, select the global catalog server as a preferred
bridgehead server.
When you use preferred bridgehead servers, the following problems can occur:
If you select preferred bridgehead servers for a domain and all preferred bridgehead servers for
that domain become unavailable, replication of that domain to and from that site does not
occur.
If you select a non-global-catalog server but a global catalog server currently exists in the site,
or the global catalog is subsequently added to another domain controller in the site, the global
catalog server cannot receive updates of read-only domain directory partitions for any domain
that does not have a selected bridgehead server in the site.
Task requirements
The following is required to perform the procedures for this task:
Active Directory Sites and Services
To complete this task, perform the following procedures:
1. Create a Site Link Object and Add the Appropriate Sites
2. By default, the KCC runs every 15 minutes to generate the replication topology. To generate the
intersite topology immediately, perform the following two procedures:
Determine the ISTG Role Owner for a Site
Generate the Replication Topology on the ISTG
3. If you are designating servers that will perform intersite replication, you can Designate a Server
as a Preferred Bridgehead Server.
Changing Site Link PropertiesTo control which sites replicate directly with each other, and when, you can use the cost, schedule, and interval properties on the site link object in Active Directory Domain Services (AD DS). For information about how to design the site topology, see Designing the Site Topology for Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/?LinkId=89026).
These settings control intersite replication, as follows:
Schedule: The time during which replication can occur. The default setting allows replication at
all times.
Interval: The number of minutes between replication polling by intersite replication partners
within the open schedule window. The default setting is every 180 minutes.
Cost: The relative priority of the link. The default setting is 100. Lower relative cost increases
the priority of the link over other, higher-cost links.
Consult your design documentation for information about the values to set for site link properties.
Task requirements
The following is required to perform the procedures for this task:
Active Directory Sites and Services
To complete this task, perform the following procedures:
1. Configure the Site Link Schedule to Identify Times During Which Intersite Replication Can Occur
2. Configure the Site Link Interval to Identify How Often Replication Polling Can Occur During the
Schedule Window
3. Configure the Site Link Cost to Establish a Priority for Replication Routing
4. To generate the intersite topology, perform the following procedures:
a. Determine the ISTG Role Owner for a Site
b. Generate the Replication Topology on the ISTG
Enabling Clients to Locate the Next Closest Domain ControllerIf you have a domain controller that runs Windows Server 2008 or Windows Server 2008 R2, you can make it possible for client computers that run Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 to locate domain controllers more efficiently by enabling the Try Next Closest Site Group Policy setting. This setting improves the Domain Controller Locator (DC Locator) by helping to streamline network traffic, especially in large enterprises that have many branch offices and sites.
This new setting can affect how you configure site link costs because it affects the order in which domain controllers are located. For enterprises that have many hub sites and branch offices, you can significantly reduce Active Directory traffic on the network by ensuring that clients fail over to the next closest hub site when they cannot find a domain controller in the closest hub site.
As a general best practice, you should simplify your site topology and site link costs as much as possible if you enable the Try Next Closest Site setting. In enterprises with many hub sites, this can simplify any plans that you make for handling situations in which clients in one site need to fail over to a domain controller in another site.
By default, the Try Next Closest Site setting is not enabled. When the setting is not enabled, DC Locator uses the following algorithm to locate a domain controller:
Try to find a domain controller in the same site.
If no domain controller is available in the same site, try to find any domain controller in the
domain.
Note
This is the same algorithm that DC Locator used in previous versions of Active Directory. For more information, see How DNS Support for Active Directory Works (http://go.microsoft.com/fwlink/?LinkId=108587).
If you enable the Try Next Closest Site setting, DC Locator uses the following algorithm to locate a domain controller:
Try to find a domain controller in the same site.
If no domain controller is available in the same site, try to find a domain controller in the next
closest site. A site is closer if it has a lower site-link cost than another site with a higher site-link
cost.
If no domain controller is available in the next closest site, try to find any domain controller in
the domain.
By default, DC Locator does not consider any site that contains a read-only domain controller (RODC) when it determines the next closest site. In addition, because only Windows Server 2008 and Windows Server 2008 R2 domain controllers support the next closest site functionality, when the client gets a response from a domain controller that runs an earlier version of Windows Server, the DC Locator behavior is the same as when then setting is not enabled.
For example, assume that a site topology has four sites with the site link values in the following illustration. In this example, all the domain controllers are writable domain controllers that run Windows Server 2008 or Windows Server 2008 R2.
When the Try Next Closest Site Group Policy setting is enabled in this example, if a client computer that runs Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 in Site_B tries to locate a domain controller, it first tries to find a domain controller in its own Site_B. If none is available in Site_B, it tries to find a domain controller in Site_A.
If the setting is not enabled, the client tries to find a domain controller in Site_A, Site_C, or Site_D if no domain controller is available in Site_B.
Note
The Try Next Closest Site setting works in coordination with automatic site coverage. For example, if the next closest site has no domain controller, DC Locator tries to find the domain controller that performs automatic site coverage for that site.
To apply the Try Next Closest Site setting, you can create a Group Policy object (GPO) and link it to the appropriate object for your organization, or you can modify the Default Domain Policy to have it affect all clients that run Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 in the domain. For more information about how to set the Try Next Closest Site setting, see Enable Clients to Locate a Domain Controller in the Next Closest Site.
Moving a Domain Controller to a Different SiteWhen you install Active Directory Domain Services (AD DS) on a server running Windows Server 2008, you can select the site for the domain controller. If you do not make this selection, the domain controller is placed into the site that its IP address maps to. If you change the IP address or the subnet-to-site association of a domain controller after AD DS is installed on the server, the server object does not change sites automatically. You must move it to the new site manually. When you move the server object, the Netlogon service on the domain controller registers Domain Name System (DNS) service (SRV) resource records for the appropriate site.
TCP/IP settings
When you move a domain controller to a different site, if an IP address of the domain controller is configured statically, you must change the TCP/IP settings accordingly. The IP address of the domain controller must map to a subnet object that is associated with the site to which you are moving the domain controller. If the IP address of a domain controller does not match the site in which the server object appears, the domain controller might be forced to communicate over a potentially slow wide area network (WAN) link to locate resources, rather than locating resources in its own site.
Before you move the domain controller, ensure that the following TCP/IP client values are appropriate for the new location:
IP address, including the subnet mask and default gateway
DNS server addresses
Windows Internet Name Service (WINS) server addresses (if appropriate)
If the domain controller that you are moving is a DNS server, you must also change the TCP/IP settings on any clients that have static references to the domain controller as the preferred or alternate DNS server.
DNS settings
If the domain controller is a DNS server, you must update the IP address in any DNS delegations or forwarders that reference the IP address. With dynamic update enabled, DNS updates host (A), host (AAAA), and name server (NS) resource records automatically. However, you must update delegations and forwarders as follows:
Delegations: Determine whether the parent DNS zone of any zone that is hosted by this DNS
server contains a delegation to this DNS server. If the parent DNS zone does contain a
delegation to this DNS server, update the IP address in the name server (NS) resource record in
the parent domain DNS zone that points to this DNS server.
Forwarders: Determine whether the server acts as a forwarder for any DNS servers. If a DNS
server uses this server as a forwarder, change the name server (NS) resource record for the
forwarder on that DNS server.
Preferred bridgehead server status
Before you move any server object, check the server object to see whether it is acting as a preferred bridgehead server for the site. This condition has implications for the Intersite Topology Generator (ISTG) in both sites, as follows:
In the site to which you are moving the server: If you move a preferred bridgehead server to a
different site, it becomes a preferred bridgehead server in the new site. If preferred bridgehead
servers are not currently in use in this site, the ISTG behavior in this site changes to support
preferred bridgehead servers. For this reason, you must either configure the server to not be a
preferred bridgehead server (recommended), or select additional preferred bridgehead servers
in the site (not recommended).
In the site from which you are moving the server: If the server is the last preferred bridgehead
server in the original site for its domain, and if other domain controllers for the domain are in
the site, the ISTG selects a bridgehead server for the domain. If you use preferred bridgehead
servers, always select more than one server as the preferred bridgehead server for the domain.
If, after the removal of this domain controller from the site, multiple domain controllers remain
that are hosting the same domain and only one of them is configured as a preferred bridgehead
server, either configure the server to not be a preferred bridgehead server (recommended), or
select additional preferred bridgehead servers that host the same domain in the site (not
recommended).
Note
If you select preferred bridgehead servers and all selected preferred bridgehead servers for a domain are unavailable in the site, the ISTG does not select a new bridgehead server. In this case, replication of this domain to and from other sites does not occur. However, if no preferred bridgehead server is selected for a domain or transport (through administrator error or as the result
of moving the only preferred bridgehead server to a different site), the ISTG automatically selects a preferred bridgehead server for the domain and replication proceeds as scheduled.
Task requirements
The following is required to perform the procedures for this task:
Network Connections
DNS snap-in
Active Directory Sites and Services
To complete this task, perform the following procedures in order:
1. Change the Static IP Address of a Domain Controller
2. Update the IP Address for a DNS Delegation
If the parent DNS zone of any zone that is hosted by this DNS server contains a delegation to
this DNS server, use this procedure to update the IP address in all such delegations.
If your forest root domain has a parent DNS domain, perform this procedure on a DNS server in
the parent domain. If you just added a new domain controller to a child domain, perform this
procedure on a DNS server in the DNS parent domain. If you are following recommended
practices, the parent domain is the forest root domain.
3. Update the IP Address for a DNS Forwarder
If the DNS server is configured as a forwarder for any other DNS server, use this procedure to
update the IP address in all forwarders.
4. Verify That an IP Address Maps to a Subnet and Determine the Site Association
5. To determine whether the server is a preferred bridgehead server, you can check a single
server or you can view the entire preferred bridgehead server list:
Determine Whether a Server is a Preferred Bridgehead Server
View the List of All Preferred Bridgehead Servers
6. Configure a Server to Not Be a Preferred Bridgehead Server
7. Move a Server Object to a New Site
Enabling Universal Group Membership Caching in a Site
In a multidomain forest, when a user logs on to a domain, a global catalog server must be contacted to determine the universal group memberships of the user. A universal group can contain users from other domains, and it can be applied to access control lists (ACLs) on objects in all domains in the forest. Therefore, universal group memberships must be ascertained at domain logon so that the user has appropriate access in the domain and in other domains during the logon session. Only global catalog servers store the memberships of all universal groups in the forest.
If a global catalog server is not available in the site when a user logs on to a domain, the domain controller must contact a global catalog server in another site.
In multidomain forests where remote sites do not have a global catalog server, the need to contact a global catalog server over a potentially slow wide are network (WAN) connection can be problematic and a user can potentially be unable to log on to the domain if a global catalog server is not available. You can enable Universal Group Membership Caching on domain controllers that are running Windows Server 2008 so that when the domain controller contacts a global catalog server for the user’s initial domain logon, the domain controller retrieves universal group memberships for the user. On subsequent logon requests by the same user, the domain controller uses cached universal group memberships and does not have to contact a global catalog server.
Task requirements
The following tool is required to perform the procedures for this task:
Active Directory Sites and Services
To complete this task, perform the following procedure:
Forcing ReplicationWhen you need updates to be replicated sooner than the intersite replication schedule allows, or when replication between sites is impossible because of configuration errors, you can force replication to and from domain controllers. You can use the following two methods of forcing replication:
Force replication of all directory partition updates from one server to another server over a
connection
Force replication of configuration directory partition updates from one server to another server
Forcing replication of all directory updates over a connection
If you want to replicate certain updates, such as a significant addition of new passwords or user accounts, to another domain controller in the domain, you can use the Replicate now option in the Active Directory Sites and Services snap-in to force replication of all directory partitions over a connection object that represents inbound replication from a specific domain controller. A connection object for a server object that represents a domain controller identifies the replication partner from which the domain controller receives replication. If the changes are made on one domain controller, you can select the connection from that domain controller and force replication to its replication partner.
You can also use the Repadmin.exe command-line tool to replication changes from a server to one or more other servers or to all servers.
Forcing replication of configuration updates
Active Directory replication uses a pull model, in which one domain controller requests changes from another domain controller. For this reason, connection objects always represent one-way, inbound replication from a source server to a destination server. All objects that are required for replication are contained in the configuration directory partition, which is replicated to every domain controller in the forest.
If a site link is deleted inadvertently, the domain controllers in the respective sites drop connection objects that represent servers in any site to which the domain controller’s site is no longer linked. The only way for these connection objects to be recreated is for a new site link to be created and for domain controllers in each site in the site link to recreate the connection objects. However, the change to the configuration directory partition (the new site link) cannot be replicated from the site where the change occurs to the other site because the domain controllers in the other site have dropped their inbound connection objects from servers in the site where the site link has been recreated. The Replicate now option does not fix the problem because the ability to use Replicate now depends on the existence of a from-server connection object.
On writable domain controllers running Windows Server 2003, the only way to resolve this issue is to create the new site link object twice, once on a domain controller in each site. When the domain controller has a site link, the Knowledge Consistency Checker (KCC) on the domain controller can then create connection objects from servers in the other site.
On writable domain controllers running Windows Server 2008, a new option is available that you can use to force replication of only the configuration directory partition to a domain controller in another site, even though a connection object from a server in the site does not exist in the configuration directory partition. In this case, you can recreate the site link in one site and force replication of this configuration change to a domain controller in the other site. When replication of the new site link object is received on the domain controller in the other site, that domain controller can then create new connection objects from servers in the other sites in the site link.
This functionality is particularly useful if the only domain controller in a site is a read-only domain controller (RODC). In this case, you cannot recreate the site link on a domain controller in both sites because you cannot write to the RODC. When you recreate the site link in the hub site and then force replication of the configuration directory partition to the site of the RODC, you enable the RODC to create connection objects from replication partners in the hub site.
Task requirements
The following tools are required to perform the procedures for this task:
Active Directory Sites and Services
Repadmin.exe
To complete this task, perform the following procedures:
1. Force Replication Between Domain Controllers
2. Update a Server with Configuration Changes
3. Synchronize Replication with All Partners
4. Verify Successful Replication to a Domain Controller
Removing a SiteIf domain controllers are no longer needed in a network location, you can remove them from the site and then delete the site object. Before you delete the site, you must remove each domain controller from the site either by removing domain controller completely or by moving it to a new location:
To remove the domain controller completely, remove Active Directory Domain Services (AD DS)
from the server and then delete the server object from the site in AD DS.
To retain the domain controller in a different location, move the domain controller itself to the
new site and then move the server object to the respective site in AD DS.
Before you remove a server object from a site, check the NTDS Settings object of the server to see if the server has a manual connection object from any server in another site. If a manual connection object exists, check the source server in the other site for a corresponding manual connection object from the server that you are removing. The Knowledge Consistency Checker (KCC) does not remove manual connection objects automatically. Therefore, if you leave a manually created connection object on a server and then remove the source server for the connection, the inability of the destination server to replicate from its source replication partner will cause replication errors to be generated. If a manual connection object exists in the NTDS Settings object of a server in another site, and if the server that you are removing is the source (“replicate from”) server for the connection, delete that manual connection object on the destination server to avoid unnecessary replication errors after you have removed the server object.
Domain controllers can host other applications that depend on site topology and publish objects as child objects of the respective server object. For example, when Microsoft Operations Manager (MOM) or Message Queuing is running on a domain controller, these applications create child objects beneath the server object. In addition, a server running Message Queuing that is not a domain controller and that is
configured to be a routing server running Message Queuing creates a server object in the sites container. Removing the application from the server automatically removes the child object below the respective server object. However, the server object is not removed automatically.
When all applications have been removed from the server (no child objects appear beneath the server object), you can remove the server object. After the application is removed from the server, a replication cycle might be required before child objects are no longer visible below the server object.
After you delete or move the server objects but before you delete the site object, reconcile the following objects:
IP addresses:
If the addresses are being reassigned to a different site, associate the subnet object or objects
with that site. Any clients that use the addresses for the decommissioned site will thereafter be
assigned automatically to the other site.
If the IP addresses will no longer be used on the network, delete the corresponding subnet
object or objects.
Site link objects:
If the site that you are removing is added to a site link that contains only two sites, delete the
site link object.
If the site that you are removing is added to a site link that contains more than two sites, do not
delete this site link object.
Before you remove a site, consider the implications. If the site that you are removing is added to more than one site link, it might be an interim site between other sites that are added to this site link. Deleting the site might disconnect the outer sites from each other. In this case, the site links must be reconciled according to the instructions of the design team.
Task requirements
The following tool is required to perform the procedures for this task:
Active Directory Sites and Services
To complete this task, perform the following procedures:
1. Delete a manual Connection object
2. Determine Whether a Server Object Has Child Objects
3. Delete a Server Object from a Site
4. Delete a Site Link object
5. Associate an Existing Subnet Object with a Site
6. Delete a Site object
7. To avoid replication errors on bridgehead servers in other sites that received replication from
the site that has been removed, generate the intersite topology in those sites by performing the
following two procedures:
Determine the ISTG Role Owner for a Site
Generate the Replication Topology on the ISTG
Introduction to Administering DFS-Replicated SYSVOLUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
SYSVOL is a collection of folders that contain a copy of the domain’s public files, including system policies, logon scripts, and important elements of Group Policy objects (GPOs). The SYSVOL directory must be present and the appropriate subdirectories must be shared on a server before the server can advertise itself on the network as a domain controller. Shared subdirectories in the SYSVOL tree are replicated to every domain controller in the domain.
Note
For Group Policy, only the Group Policy template (GPT) is replicated through SYSVOL replication. The Group Policy container (GPC), which is stored in the domain, is replicated through Active Directory replication. For Group Policy to be effective, both parts must be available on a domain controller.
SYSVOL terminology and capitalization
SYSVOL is referred to as the “SYSVOL share.” The default root of the SYSVOL replica is at the path %systemroot%\SYSVOL\domain, but the folder that is actually shared by the domain controller is the %systemroot%\SYSVOL\sysvol folder by default.
Note
The location of the SYSVOL directory and subdirectories is configurable during and after Active Directory installation. The default locations under %systemroot%\SYSVOL are used throughout this guide only as a relative reference to the location of SYSVOL files and folders.
The %systemroot%\SYSVOL\domain and %systemroot%\SYSVOL\sysvol folders appear to contain the same content because SYSVOL uses junction points (also called reparse points). A junction point is a physical location on a hard disk that points to data that is located elsewhere on the hard disk or on another storage device. Junction points look like folders and behave like folders (in Windows Explorer they appear to be shortcuts to folders), but they are not folders. A junction point contains a link to another folder. When a program opens it, the junction point automatically redirects the program to the folder to which the junction point is linked. The redirection is completely transparent to the user and the application. For example, if you open a command prompt and type dir to list the contents of \%systemroot%\SYSVOL\sysvol, you notice a folder that is listed as <JUNCTION>. The junction point in %systemroot%\SYSVOL\sysvol links to %systemroot%\SYSVOL\domain.
In this guide, in reference to SYSVOL components and folders, the capitalization that is used reflects the capitalization of the default folders and parameters as they appear in the file system, in the registry, and in Active Directory Domain Services (AD DS). For example, the default SYSVOL directory tree always appears as %systemroot%\SYSVOL\sysvol, as it appears in Windows Explorer. When the topic is specific to the sysvol shared folder, lowercase sysvol is used. Similarly, the area of SYSVOL that is historically referred to as “the staging area” is described in this guide as “the staging areas subdirectory.” In this way, the folder “%systemroot%\SYSVOL\staging areas” is clearly understood and distinct from the “%systemroot%\SYSVOL\staging” folder. Capitalization of registry parameters and Active Directory attribute names are presented as they appear in those locations.
Using DFS Replication for replicating SYSVOL in Windows Server 2008
Distributed File System (DFS) Replication is a replication service that is available for replicating SYSVOL to all domain controllers in domains that have the Windows Server 2008 domain functional level. DFS Replication was introduced in Windows Server 2003 R2. However, on domain controllers that are running Windows Server 2003 R2, SYSVOL replication is performed by the File Replication Service (FRS).
Note
The information and instructions in this section relate to DFS Replication of SYSVOL. For information about managing SYSVOL when you use FRS for file replication, see Administering FRS-Replicated SYSVOL (http://go.microsoft.com/fwlink/?LinkId=122535).
DFS Replication technology significantly improves replication of SYSVOL. In Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2, FRS is used to replicate the contents of the SYSVOL share. When a change to a file occurs, FRS replicates the entire updated file. With DFS Replication, for files larger than 64 KB, only the updated portion of the file is replicated.
To replicate only updates to files, DFS Replication uses an algorithm called remote differential compression (RDC). RDC detects changes to the data in a file and enables DFS Replication to replicate changes in the form of file blocks, without having to replicate the entire file. RDC detects insertions, removals, and rearrangements of data in files. The DFS Replication service monitors SYSVOL, and, if a change occurs to any file that is stored in SYSVOL, DFS Replication automatically replicates the file updates to the SYSVOL folders on the other domain controllers in the domain. An additional improvement is that DFS Replication does not require the version vector join (vvjoin) operation, which is performed between FRS replication partners when new connections are created. Vvjoin is a CPU-intensive operation that can affect the performance of the server and cause increased replication traffic.
In Windows Server 2008, DFS Replication is the default file replication service for domains that are initially created on domain controllers running Windows Server 2008. However, in a domain that is upgraded from another operating system to Windows Server 2008, FRS is the default replication service for SYSVOL replication. To implement DFS Replication of SYSVOL after an upgrade to Windows Server 2008 domain functional level, you must perform a preliminary migration process for replication of the SYSVOL tree.
Requirements for using DFS Replication
In Windows Server 2008, for newly created domains operating at the Active Directory domain functional level of Windows Server 2008, DFS Replication is used by default for SYSVOL replication. If your domain controllers are upgraded from another operating system to Windows Server 2008, you must install DFS Replication on all domain controllers in the domain, raise the domain functional level to Windows Server 2008, and then follow a migration process to move from using FRS replication of SYSVOL to DFS Replication. For more information about the SYSVOL migration process, see SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process (http://go.microsoft.com/fwlink/?LinkID=119296). For more information about DFS Replication, see Distributed File System Replication: Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkId=122537).
The day-to-day operation of SYSVOL replication is an automated process that does not require any human intervention other than watching for alerts that the DFS Replication service raises. Occasionally, you might perform some system maintenance as you change your network.
The topics in this section describe the tasks that are required for managing SYSVOL replication, including maintaining capacity and relocating SYSVOL components.
Key considerations for administering SYSVOL
A new graphical user interface (GUI) management tool, DFS Management, provides options for performing many SYSVOL management tasks. In Windows Server 2003, most SYSVOL management tasks required registry changes. In Windows Server 2008, you can use DFS Management to perform the following SYSVOL updates:
Change the space that is allocated to the staging area
Change the staging area path
Note
You cannot use DFS Management to change the SYSVOL path. You must make this change in the registry directly. For information about changing the SYSVOL path, see Relocating SYSVOL Manually.
View shared folders
You can use the Diagnostic Reports features of DFS Management to implement a monitoring system to detect low disk space and other potential DFS Replication disruptions so that you can resolve these issues before the system stops replicating. The Ultrasound utility, which is a tool for monitoring FRS, cannot be used for DFS Replication. Instead, you can use the DFS Replication health reports that
DFS Management generates. For information about using DFS Management to generate diagnostic reports, see Create a Diagnostic Report for DFS Replication (http://go.microsoft.com/fwlink/?LinkId=122538).
Other key considerations for managing SYSVOL include the following:
Capacity
To manage SYSVOL, enough space must be provided to store SYSVOL. The quota that is
allocated to the DFS Replication staging area is 4 gigabytes (GB) (4096 MB). The maximum size
is 4 terabytes (TB) (4096 GB). Depending on the configuration of your domain, SYSVOL can
require a significant amount of disk space to function properly. During the initial deployment,
SYSVOL might be allocated adequate disk space to function. However, as your installation of
Active Directory Domain Services (AD DS) grows in size and complexity, the required capacity
can exceed the available disk space.
If you receive indications that disk space is low, determine whether the cause is attributable to
inadequate physical space on the disk or the DFS Management setting that limits the quota that
is allocated to the staging area. If staging area disk space is low, DFS Replication encounters
frequent staging area cleanup events. You can avoid this scenario by using .admx file capability
to implement a Central Store in SYSVOL to store and to replicate Windows Vista policy files. For
information about using this solution, see article 929841 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=122539). You can also reduce SYSVOL size and
replication time by managing Administrative Templates in Group Policy. For information about
using this solution, see article 813338 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=122540).
Hardware maintenance
System maintenance, such as removal of a disk drive, can make it necessary for you to relocate
SYSVOL. Even if the maintenance occurs on a different disk drive, verify that the maintenance
does not affect SYSVOL. Logical drive letters can change after you add and remove disks.
DFS Replication locates SYSVOL by using paths that are stored in AD DS. If drive letters change
after you add or remove disk drives, you must manually update the paths in AD DS.
Backing up GPOs
The successful operation of Group Policy depends on the reliable operation of SYSVOL. Key
components of GPOs exist in SYSVOL (in the policies subdirectory), and it is essential that these
GPO components remain synchronized with related components in AD DS. Therefore, backing up
only the SYSVOL component does not represent a full and complete backup of your GPOs. The
Group Policy Management Console (GPMC) provides both UI-based and scriptable methods for
backing up GPOs. It is important that you back up GPOs as part of your regular backup/disaster
recovery processes. Soon after installation of a new domain, the default domain and default
domain controllers' GPOs should be backed up. They should also be backed up after any
subsequent changes are made. GPOs are included in system state backups. For information
about backing up system state, see Backing Up Active Directory Domain Services. For
information about backing up GPOs, see Back Up a Group Policy Object
(http://go.microsoft.com/fwlink/?LinkID=122542).
Relocating SYSVOL
When you relocate SYSVOL, you must first copy the entire folder structure to a new location.
Then, you must update the junction points and path values that are stored in the registry and in
AD DS to maintain the relationships between the paths, the folders, and the junctions. As an
option, you can relocate the staging area and leave the rest of SYSVOL at its original location. In
this case, you must update the staging folder path in AD DS.
Relocating SYSVOL folders
SYSVOL relocation should be undertaken only when required by disk space maintenance or upgrades. By default, SYSVOL is contained in the %systemroot%\SYSVOL folder. The tree of folders that is contained within this folder can be extensive, depending on the size of SYSVOL, number of GPOs, and use of logon scripts. When you relocate SYSVOL folders, ensure that you copy all folders (including any hidden folders) and ensure that the relationships of the folders do not change.
Note
To ensure that all folders appear in Windows Explorer, on the Tools menu, click Folder Options. On the View tab, select Show hidden files and folders.
Before you attempt to relocate all or portions of SYSVOL, you must clearly understand the folder structure and the relationships between the folders and the path and size information that is stored in AD DS. When folders are moved, any associated values that are stored in AD DS and the registry must be updated to match the new location. The folder structure contains junction points that also require updating after folders are moved to a new location.
When you relocate folders, you use the first three levels of subdirectories to properly update the path locations that DFS Replication uses. These levels are affected by junction points and parameter settings. These folders include the following:
%systemroot%\SYSVOL
%systemroot%\SYSVOL\domain
%systemroot%\SYSVOL\domain\DfsrPrivate
%systemroot%\SYSVOL\domain\Policies
%systemroot%\SYSVOL\domain\scripts
%systemroot%\SYSVOL\staging
%systemroot%\SYSVOL\staging\domain
%systemroot%\SYSVOL\staging areas
%systemroot%\SYSVOL\staging areas\<FQDN>, where FQDN is the fully qualified domain name
of the domain that this domain controller hosts, for example, contoso.com.
%systemroot%\SYSVOL\sysvol
%systemroot%\SYSVOL\sysvol\<FQDN>, where FQDN is the fully qualified domain name of the
domain that this domain controller hosts, for example, contoso.com.
Note
If any of the folders do not appear in Windows Explorer, click Tools, and then click Folder Options. On the View tab, click Show hidden files and folders.
If you use Windows Explorer to view these folders, they appear to be typical folders. If you open a command prompt and type dir to list these folders, you notice that two special folders are listed as <JUNCTION>. Both folders labeled FQDN are junction points. The junction point in %systemroot%\SYSVOL\sysvol links to %systemroot%\SYSVOL\domain. The junction in %systemroot%\SYSVOL\staging areas links to %systemroot%\SYSVOL\staging\domain. If you change the path to the folders to which the
junctions are linked, you must also update the junctions, including drive letter changes and folder changes.
Besides junction points linking to folders within the SYSVOL tree, the registry and AD DS also store references to folders. These references contain paths that you must update if you change the location of the folder:
Registry: The SysVol Netlogon parameter in HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Netlogon\Parameters. This registry entry stores the path to
the sysvol shared folder (default %systemroot%\SYSVOL\sysvol). The Netlogon service uses this
path to identify the location of the folder that it uses to create the SYSVOL and NETLOGON
(scripts) share points.
AD DS: Two attributes in AD DS store the paths for the SYSVOL root and staging area folders, as
shown in the following table.
Directory value Default referenced location Contents
msDFSR-RootPath %systemroot\SYSVOL\domain Policies and scripts
msDFSR-StagingPath %systemroot\SYSVOL\staging\domain Staging area folders
SYSVOL Replication Migration Guide: FRS to DFS ReplicationPublished: April 15, 2009
Updated: August 25, 2010
Applies To: Windows Server 2008, Windows Server 2008 R2
Domain controllers use a special shared folder named SYSVOL to replicate logon scripts and Group Policy object files to other domain controllers. Windows 2000 Server and Windows Server 2003 use File Replication Service (FRS) to replicate SYSVOL, whereas Windows Server 2008 uses the newer DFS Replication service when in domains that use the Windows Server 2008 domain functional level, and FRS for domains that run older domain functional levels.
To use DFS Replication to replicate the SYSVOL folder, you can either create a new domain that uses the Windows Server 2008 domain functional level, or you can use the procedure that is discussed in this document to upgrade an existing domain and migrate replication to DFS Replication.
This document assumes that you have a basic knowledge of Active Directory Domain Services (AD DS), FRS, and Distributed File System Replication (DFS Replication). For more information, see Active Directory Domain Services Overview, FRS Overview, or Overview of DFS Replication
Note
To download a printable version of this guide, go to SYSVOL Replication Migration Guide: FRS to DFS Replication (http://go.microsoft.com/fwlink/?LinkId=150375)
In this guide
SYSVOL Migration Conceptual Information
SYSVOL Migration States
Overview of the SYSVOL Migration Procedure
SYSVOL Migration Procedure
Migrating to the Prepared State
Migrating to the Redirected State
Migrating to the Eliminated State
Troubleshooting SYSVOL Migration
Troubleshooting SYSVOL Migration Issues
Rolling Back SYSVOL Migration to a Previous Stable State
SYSVOL Migration Reference Information
Appendix A: Supported SYSVOL Migration Scenarios
Appendix B: Verifying the State of SYSVOL Migration
Appendix C: Dfsrmig Command Reference
Appendix D: SYSVOL Migration Tool Actions
Additional references
SYSVOL Migration Series: Part 1—Introduction to the SYSVOL migration process
SYSVOL Migration Series: Part 2—Dfsrmig.exe: The SYSVOL migration tool
SYSVOL Migration Series: Part 3—Migrating to the 'PREPARED' state
SYSVOL Migration Series: Part 4—Migrating to the ‘REDIRECTED’ state
SYSVOL Migration Series: Part 5—Migrating to the ‘ELIMINATED’ state
Step-by-Step Guide for Distributed File Systems in Windows Server 2008
FRS Technical Reference
Forcing ReplicationUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
When you need updates to be replicated sooner than the intersite replication schedule allows, or when replication between sites is impossible because of configuration errors, you can force replication to and from domain controllers. You can use the following two methods of forcing replication:
Force replication of all directory partition updates from one server to another server over a
connection
Force replication of configuration directory partition updates from one server to another server
Forcing replication of all directory updates over a connection
If you want to replicate certain updates, such as a significant addition of new passwords or user accounts, to another domain controller in the domain, you can use the Replicate now option in the Active Directory Sites and Services snap-in to force replication of all directory partitions over a connection object that represents inbound replication from a specific domain controller. A connection
object for a server object that represents a domain controller identifies the replication partner from which the domain controller receives replication. If the changes are made on one domain controller, you can select the connection from that domain controller and force replication to its replication partner.
You can also use the Repadmin.exe command-line tool to replication changes from a server to one or more other servers or to all servers.
Forcing replication of configuration updates
Active Directory replication uses a pull model, in which one domain controller requests changes from another domain controller. For this reason, connection objects always represent one-way, inbound replication from a source server to a destination server. All objects that are required for replication are contained in the configuration directory partition, which is replicated to every domain controller in the forest.
If a site link is deleted inadvertently, the domain controllers in the respective sites drop connection objects that represent servers in any site to which the domain controller’s site is no longer linked. The only way for these connection objects to be recreated is for a new site link to be created and for domain controllers in each site in the site link to recreate the connection objects. However, the change to the configuration directory partition (the new site link) cannot be replicated from the site where the change occurs to the other site because the domain controllers in the other site have dropped their inbound connection objects from servers in the site where the site link has been recreated. The Replicate now option does not fix the problem because the ability to use Replicate now depends on the existence of a from-server connection object.
On writable domain controllers running Windows Server 2003, the only way to resolve this issue is to create the new site link object twice, once on a domain controller in each site. When the domain controller has a site link, the Knowledge Consistency Checker (KCC) on the domain controller can then create connection objects from servers in the other site.
On writable domain controllers running Windows Server 2008, a new option is available that you can use to force replication of only the configuration directory partition to a domain controller in another site, even though a connection object from a server in the site does not exist in the configuration directory partition. In this case, you can recreate the site link in one site and force replication of this configuration change to a domain controller in the other site. When replication of the new site link object is received on the domain controller in the other site, that domain controller can then create new connection objects from servers in the other sites in the site link.
This functionality is particularly useful if the only domain controller in a site is a read-only domain controller (RODC). In this case, you cannot recreate the site link on a domain controller in both sites because you cannot write to the RODC. When you recreate the site link in the hub site and then force replication of the configuration directory partition to the site of the RODC, you enable the RODC to create connection objects from replication partners in the hub site.
Task requirements
The following tools are required to perform the procedures for this task:
Active Directory Sites and Services
Repadmin.exe
To complete this task, perform the following procedures:
1. Force Replication Between Domain Controllers
2. Update a Server with Configuration Changes
3. Synchronize Replication with All Partners
4. Verify Successful Replication to a Domain Controller
Configure the global catalog
Enabling Universal Group Membership Caching in a SiteUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
In a multidomain forest, when a user logs on to a domain, a global catalog server must be contacted to determine the universal group memberships of the user. A universal group can contain users from other domains, and it can be applied to access control lists (ACLs) on objects in all domains in the forest. Therefore, universal group memberships must be ascertained at domain logon so that the user has appropriate access in the domain and in other domains during the logon session. Only global catalog servers store the memberships of all universal groups in the forest.
If a global catalog server is not available in the site when a user logs on to a domain, the domain controller must contact a global catalog server in another site.
In multidomain forests where remote sites do not have a global catalog server, the need to contact a global catalog server over a potentially slow wide are network (WAN) connection can be problematic and a user can potentially be unable to log on to the domain if a global catalog server is not available. You can enable Universal Group Membership Caching on domain controllers that are running Windows Server 2008 so that when the domain controller contacts a global catalog server for the user’s initial domain logon, the domain controller retrieves universal group memberships for the user. On subsequent logon requests by the same user, the domain controller uses cached universal group memberships and does not have to contact a global catalog server.
Task requirements
The following tool is required to perform the procedures for this task:
Active Directory Sites and Services
To complete this task, perform the following procedure:
Enable Universal Group Membership Caching in a Site
Understanding the Global Catalog
Updated: December 30, 2008
Applies To: Windows Server 2008, Windows Server 2008 R2
The global catalog is the set of all objects in an Active Directory Domain Services (AD DS) forest. A global catalog server is a domain controller that stores a full copy of all objects in the directory for its host domain and a partial, read-only copy of all objects for all other domains in the forest. Global catalog servers respond to global catalog queries.
Attributes that replicate to the global catalog
The partial, read-only copies of objects that make up the global catalog are described as "partial" because they include a limited set of attributes—the attributes that are required by the schema plus the attributes that are most commonly used in user search operations. These attributes are marked for inclusion in the partial attribute set (PAS) as part of their schema definitions. Storing the most commonly searched attributes of all domain objects in the global catalog makes searches more efficient for users without affecting network performance with unnecessary referrals to domain controllers and without requiring a global catalog server to store large amounts of data that is not needed.
Global catalog functionality
When you install AD DS, the global catalog for a new forest is created automatically on the first domain controller in the forest. You can add global catalog functionality to additional domain controllers. You can also remove the global catalog from a domain controller.
A global catalog server:
Finds objects.
The 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 a user searches for people or printers from the Start menu or selects the Entire
Directory option in a query, that user is searching the global catalog. After the user enters a
search request, the request is routed to the default global catalog port 3268 and sent to a global
catalog server for resolution.
Supplies user principal name authentication.
A global catalog server resolves a user principal name (UPN) when the authenticating domain
controller has no knowledge of the user account. For example, if a user’s account is located in
sales1.cohovineyard.com and the user logs on with a UPN of [email protected]
from a computer that is located in sales2.cohovineyard.com, the domain controller in
sales2.cohovineyard.com cannot find the user’s account and it must contact a global catalog
server to complete the logon process.
Validates object references within a forest.
Domain controllers use the global catalog to validate references to objects of other domains in
the forest. When a domain controller holds a directory object with an attribute that contains a
reference to an object in another domain, the domain controller validates the reference by
contacting a global catalog server.
Supplies universal group membership information in a multiple-domain environment.
A domain controller can always discover domain local group and global group memberships for
any user in its domain, and the membership of these groups is not replicated to the global
catalog. In a single-domain forest, a domain controller can also always discover universal group
memberships. However, universal groups can have members in different domains. For this
reason, the member attribute of universal groups, which contains the list of members in the
group, is replicated to the global catalog. When a user in a multiple-domain forest logs on to a
domain where universal groups are allowed, the domain controller must contact a global catalog
server to retrieve any universal group memberships that the user might have in other domains.
If a global catalog server is not available when a user logs on to a domain where universal
groups are available, the user's client computer can use cached credentials to log on if the user
has logged on to the domain previously. If the user has not logged on to the domain previously,
the user can log on only to the local computer.
Note
The Administrator in the domain (the Builtin Administrator account) can always log on to the domain, even when a global catalog server is not available.
Universal group membership caching
On domain controllers running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 in a site that has no global catalog server, you can use universal group membership caching to reduce
the need to contact a global catalog server in a different site. When this feature is enabled, the first time that a user logs on to a domain where universal groups are available, the user's universal group membership information is cached on the domain controller. Thereafter, the domain controller uses cached memberships to process the logon, rather than having to contact a global catalog server.
Additional references
Adding the Global Catalog to a Site
Add or Remove the Global Catalog
Introduction to Administering the Global CatalogUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
Designate global catalog servers in sites to accommodate forest-wide directory searching and to facilitate domain client logons when universal groups are available (that is, when a domain has a domain functional level of Windows Server 2008, Windows Server 2003, or Windows 2000 native). When universal groups are available in a domain, a domain controller must be able to locate a global catalog server to process a logon request.
Global catalog hardware requirements
Minimum hardware requirements for global catalog servers depend on the number of users in the site. For disk space requirements and directory database storage guidelines, see Planning Domain Controller Capacity (http://go.microsoft.com/fwlink/?LinkId=80404).
Global catalog placement
In most cases, we recommend that you include the global catalog when you install new domain controllers. The following exceptions apply:
Limited bandwidth: In remote sites, if the wide area network (WAN) link between the remote site and the hub site is limited, you can use universal group membership caching in the remote site to accommodate the logon needs of users in the site. For information about universal group membership caching, see Enabling Universal Group Membership Caching in a Site.
Infrastructure operations master role incompatibility: Do not place the global catalog on a domain controller that hosts the infrastructure operations master role in the domain unless all domain controllers in the domain are global catalog servers or the forest has only one domain.
Initial global catalog replication
When you add a global catalog server to a site, the Knowledge Consistency Checker (KCC) updates the replication topology, after which replication of partial domain directory partitions that are available within the site begins. Replication of partial domain directory partitions that are available only from other sites begins at the next scheduled interval.
Adding subsequent global catalog servers within the same site requires only intrasite replication and does not affect network performance. Replication of the global catalog potentially affects network performance only when you add the first global catalog server in the site. The impact of this replication varies, depending on the following conditions:
The speed and reliability of the WAN link or links to the site
The size of the forest
For example, in a forest that has a large hub site, five domains, and thirty small branch sites (some of which are connected by only dial-up connections), global catalog replication to the small sites takes considerably longer than replication of one or two domains to a few well-connected sites.
Global catalog readiness
A global catalog server is available to directory clients when Domain Name System (DNS) servers can locate it as a global catalog server. Several conditions must be met before the global catalog server is locatable by clients. These conditions are divided into seven levels (numbered 0 to 6) of readiness, called occupancy levels. At each level, a specific degree of synchronization must be achieved before occupancy moves to the next level. By default, domain controllers running Windows Server 2008 require all levels to be reached before the global catalog is ready for use. At level 6, all partial, read-only directory partitions have been successfully replicated to the global catalog server. When the requirements of all occupancy levels have been satisfied, the Net Logon service on the global catalog server registers DNS service (SRV) resource records that identify the domain controller as a global catalog server in the site and in the forest. For more information about global catalog readiness and occupancy levels, see How the Global Catalog Works (http://go.microsoft.com/fwlink/?LinkID=107063).
In summary, a global catalog server is ready to serve clients when the following events occur, in this order:
The global catalog receives replication of read-only replicas to the required occupancy level.
The isGlobalCatalogReady rootDSE attribute is set to TRUE.
The Net Logon service on the domain controller has updated DNS with global-catalog-specific
service (SRV) resource records.
At this point, the global catalog server begins accepting queries on ports 3268 and 3269.
Global catalog removal
When you remove the global catalog from a domain controller, that domain controller immediately stops advertising in DNS as a global catalog server. The Knowledge Consistency Checker (KCC) gradually removes the read-only replicas from the domain controller. On domain controllers running Windows Server 2008 or Windows Server 2003, the global catalog, partial, read-only directory partitions are removed in the background, and they receive a low priority so that high-priority services are not interrupted.
You might decide to remove the global catalog from a domain controller if universal group membership caching is adequate to satisfy logon requirements in a particular site where WAN link speeds are not adequate for the global catalog. For more information, see Enabling Universal Group Membership Caching in a Site.
For more information about global catalog removal, see How the Global Catalog Works (http://go.microsoft.com/fwlink/?LinkID=107063).
Checklist: Add a Global Catalog ServerUpdated: June 18, 2007
Applies To: Windows Server 2008
If you have more than one domain in your forest and you have a significant user population in a site, you can optimize the speed and efficiency of domain logons and directory searches by adding a global catalog server to the site.
If you have a single-domain forest, global catalog servers are not required for logons, but directory searches are directed to the global catalog. In this case, you can enable the global catalog on all domain controllers for faster directory searches.
Task Reference
(Optional) Review global catalog concepts. Understanding the Global Catalog
Add or remove the global catalog read-only directory partitions from a domain controller in the site.
Add or Remove the Global Catalog
Confirm that all read-only directory partitions have been replicated to the new global catalog server.
Verify Global Catalog Readiness
Verify that the global catalog server is being advertised in Domain Name System (DNS).
Verify Global Catalog DNS Registrations
Configuring a Global Catalog ServerUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
When conditions in a site warrant adding a global catalog server, you can configure a domain controller to be a global catalog server. Selecting the global catalog setting on the NTDS Settings object prompts the Knowledge Consistency Checker (KCC) to update the topology. After the topology is updated, read-only, partial, domain directory partitions are replicated to the designated domain controller. When replication must occur between sites to create the global catalog, the site link schedule determines when replication can occur.
Task requirements
The following tools are required to perform the procedures for this task:
Active Directory Sites and Services
Repadmin.exe
Dcdiag.exe
To complete this task, perform the following procedures.
Note
Some procedures are performed only when you are configuring the first global catalog server in a site.
1. Determine Whether a Domain Controller Is a Global Catalog Server
Determine Whether a Domain Controller Is a Global Catalog Server
Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
You can use the setting on the NTDS Settings object to determine whether a domain controller is designated as a global catalog server.
Membership in Domain Users, or equivalent, is the minimum required to complete this procedure when you perform the procedure remotely by using Remote Server Administration Tools (RSAT). Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To determine whether a domain controller is a global catalog server1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools,
and then click Active Directory Sites and Services. If the User Account Control dialog box
appears, provide credentials, if required, and then click Continue.
2. In the console tree, expand the Sites container, expand the site of the domain controller that
you want to check, expand the Servers container, and then expand the Server object.
3. Right-click the NTDS Settings object, and then click Properties.
4. On the General tab, if the Global Catalog box is selected, the domain controller is designated
as a global catalog server.
2. Designate a Domain Controller to Be a Global Catalog Server
Designate a Domain Controller to Be a Global Catalog Server
Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
You use this procedure to designate a domain controller as a global catalog server. When you designate a domain controller as a global catalog server, a partial, read-only directory partition for each domain in the forest, other than the full, writable directory partition of the local domain, is replicated to create the global catalog instance on the server.
Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To designate a domain controller to be a global catalog server1. Click Start, point to Administrative Tools, and then click Active Directory Sites and
Services.
2. In the console tree, expand the Sites container, and then expand the site in which you are
designating a global catalog server.
3. Expand the Servers container, and then expand the Server object for the domain controller
that you want to designate as a global catalog server.
4. Right-click the NTDS Settings object for the target server, and then click Properties.
5. Select the Global Catalog check box, and then click OK.
3. Monitor Global Catalog Replication Progress
Monitor Global Catalog Replication Progress
Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
You can monitor inbound replication progress to see the percentage of completeness of partial, read-only, directory partition replication to the new global catalog server.
Note
Although you can change occupancy level requirements for global catalog advertisement to force advertisement to occur before full replica occupancy, doing so can cause e-mail and search issues. Exchange servers use the global catalog for Address Book lookup. Therefore, in addition to causing Active Directory client search problems, the condition of a global catalog server being advertised before it receives all partial replicas can cause Address Book lookup and e-mail delivery problems for Exchange clients.
Membership in Domain Users and the right to log on locally to the domain controller is the minimum required to complete this procedure. By default, members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the right to log on locally to a domain controller. Review details about using the appropriate
accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To monitor global catalog replication progress1. Open a Command Prompt as an administrator: On the Start menu, 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 Continue.
2. At the command prompt, type the following command, and then press ENTER:
dcdiag /s:<servername> /v | find "%"
Parameter Description
s:<servername> Specifies the name of the global catalog server that you want to monitor.
/v | find "%" Finds the percentage of replication, and provides extended information.
3. Repeat this command periodically to monitor progress. If the test shows no output, replication
has completed.
4. Verify Successful Replication to a Domain Controller
Verify Successful Replication to a Domain Controller
Updated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
You can use the repadmin /showrepl command to verify successful replication to a specific domain controller. If you are not running Repadmin on the domain controller whose replication you are checking, you can specify a destination domain controller in the command. Repadmin lists INBOUND NEIGHBORS for the current or specified domain controller. INBOUND NEIGHBORS shows the distinguished name of each directory partition for which inbound directory replication has been attempted, the site and name of the source domain controller, and whether replication succeeded or not, as follows:
Last attempt @ <YYYY-MM-DD HH:MM.SS> was successful.
Last attempt @ [Never] was successful.
If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection.
Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To verify successful replication to a domain controller1. Open a Command Prompt as an administrator: On the Start menu, right-click Command
Prompt, and then click Run as administrator. If the User Account Control dialog box
appears, provide Domain Admins credentials, if required, and then click Continue.
2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl <servername> /u:<domainname>\<username> /pw:*
Note
The user credential parameters (/u:<domainname>\<username> /pw:*) are not required
for the domain of the user if the user has opened the Command Prompt as an administrator with Domain Admins credentials or is logged on to the domain controller as a member of Domain Admins or equivalent. However, if you run the command for a domain controller in a different domain in the same Command Prompt session, you must provide credentials for an account in that domain.
Value Description
repadmin /showrepl
Displays the replication status for the last time that the domain controller that is named in <servername> attempted inbound replication of Active Directory partitions.
<servername> The name of the destination domain controller.
/u: Specifies the domain name and user name, separated by a backslash, for a user who has permissions to perform operations in AD DS.
<domainname> The single-label name of the domain of the destination domain controller. (You do not have to use a fully qualified Domain Name System (DNS) name.)
<username> The name of an administrative account in that domain.
/pw:* Specifies the domain password for the user named in <username>. * provides a Password: prompt when you press ENTER.
3. At the Password: prompt, type the password for the user account that you provided, and then
press ENTER.
You can also use repadmin to generate the details of replication to and from all replication partners in a Microsoft Excel spreadsheet. The spreadsheet displays data in the following columns:
Showrepl_COLUMNS
Destination DC Site
Destination DC
Naming Context
Source DC Site
Source DC
Transport Type
Number of Failures
Last Failure Time
Last Success Time
Last Failure Status
The following procedure creates this spreadsheet and sets column headings for improved readability.
To generate a repadmin /showrepl spreadsheet for all replication partners1. Open a Command Prompt as an administrator: On the Start menu, right-click Command
Prompt, and then click Run as administrator. If the User Account Control dialog box
appears, provide Domain Admins credentials, if required, and then click Continue.
2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv >showrepl.csv
3. Open Excel.
4. Click the Office button, click Open, navigate to showrepl.csv, and then click Open.
5. Hide or delete column A as well as the Transport Type column, as follows:
6. Select a column that you want to hide or delete.
To hide the column, right-click the column, and then click Hide.
Or
To delete the column, right-click the selected column, and then click Delete.
7. Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then
click Freeze Top Row.
8. Select the entire spreadsheet. On the Data tab, click Filter.
9. In the Last Success Time column, click the down arrow, and then click Sort Ascending.
10. In the Source DC column, click the filter down arrow, point to Text Filters, and then click
Custom Filter.
11. In the Custom AutoFilter dialog box, under Show rows where, click does not contain. In
the adjacent text box, type del to eliminate from view the results for deleted domain
controllers.
12. Repeat step 11 for the Last Failure Time column, but use the value does not equal, and then
type the value 0.
13. Resolve replication failures.
The last successful attempt should agree with the replication schedule for intersite replication, or the attempt should be within the last hour for intrasite replication.
If Repadmin reports any of the following conditions, see Troubleshooting Active Directory Replication Problems (http://go.microsoft.com/fwlink/?LinkID=93582):
The last successful intersite replication was before the last scheduled replication.
The last intrasite replication was longer than one hour ago.
Replication was never successful.
Configure operations masters
Introduction to Administering the Windows Time ServiceUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
The Windows Server 2008 Windows Time service (W32time) synchronizes the date and time for all computers running on a Windows Server 2008 network. The service integrates Network Time Protocol (NTP) and time providers, making it a reliable and scalable time service for enterprise administrators.
The purpose of the Windows Time service is to make sure that all computers running versions of Windows 2000 Server, Windows Server 2003, Windows XP, Windows Vista, or Windows Server 2008 in an organization use a common time. To guarantee appropriate common time usage, the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops. A domain controller at the top of the hierarchy provides authoritative time to all other domain controllers, and domain clients use domain controllers as their time source. By default, the domain controller at the top of the hierarchy is the primary domain controller (PDC) operations master (also known as flexible single master operations or FSMO) in the forest root domain.
Windows time source selection
By default, Windows-based computers use the following sources for time synchronization:
For computers that are joined to a domain, the first query is to a time source in the parent
domain.
Note
Computers that are not joined to a domain and are running Windows Vista are configured to synchronize with the following external time sources by default: time.windows.com, time.nist.gov, time-nw.nist.gov, time-a.nist.gov, and time-b.nist.gov. Computers that are not joined to a domain and are running Windows XP or Windows XP Home Edition are configured to synchronize with time.windows.com by default.
If the time client is in a single-domain forest, the first query is to the PDC emulator in the
domain.
All PDC emulator operations masters follow the hierarchy of domains in the selection of their
inbound time partner. A PDC emulator can synchronize its time from the PDC emulator in the
parent domain or from any domain controller in the parent domain.
For more information about time source selection, see How Windows Time Service Works (http://go.microsoft.com/fwlink/?LinkID=117753).
The authoritative time source at the root of the forest can acquire its time either by connecting to an installed hardware clock on the internal network or by connecting to an external NTP server, which is connected to a hardware device. If no domain controller is configured as the authoritative time source in the forest root domain, the domain controller that holds the PDC emulator operations master role uses its internal clock to provide time to forest computers.
External NTP time servers
Many external NTP servers are available over the Internet. Use the following information to select an NTP server:
The National Institute of Standards and Technology (NIST) in Boulder, Colorado, which is used as
the external time provider by the Microsoft time server (time.windows.com). NIST provides the
Automated Computer Time Service (ACTS), which can set a computer clock with an uncertainty
of less than 10 milliseconds. For more information about NTP and for a list of external time
servers, see Set Your Computer Clock Via the Internet: NIST Internet Time Service (ITS)
(http://go.microsoft.com/fwlink/?LinkId=112035).
The U.S. Naval Observatory (USNO) Time Service Department in Washington, DC, is another
reliable source for accurate time synchronization in the United States. To see a list of USNO
servers and their descriptions, see USNO Network Time Servers (http://go.microsoft.com/fwlink/?
LinkId=112036).
You can use many other sites throughout the world for time synchronization. For more NTP
server lists and search criteria, see the NTP.Servers Web site (http://go.microsoft.com/fwlink/?
LinkId=116972).
For the most highly accurate time synchronization, configure a hardware clock, such as a radio or Global Positioning System (GPS) device, as the time source for the PDC. There are many consumer and enterprise devices that use NTP, which makes it possible for you to install the device on an internal network for use with the PDC.
You use the w32tm command-line tool to configure Windows Time service. For a detailed technical reference for the Windows Time service, including complete documentation of the w32tm command-line tool and time service registry settings, see the Windows Time Service Technical Reference (http://go.microsoft.com/fwlink/?LinkID=100940).
W32tm and net time
The net time commands are predecessors of w32tm commands, and they should not be used to configure the Windows Time service or to set the time on a computer while the Windows Time service is actively running. The recommended method for configuring the Windows Time service and displaying Windows Time service information for Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 operating systems is to use w32tm commands.
Although the command net time /querysntp appears to display the Simple Network Time Protocol (SNTP) server for Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 operating systems, it does not display complete time configuration information. On Windows Vista and Windows Server 2008, you can use the command w32tm /query /configuration to determine whether the computer is configured to synchronize time from the domain hierarchy or from a manual list of time servers. (On Windows XP and Windows Server 2003, you can use the command w32tm /dumpreg /subkey:parameters). The command output includes a line labeled Type that identifies the time synchronization method that the client is using. The following Type line outputs are possible for the time client:
NoSync: The client does not synchronize time.
NTP: The client synchronizes time from an external time source. Review the values in the
NtpServer line in the output to see the name of the server or servers that the client uses for
time synchronization.
NT5DS: The client is configured to use the domain hierarchy for its time synchronization.
AllSync: The client synchronizes time from any available time source, including domain
hierarchy and external time sources.
For information about Windows Time Server Internet communication, see Windows Time Service and Resulting Internet Communication in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=116982).
Introduction to Administering Operations Master RolesUpdated: July 24, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
Domain controllers that hold operations master (also known as flexible single master operations or FSMO) roles keep the directory functioning properly by performing specific tasks that no other domain controllers are permitted to perform.
Three operations master roles exist in each domain:
The primary domain controller (PDC) emulator operations master. The PDC emulator
operations master processes all replication requests from Windows NT Server 4.0 backup
domain controllers (BDCs). It also processes all password updates for clients not running
Active Directory–enabled client software, plus any other directory write operations. The PDC
emulator receives preferential replication of password changes that are performed by other
domain controllers in the domain, and it is the source for the latest password information
whenever a logon attempt fails as a result of a bad password. For this reason, of all operations
master roles, the PDC emulator operations master role has the highest impact on the
performance of the domain controller that hosts that role. The PDC emulator in the forest root
domain is also the default Windows Time service (W32time) time source for the forest.
The relative ID (RID) operations master. The RID master allocates RID pools to all domain
controllers to ensure that new security principals can be created with a unique identifier.
The infrastructure operations master. The infrastructure master manages references from
objects in its domain to objects in other domains. It also updates group-to-user references when
the members of groups are renamed or changed.
In addition to the three domain-level operations master roles, two operations master roles exist in each forest:
The schema operations master. The schema master governs all changes to the schema.
The domain naming operations master. The domain naming master adds and removes
domain directory partitions and application directory partitions to and from the forest.
To perform their respective operations, the domain controllers that host operations master roles must be consistently available and they must be located in areas where network reliability is high. Careful placement of your operations masters becomes more important as you add more domains and sites as you build your forest.
Guidelines for role placement
Improper placement of operations master role holders can prevent clients from changing their passwords or being able to add domains and new objects, such as Users and Groups. Schema changes might not be possible. In addition, name changes might appear improperly within group memberships that are displayed in the user interface (UI).
Note
Operations master roles cannot be placed on a read-only domain controller (RODC).
As your environment changes, you must avoid the problems that are associated with improper operations master role placement. Eventually, you might have to reassign the roles to other domain controllers.
Although you can assign the forest-level and domain-level operations master roles to any domain controller in the forest and domain, respectively, improper infrastructure master role placement can cause the infrastructure master to perform incorrectly. Other improper operations master configurations can increase administrative overhead. Following these guidelines will help to minimize administrative overhead and ensure the proper performance of Active Directory Domain Services (AD DS). Following these guidelines will simplify the recovery process if a domain controller that is hosting an operations master role fails.
Follow these guidelines for operations master role placement:
Configure an additional domain controller as the standby operations master for the forest-level
roles. Configure an additional domain controller as the standby operations master for the
domain-level roles.
Place the domain-level roles on a high-performance domain controller.
Do not place domain-level roles on a global catalog server.
Leave the two forest-level roles on a domain controller in the forest root domain.
In the forest root domain, transfer the three domain-level roles from the first domain controller
that you installed in the forest root domain to an additional domain controller that has a high
performance level.
In all other domains, leave the domain-level roles on the first domain controller.
Adjust the workload of the PDC emulator, if necessary.
Prepare additional domain controllers as standby operations masters
Because the operations master roles are critical to proper forest and domain function, it is important to be prepared in the event that an operations master role holder becomes inoperable or unreachable. You can prepare an additional domain controller for the forest roles in the forest root domain and an additional domain controller for the domain roles in each domain by configuring them to be optimally connected to the respective current role holder so that role transfer occurs as quickly as possible.
Place domain-level roles on a high-performance domain controller
The PDC emulator role requires a powerful and reliable domain controller to ensure that the domain controller is available and capable of handling the workload. Of all the operations master roles, the PDC emulator role creates the most overhead on the server that is hosting the role. It has the most intensive daily interaction with other systems on the network. The PDC emulator has the greatest potential to affect daily operations of the directory.
Domain controllers can become overloaded while attempting to service client requests on the network, manage their own resources, and handle any specialized tasks, such as performing the various operations master roles. This is especially true of the domain controller that holds the PDC emulator role. Again, clients running operating systems earlier than Windows 2000 Server and domain controllers running Windows NT Server 4.0 rely more heavily on the PDC emulator than AD DS clients and domain controllers. If your networking environment has clients and domain controllers running operating systems earlier than Windows 2000 Server, you might need to reduce the workload of the PDC emulator.
If a domain controller begins to indicate that it is overloaded and its performance is affected, you can reconfigure the environment so that some tasks are performed by other, less-used domain controllers. By adjusting the domain controller’s weight in the Domain Name System (DNS) environment, you can configure the domain controller to receive fewer client requests than other domain controllers on your network. As an option, you can adjust the domain controller’s priority in the DNS environment so that it processes client requests only if other DNS servers are unavailable. With fewer DNS client requests to process, the domain controller can use more resources to perform operations master services for the domain.
Do not place domain-level roles on a global catalog server
The infrastructure master is incompatible with the global catalog, and it must not be placed on a global catalog server. Because it is best to keep the three domain-level roles together for ease of administration, avoid putting any of them on a global catalog server.
The infrastructure master updates objects for any attribute values with distinguished name (dn) syntax that reference objects outside the current domain. These updates are particularly important for security principal objects (users, computers, and groups). For example, suppose a user from one domain is a member of a group in a second domain and the user’s surname (the sn attribute on the user object) is changed in the first domain. This change usually also changes the dn attribute value of the user object, which is the value that is used in the member attribute of group objects. Because domain controllers in one domain do not replicate security principals to domain controllers in another domain, the second domain never receives the change. An out-of-date value on the member attribute of a group in another domain could result in the user whose name has changed being denied privileges. To ensure consistency between domains, the infrastructure master constantly monitors group memberships, looking for member attribute values that identify security principals from other domains. If it finds one, it compares its distinguished name with the distinguished name in the domain of the security principal to determine if the information has changed. If the information on the infrastructure master is out of date, the infrastructure master performs an update and then replicates the change to the other domain controllers in its domain.
Two exceptions apply to this rule:
1. If all the domain controllers are global catalog servers, the domain controller that hosts the
infrastructure master role is insignificant because global catalog servers replicate updated
security principal information to all other global catalog servers.
2. If the forest has only one domain, the infrastructure master role is not needed because security
principals from other domains do not exist.
Leave forest-level roles on the original domain controller in the forest root domain
The first domain controller that is installed in the forest automatically receives the schema master and domain naming master roles. It also hosts the global catalog. To ease administration and backup and restore procedures, leave these roles on the original forest root domain controller. The roles are compatible with the global catalog, and moving the roles to other domain controllers does not improve performance. Separating the roles creates additional administrative overhead when you must identify the standby operations masters and when you implement a backup and restore policy.
Unlike the PDC emulator role, forest-level roles rarely place a significant burden on the domain controller. Keep these roles together to provide easy, predictable management.
In the forest root domain, transfer domain-level roles from the first domain controller
The three domain-level roles are assigned to the first domain controller that is created in a new domain. In the case of the forest root domain, the first domain controller that is created in the domain hosts both forest-level roles and all three domain-level roles, as well as the global catalog. The infrastructure master role is incompatible with the global catalog. For this reason, when you install the second domain controller in the forest root domain, the Active Directory Domain Services Installation Wizard prompts you to allow the wizard to transfer the role during installation of AD DS. Following installation of the second domain controller, consider transferring the PDC emulator and RID master roles to the second domain controller, as well, to keep the three roles together for easy administration.
In all other domains, leave domain-level roles on the first domain controller
Except for the forest root domain, leave the domain-level roles on the first domain controller that you install in the domain and do not configure that domain controller as a global catalog server. Keep the roles together unless the workload on your operations master justifies the additional management burden of separating the roles.
Because all clients running non-Windows operating systems or Windows operating systems earlier than Windows 2000 Server submit updates to the PDC emulator, the domain controller holding that role uses a higher number of RIDs when the network hosts many of these clients. Place the PDC emulator and RID master roles on the same domain controller so that these two roles interact more efficiently.
If you must separate the roles, you can still use a single standby operations master for all three roles. However, you must ensure that the standby is a replication partner of all three of the role holders.
Backup and restore procedures also become more complex if you separate the roles. Special care must be taken to restore a domain controller that hosted an operations master role. By hosting the roles on a single computer, you minimize the steps that are required to restore a role holder.
Adjust the workload of the PDC emulator operations master role holder
Depending on the size of the forest or domain, you might want to configure DNS so that client requests favor domain controllers other than the PDC emulator. The PDC emulator role has the highest load demands of all the operations master roles.
Guidelines for role transfer
Role transfer is the preferred method to move an operations master role from one domain controller to another. During a role transfer, the two domain controllers replicate to ensure that no information is lost. After the transfer is complete, the previous role holder no longer attempts to perform as the operations master, which eliminates the possibility of duplicate operations masters existing on the network.
Consider moving the operations master role or roles when any of the following conditions exist:
Inadequate service performance
Failure of a domain controller that hosts an operations master role
Decommissioning of a domain controller that hosts an operations master role
Administrative configuration changes that affect operations master role placement
Inadequate service performance
The PDC emulator is the operations master role that most affects the performance of a domain controller. For clients that do not run Active Directory client software, the PDC emulator processes requests for password changes, replication, and user authentication. While it provides support for these clients, the domain controller continues to perform its normal services, such as authenticating Active Directory–enabled clients. As the network grows, the volume of client requests can increase the workload for the domain controller that hosts the PDC emulator role and its performance can suffer. To solve this problem, you can transfer all or some of the operations master roles to another, more powerful domain controller. As an alternative, you may choose to transfer the role to another domain controller, upgrade the hardware on the original domain controller, and then transfer the role back again.
Operations master failure
In the event of a failure of an operations role holder, you must decide if you need to relocate the operations master roles to another domain controller or wait for the domain controller to be returned to service. Base that determination on the role that the domain controller hosts and the expected downtime.
Decommissioning of the domain controller
Before you take a domain controller offline permanently, transfer any operations master roles that the domain controller holds to another domain controller.
When you use the Active Directory Installation Wizard to decommission a domain controller that currently hosts one or more operations master roles, the wizard reassigns the roles to a different domain controller. When the wizard is run, it determines whether the domain controller currently hosts any operations master roles. If it detects any operations master roles, it queries the directory for other eligible domain controllers and transfers the roles to a new domain controller. A domain controller is eligible to host the domain-level roles if it is a member of the same domain. A domain controller is eligible to host a forest-level role if it is a member of the same forest.
Configuration changes
Configuration changes to domain controllers or the network topology can result in the need to transfer operations master roles. Except for the infrastructure master, you can assign operations master roles to any domain controller regardless of any other tasks that the domain controller performs. Do not host the infrastructure master role on a domain controller that is also acting as a global catalog server unless all the domain controllers in the domain are global catalog servers or unless the forest has only one domain. If the domain controller that hosts the infrastructure master role is configured to be a global catalog server, you must transfer the infrastructure master role to another domain controller. Changes to the network topology can result in the need to transfer operations master roles to keep them in a particular site.
Note
Do not change the global catalog configuration on the domain controller that you intend to assume an operations master role unless your information technology (IT) management authorizes that change. Changing the global catalog configuration can cause changes that can take days to complete, and the domain controller might not be available during that period. Instead, transfer the operations master roles to a different domain controller that is already configured properly.
You can reassign an operations master role by transfer or, as a last resort, by seizure.
Important
If you must seize an operations master role, never reattach the previous role holder to the network without following the procedures in this guide. Reattaching the previous role holder to the network incorrectly can result in invalid data and corruption of data
Transferring an Operations Master RoleUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
When you create a new domain, the Active Directory Domain Services Installation Wizard automatically assigns all the domain-level operations master roles to the first domain controller that is created in that domain. When you create a new forest, the wizard also assigns the two forest-level operations master roles to the first domain controller. After the domain is created and functioning, you might transfer various operations master roles to different domain controllers to optimize performance and simplify administration.
The first domain controller that you install to create a new forest is necessarily both a global catalog server and the infrastructure operations master role holder. When you install the second domain controller in the forest root domain, the Active Directory Domain Services Installation Wizard prompts you to transfer the infrastructure master role to the domain controller that you are installing. Select this option to avoid having to transfer the infrastructure operations master role manually.
The transfer of forest-level and domain-level operations master roles is performed as needed, and it is governed by the guidelines for placing operations master roles. Before you transfer an operations master role, ensure that replication between the current role holder and the domain controller that is assuming the role is updated.
When you transfer domain-level roles, you must determine whether the domain controller that you want to assume an operations master role is a global catalog server. The infrastructure master for each domain must not host the global catalog.
Caution
Do not change the global catalog configuration on the domain controller that you want to assume an operations master role unless your information technology (IT) management authorizes that change. Changing the global catalog configuration can cause changes that can take days to complete, and the domain controller might not be available during that period. Instead, transfer the operations master roles to a different domain controller that is already properly configured.
Transferring to a standby operations master
When you follow the recommendations for operations master role placement, the standby operations master is a direct replication partner and it is ready to assume the operations master roles. Remember to designate a new standby operations master for the domain controller that assumes the operations master roles. For more information, see Designating a Standby Operations Master.
Transferring an operations master role when no standby is ready
If you have not designated a standby operations master, you must properly prepare a domain controller to which you intend to transfer the operations master roles. If you are transferring the infrastructure master role, make sure that the target domain controller is not a global catalog server. Preparing the future operations master role holder is the same process as preparing a standby operations master. You must manually create a connection object to ensure that the standby operations master is a replication partner with the current role holder and that replication between the two domain controllers is updated.
Task requirements
The following are required to perform the procedures for this task:
Repadmin.exe
Active Directory Sites and Services
Active Directory Domains and Trusts
Active Directory Schema snap-in
Active Directory Users and Computers
Ntdsutil.exe
To complete this task, perform the following procedure:
Verify Successful Replication to a Domain Controller
Determine Whether a Domain Controller Is a Global Catalog Server
Install the Schema Snap-In
Transfer the Schema Master
Transfer the Domain Naming Master
Transfer the Domain-Level Operations Master Roles
View the Current Operations Master Role Holders
Seizing an operations master roleUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
Role seizure is the act of assigning an operations master (also known as flexible single master operations or FSMO) role to a new domain controller without the cooperation of the current role holder—usually, because the current role holder is offline as a result of a hardware failure. During role seizure, the new domain controller assumes the operations master role without communicating with the current role holder.
Role seizure should be performed only as a last resort. Role seizure can cause the following directory problems:
Data loss or directory inconsistency as a result of replication latency. The new role
holder starts performing its duties based on the data that is located in its current directory
partition. If replication did not complete before the time that the original role holder went
offline, the new role holder might not have received the latest changes.
To minimize the risk of losing data to incomplete replication, do not perform a role seizure until
enough time has passed to complete at least one end-to-end replication cycle across your
network. Allowing enough time for complete end-to-end replication ensures that the domain
controller that assumes the role is as up to date as possible.
Two domain controllers performing the same role. Because the original role holder is
offline when role seizure occurs, the original role holder is not informed that it is no longer the
operations master role holder, which is not a problem if the original role holder stays offline.
However, if the original role holder comes back online—for example, if the hardware is repaired
or the server is restored from a backup)—it might try to perform the operations master role that
it previously owned. If two domain controllers are performing the same operations master role
simultaneously, the severity of the effect from duplicate operations master roles varies,
depending on the role that was seized. The effect can range from no visible effect to potential
corruption of the Active Directory database. Do not allow a former operations master role holder
whose role has been seized to return to an online domain controller.
Task requirements
The following is required to perform the procedures for this task:
Repadmin.exe
Ntdsutil.exe
To complete this task, perform the following procedure:
Verify Successful Replication to a Domain Controller
Verify replication to the domain controller that will be seizing the role.
Seize the Operations Master Role
View the Current Operations Master Role Holders
Designating a Standby Operations MasterUpdated: January 9, 2009
Applies To: Windows Server 2008, Windows Server 2008 R2
A standby operations master is a domain controller that you identify as the computer that assumes the operations master role if the original computer fails. A single domain controller can act as the standby operations master for all the operations master roles in a domain, or you can designate a separate standby for each operations master role.
When you designate a domain controller as the standby operations master, follow all the recommendations in "Guidelines for Role Placement" in Introduction to Administering Operations Master Roles.
Standby operations master computer requirements
No utilities or special steps are required to designate a domain controller as a standby operations master. However, the current operations master and the standby operations master should be well connected. “Well connected” means that the network connection between them must support at least a 10-megabit transmission rate and be available at all times. In addition, creating a manual connection object between the standby domain controller and the operations master will ensure direct replication between the two operations masters. By making the operations master and the standby operations master direct replication partners, you reduce the chance of data loss in the event of a role seizure, which reduces the chance of directory corruption.
Replication requirements
Before you transfer a role from the current role holder to the standby operations master, ensure that replication between the two computers is functioning properly. Because they are replication partners, the new operations master is already consistent with the original operations master, which reduces the time that is required for the transfer operation.
During role transfer, the two domain controllers exchange any unreplicated information to ensure that no transactions are lost. If the two domain controllers are not direct replication partners, a substantial amount of information might have to be replicated before the domain controllers completely synchronize with each other. The role transfer requires extra time to replicate the outstanding transactions. If the two domain controllers are direct replication partners, fewer outstanding transactions exist and the role transfer operation completes sooner.
Task requirements
The following tools are required to perform the procedures for this task:
Active Directory Sites and Services
Repadmin.exe
To complete this task, perform the following procedure:
Determine Whether a Domain Controller Is a Global Catalog Server
Create a Connection Object on the Operations Master and Standby
Verify Successful Replication to a Domain Controller
Active Directory SchemaUpdated: May 1, 2010
Applies To: Windows Server 2008
Active Directory® Schema is a Microsoft Management Console (MMC) snap-in that you can use to view and manage the Active Directory Domain Services (AD DS) schema.
Note
You can also use the Active Directory Schema snap-in to view and manage Active Directory Lightweight Directory Services (AD LDS) schema objects.
Schema definitions
The schema contains formal definitions of every object class that can be created in an Active Directory forest. The schema also contains formal definitions of every attribute that can or must exist in an Active Directory object.
Schema containers
The Active Directory Schema snap-in includes two containers: the Classes container and the Attributes container. These containers store the class and attribute definitions. These definitions take the form of classSchema objects, which you can view in the Classes container, and attributeSchema objects, which you can view in the Attributes container.
Schema changes
Making changes to the AD DS schema is advisable only rarely. Errors in schema changes can result in data loss and corruption. For this reason, before you attempt any manipulation of schema objects, be sure that you understand the effects of the change and that you have deployed the change and observed its effects in a test forest.
Before making any schema changes, read the Active Directory Schema Technical Reference (http://go.microsoft.com/fwlink/?LinkID=65961). For information about how to make schema changes, see Active Directory Schema (http://go.microsoft.com/fwlink/?LinkId=80809).
Overview of the Active Directory Schema Snap-in
Installing, Securing, and Viewing the Schema
Troubleshooting Active Directory Schema
Resources for Active Directory Schema
User Interface: Active Directory Schema
Planning Operations Master Role Placement
Updated: June 11, 2010
Applies To: Windows Server 2008, Windows Server 2008 R2
Active Directory Domain Services (AD DS) supports multimaster replication of directory data, which means any domain controller can accept directory changes and replicate the changes to all other domain controllers. However, certain changes, such as schema modifications, are impractical to perform in a multimaster fashion. For this reason certain domain controllers, known as operations masters, hold roles responsible for accepting requests for certain specific changes.
Note
Operations master role holders must be able to write some information to the Active Directory database. Because of the read-only nature of the Active Directory database on a read-only domain controller (RODC), RODCs cannot act as operations master role holders.
Three operations master roles (also known as flexible single master operations or FSMO) exist in each domain:
The primary domain controller (PDC) emulator operations master processes all password
updates.
The relative ID (RID) operations master maintains the global RID pool for the domain and
allocates local RIDs pools to all domain controllers to ensure that all security principals created
in the domain have a unique identifier.
The infrastructure operations master for a given domain maintains a list of the security
principals from other domains that are members of groups within its domain.
In addition to the three domain-level operations master roles, two operations master roles exist in each forest:
The schema operations master governs changes to the schema.
The domain naming operations master adds and removes domains and other directory
partitions (for example, Domain Name System (DNS) application partitions) to and from the
forest.
Place the domain controllers hosting these operations master roles in areas where network reliability is high, and ensure that the PDC emulator and the RID master are consistently available.
Operations master role holders are assigned automatically when the first domain controller in a given domain is created. The two forest-level roles (schema master and domain naming master) are assigned to the first domain controller created in a forest. In addition, the three domain-level roles (RID master, infrastructure master, and PDC emulator) are assigned to the first domain controller created in a domain.
Note
Automatic operations master role holder assignments are made only when a new domain is created and when a current role holder is demoted. All other changes to role owners have to be initiated by an administrator.
These automatic operations master role assignments can cause very high CPU usage on the first domain controller created in the forest or the domain. To avoid this, assign (transfer) operations master roles to various domain controllers in your forest or domain. Place the domain controllers that host operations master roles in areas where the network is reliable and where the operations masters can be accessed by all other domain controllers in the forest.
You should also designate standby (alternate) operations masters for all operations master roles. The standby operations masters are domain controllers to which you could transfer the operations master roles in case the original role holders fail. Ensure that the standby operations masters are direct replication partners of the actual operations masters.
Planning the PDC emulator placement
The PDC emulator processes client password changes. Only one domain controller acts as the PDC emulator in each domain in the forest.
Even if all the domain controllers are upgraded to Windows 2000, Windows Server 2003, and Windows Server 2008, and the domain is operating at the Windows 2000 native functional level, the PDC emulator receives preferential replication of password changes performed by other domain controllers in the domain. If a password was recently changed, that change takes time to replicate to every domain controller in the domain. If logon authentication fails at another domain controller due to a bad password, that domain controller forwards the authentication request to the PDC emulator before deciding whether to accept or reject the logon attempt.
Place the PDC emulator in a location that contains a large number of users from that domain for password forwarding operations if needed. In addition, ensure that the location is well connected to other locations to minimize replication latency.
For a worksheet to assist you in documenting the information about where you plan to place PDC emulators and the number of users for each domain that is represented in each location, see Job Aids for Windows Server 2003 Deployment Kit (http://go.microsoft.com/fwlink/?LinkID=102558), download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open Domain Controller Placement (DSSTOPO_4.doc).
You need to refer to the information about locations in which you need to place PDC emulators when you deploy regional domains. For more information about deploying regional domains, see Deploying Windows Server 2008 Regional Domains.
Requirements for infrastructure master placement
The infrastructure master updates the names of security principals from other domains that are added to groups in its own domain. For example, if a user from one domain is a member of a group in a second domain and the user’s name is changed in the first domain, the second domain is not notified that the user’s name must be updated in the group’s membership list. Because domain controllers in one domain do not replicate security principals to domain controllers in another domain, the second domain never becomes aware of the change in the absence of the infrastructure master.
The infrastructure master constantly monitors group memberships, looking for security principals from other domains. If it finds one, it checks with the security principal’s domain to verify that the information is updated. If the information is out of date, the infrastructure master performs the update and then replicates the change to the other domain controllers in its domain.
Two exceptions apply to this rule. First, if all domain controllers are global catalog servers, the domain controller that hosts the infrastructure master role is insignificant because global catalogs replicate the updated information regardless of the domain to which they belong. Second, if the forest has only one domain, the domain controller that hosts the infrastructure master role is insignificant because security principals from other domains do not exist.
Do not place the infrastructure master on a domain controller that is also a global catalog server. 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; therefore, it will never replicate any changes to the other domain controllers in the domain.
Operations master placement for networks with limited connectivity
Be aware that if your environment does have a central location or hub site in which you can place operations master role holders, certain domain controller operations that depend on the availability of those operations master role holders might be affected.
For example, suppose that an organization creates sites A, B, C, and D. Site links exist between A and B, between B and C, and between C and D. Network connectivity exactly mirrors the network connectivity of the sites links. In this example, all operations master roles are placed in site A and the option to Bridge all site links is not selected.
Although this configuration results in successful replication between all of the sites, the operations master role functions have the following limitations:
Domain controllers in sites C and D cannot access the PDC emulator in site A to update a
password or to check it for a password that has been recently updated.
Domain controllers in sites C and D cannot access the RID master in site A to obtain an initial
RID pool after the Active Directory installation and to refresh RID pools as they become
depleted.
Domain controllers in sites C and D cannot add or remove directory, DNS, or custom application
partitions.
Domain controllers in sites C and D cannot make schema changes.
For a worksheet to assist you in planning operations master role placement, see Job Aids for Windows Server 2003 Deployment Kit (http://go.microsoft.com/fwlink/?LinkID=102558), download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open Domain Controller Placement (DSSTOPO_4.doc).
You will need to refer to this information when you create the forest root domain and regional domains. For more information about deploying the forest root domain, see Deploying a Deploying a Windows Server 2008 Forest Root Domain. For more information about deploying regional domains, see Deploying Windows Server 2008 Regional Domains.
Configuring additional Active Directory server roles