Configuring The Active Directory Infrastructure

Configuring the Active Directory infrastructure
Configure a forest or a domain
Requirements for Installing AD DS

Updated: 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 StepBy-Step Guide (http://go.microsoft.com/fwlink/?LinkId=87786).
y y
Install Windows Server 2008 or Windows Server 2008 R2. Verify that a Domain Name System (DNS) infrastructure is in place. Before y ou 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 D NS 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 avail able. 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.
y y
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 durin g 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 DS

Updated: 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 metho ds 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:
y y y y y y y
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 Guide

Updated: 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
y y y y y y y y y y y
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, inc luding its original publication on Microsoft TechNet.
Date April 2006 January 2009
Revision Original publication on Technet
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 DS

Updated: 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:
y y y y
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 Parameters

Updated: 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 DS

Updated: 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.
y y y y y y
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).
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.
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 o peration 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:
y y y y
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 Features

Updated: 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 Windows 2000 native
Enabled features All default Active Directory features and the following features: Universal groups are enabled for both distribution groups and security groups.
Supported domain controller operating systems Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 Windows 2000
y y
Group nesting.
Group conversion is enabled, which makes conversion between security groups and distribution groups possible.
Security identifier (SID) history.
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.
Windows Server 2008 R2 Windows Server 2008 Windows Server 2003
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 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:
Windows Server 2008 R2 Windows Server 2008
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 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 users Kerberos token. When this feature is enabled in a network environment that has deployed a federated identity management infrastructure, such as Active Directory Federation Services (AD FS), the information in the token can then be extracted whenever a user attempts to access any claims-aware application that has been developed to determine authorization based on a users logon, 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 Windows 2000
Enabled features All default Active Directory features.
Supported domain controllers Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 Windows 2000 Windows
Windows
All default Active Directory features, and the following
Server 2003
features: Forest trust.
y y y
Server 2008 R2 Windows Server 2008 Windows Server 2003
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.
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 R2 Windows Server 2008
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.
Configure trusts
Managing Trusts
You can use Active Directory Domains and Trusts to manage domain trusts.
Understanding Trusts
y y y y y
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.
y y
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.
y y
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.
y y y
Trusted domain objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time that a trust is establ ished, 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).
y y
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 External
Transitivity Nontransitive
Direction One-way or two-way
Description 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:
y y y y y
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-ofSupport Solution Center (http://go.microsoft.com/fwlink/?LinkId=184536)
y y
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).
y y
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:
y y
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
y y
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 requestsbut 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

y y
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
y y
Using the Windows interface Using a command line
To create a shortcut trust using the Windows interface 1. 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. 4. On the Trusts tab, click New Trust, and then click Next. 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
y y
To create an external trust using the Windows interface 1. 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. 4. On the Trusts tab, click the New Trust, and then click Next. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the domain, and then click Next.
5. 6.
On the Trust Type page, click External trust, and then click Next. 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 line 1. 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 netdom trust
Description 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
y y
To create a realm trust using the Windows interface 1. 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. 4. 5. 6. On the Trusts tab, click New trust, and then click Next. On the Trust Name page, type the realm name for the target realm, and then click Next. On the Trust Type page, select the Realm trust option, and then click Next. 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 line 1. 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>
Description Manages or verifies trust relationships between domains.
Specifies the Domain Name System (DNS) name of the trusting domain in the new realm trust.
/d:
<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.
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
y y
To verify a trust using the Windows interface 1. 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. 5. Click Validate. 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 line 1. 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
Description Managers or verifies the trust relationship between domains.
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.
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
y y
To remove a trust using the Windows interface 1. 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 line 1. 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>
Description Manages or verifies trust relationships between domains.
Specifies the Domain Name System (DNS) name of the trusting domain in the trust that is being removed.
/d:
<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.
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 interface 1. 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 Services

Updated: 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:
y y y
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
y y y y y y y
Sites Site objects are located in the Sites container. You can use site objects to accomplish the following tasks:
y y
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. Subnets Subnet objects identify the ranges of IP addresses within a site. You can use subnet objects to accomplish the following tasks:
y y y
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. Servers Server 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 Settings Every 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. Connections Replication 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 o bject. 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 links Site 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:
y y
y y
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 transports Replication 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 thi s 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 rea son, 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
y y y
Adding a Site to the Forest Scheduling Replication Between Sites Adding the Global Catalog to a Site
Checklist: Configure an Additional Site

Updated: June 18, 2007 Applies To: Windows Server 2008 The tasks for configuring a new site include the following:
y y y
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 (Optional) Review sites and replication concepts.
Reference Understanding Sites, Subnets, and Site Links Create a Site
Create a new site object to represent the domain controllers in a geographic location. Identify the range of IP addresses that domain controllers in this site useand that identify the domain controllers as members of this site by creating a subnet object and associating it with the new site. 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. Change the site link association of the new site from its existin g site link to the new site link so that replication will begin with the new site link.
Create a Subnet
Create a Site Link
Add a Site to or Remove a Site from a Site Link
Changing Site Link Properties

Updated: 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 incre ases 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. 2. Configure the Site Link Schedule to Identify Times During Which Intersite Replication Can Occur Configure the Site Link Interval to Identify How Often Replication Polling Can Occur During the Schedule Window 3. 4. Configure the Site Link Cost to Establish a Priority for Replication Routing To generate the intersite topology, perform the following procedures: a. b. Determine the ISTG Role Owner for a Site Generate the Replication Topology on the ISTG
Creating a Site Link Bridge Design

Updated: 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 enable d 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 failover If 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 firewall If 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. There fore, 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 Replication

Updated: 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 bridging By 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 bridging If 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 site By 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 i s 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 rediscovery In 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 s econds. 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 users 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 users domain and the identity of the users 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 Replication

This section includes the following tasks for managing intersite replication:
Adding a New Site

Applies 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 f irst 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:
To complete this task, perform the following procedures: 1. 2. Create a Site Object and Add it to an Existing Site Link 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
y y
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 si te 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:
To complete this task, perform the following procedures: 1. 2. Create a Site Link Object and Add the Appropriate Sites 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
y y
3.
If you are designating servers that will perform intersite replication, you can Designate a Server as a Preferred Bridgehead Server.
Changing Site Link Properties

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:
To complete this task, perform the following procedures: 1. 2. Configure the Site Link Schedule to Identify Times During Which Intersite Replication Can Occur Configure the Site Link Interval to Identify How Often Replication Polling Can Occur During the Schedule Window 3. 4. Configure the Site Link Cost to Establish a Priority for Replication Routing To generate the intersite topology, perform the following procedures:
a. b.
Determine the ISTG Role Owner for a Site Generate the Replication Topology on the ISTG
Enabling Clients to Locate the Next Closest Domain Controller

If 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:
y y
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:
y y
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 cl oser if it has a lower site -link cost than another site with a higher sitelink 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 Site

When 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:
y y y
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 i s 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 o ccur. 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:
y y y
Network Connections DNS snap-in Active Directory Sites and Services
To complete this task, perform the following procedures in order: 1. 2. Change the Static IP Address of a Domain Controller 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. 5. Verify That an IP Address Maps to a Subnet and Determine the Site Association 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
y y
6. 7.
Configure a Server to Not Be a Preferred Bridgehead Server 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 users 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:
To complete this task, perform the following procedure:
Forcing Replication
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 th e 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 controllers 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 th e 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
y y
To complete this task, perform the following procedures: 1. 2. 3. 4. Force Replication Between Domain Controllers Update a Server with Configuration Changes Synchronize Replication with All Partners Verify Successful Replication to a Domain Controller
Removing a Site
If 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:
To complete this task, perform the following procedures: 1. 2. 3. 4. 5. 6. Delete a manual Connection object Determine Whether a Server Object Has Child Objects Delete a Server Object from a Site Delete a Site Link object Associate an Existing Subnet Object with a Site 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
y y
Introduction to Administering DFS-Replicated SYSVOL

Updated: January 9, 2009 Applies To: Windows Server 2008, Windows Server 2008 R2 SYSVOL is a collection of folders that contain a copy of the domains 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 lo cated 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 CPUintensive 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:
y y
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 c ause 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:
y y y y y y y y y
%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.
y y
%systemroot%\SYSVOL\sysvol %systemroot%\SYSVOL\sysvol\<FQDN>, where FQDN is the fully qualified domain n ame 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 msDFSR-RootPath msDFSR-StagingPath
Default referenced location %systemroot\SYSVOL\domain %systemroot\SYSVOL\staging\domain
Contents Policies and scripts Staging area folders
SYSVOL Replication Migration Guide: FRS to DFS Replication

Published: 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
y y
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
y y y
Troubleshooting SYSVOL Migration
y y
Troubleshooting SYSVOL Migration Issues Rolling Back SYSVOL Migration to a Previous Stable State
SYSVOL Migration Reference Information
y y y y
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 1Introduction to the SYSVOL migration process SYSVOL Migration Series: Part 2Dfsrmig.exe: The SYSVOL migration tool SYSVOL Migration Series: Part 3Migrating to the 'PREPARED' state SYSVOL Migration Series: Part 4Migrating to the REDIRECTED state SYSVOL Migration Series: Part 5Migrating to the ELIMINATED state Step-by-Step Guide for Distributed File Systems in Windows Server 2008 FRS Technical Reference
Forcing Replication
Updated: 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 repli cation 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 do main 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 controllers 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. 2. 3. 4. Force Replication Between Domain Controllers Update a Server with Configuration Changes Synchronize Replication with All Partners Verify Successful Replication to a Domain Controller
Configure the global catalog
Enabling Universal Group Membership Caching in a Site

Updated: 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 users 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:
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 users account is located in sales1.cohovineyard.com and the user logs on with a UPN of luis@sales1.cohovineyard.com from a computer that is located in sales2.cohovineyard.com, the domain controller in sales2.cohovineyard.com cannot find the users 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
y y
Adding the Global Catalog to a Site Add or Remove the Global Catalog
Introduction to Administering the Global Catalog

Updated: 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 doma in 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:
y y
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:
y y y
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 Server

Updated: 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 directo ry searches.
Task (Optional) Review global catalog concepts.
Reference Understanding the Global Catalog Add or Remove the Global Catalog Verify Global Catalog Readiness Verify Global Catalog DNS Registrations
Add or remove the global catalog read-only directory partitions from a domain controller in the site. Confirm that all read-only directory partitions have been replicated to the new global catalog server. Verify that the global catalog server is being advertised in Domain Name System (DNS).
Configuring a Global Catalog Server

Updated: 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, readonly, 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:
y y y
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 server 1. 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. 4. Right-click the NTDS Settings object, and then click Properties. 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 server 1. 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. 5.
Right-click the NTDS Settings object for the target server, and then click Properties. 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, readonly, 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 progress 1. 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 s:<servername>
Description 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:
y y
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 controller 1. 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 repadmin /showrepl
Description 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 partners 1. 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. 4. 5. Open Excel. Click the Office button, click Open, navigate to showrepl.csv, and then click Open. 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.
y
7.
Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top Row.
8. 9.
Select the entire spreadsheet. On the Data tab, click Filter. In the Last Success Time column, click the down arrow, and then cli ck 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):
y y y
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 Service

Updated: 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 Technica l 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:
y y
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.
y y
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 Roles

Updated: 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 Directoryenabled 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:
y y
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.
y y y y
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 controllers 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 controllers 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 users 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 do main 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 previ ous 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:
y y y y
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 Directoryenabled 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 o f 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 Role

Updated: 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:
y y y y y
Repadmin.exe Active Directory Sites and Services Active Directory Domains and Trusts Active Directory Schema snap-in Active Directory Users and Computers
Ntdsutil.exe
y y y y y y y
Verify Successful Replication to a Domain Controller Determine Whether a Domain Controller Is a Globa l 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 role

Updated: 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 th e 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 onlinefor 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:
y y
Repadmin.exe Ntdsutil.exe
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
y y
Designating a Standby Operations Master

Updated: 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 co ntroller 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 transacti ons. 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
y y y
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 Schema

Updated: 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).
y y y y y
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 mai ntains 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:
y y
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 users name is changed in the first domain, the second domain is not notified that the users name must be updated in the groups 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 principals domain to verify that the information is updated. If the information is out of date, the infrastr ucture 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 insignif icant 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 obtai n 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

Configuring The Active Directory Infrastructure

Uploaded by

Copyright:

Available Formats

Configuring The Active Directory Infrastructure

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuring The Active Directory Infrastructure

Uploaded by

Copyright:

Available Formats

Configuring the Active Directory infrastructure

Configure a forest or a domain

Requirements for Installing AD DS

Steps for Installing AD DS

AD DS Installation and Removal Step-by-Step Guide

Publication and revision history

Date April 2006 January 2009

Revision Original publication on Technet

Steps for Removing AD DS

Appendix of Unattended Installation Parameters

dcpromo /unattend /username:Jsmith /password:* /sitename:NorthRegion ...

Scenarios for Installing AD DS

Install a new forest

Install a new domain in an existing forest

Install a new domain controller in an existing domain

Perform a staged RODC installation

Install AD DS from media

Appendix of Functional Level Features

Features that are enabled at domain functional levels

Domain functional level Windows 2000 native

Security identifier (SID) history.

Windows Server 2003

Windows Server 2008 R2 Windows Server 2008 Windows Server 2003

attribute is replicated within the domain.

Windows Server 2008

Windows Server 2008 R2 Windows Server 2008

Windows Server 2008 R2

Windows Server 2008 R2

Features that are enabled at forest functional levels

Forest functional level Windows 2000

Enabled features All default Active Directory features.

All default Active Directory features, and the following

features: Forest trust.

Server 2008 R2 Windows Server 2008 Windows Server 2003

Deactivation and redefinition of attributes and classes in the schema.

Windows Server 2008

Windows Server 2008 R2 Windows Server 2008

Windows Server 2008 R2

Windows Server 2008 R2

Trusted domain objects

Understanding Trust Types

Trust type External

Direction One-way or two-way

Understanding When to Create a Realm Trust.

Understanding Trust Direction

Understanding Trust Transitivity

Understanding When to Create an External Trust

When to create an external trust

Understanding When to Create a Shortcut Trust

Using one-way trusts

Using two-way trusts

Understanding When to Create a Realm Trust

Create a Shortcut Trust

Creating a shortcut trust

Using the Windows interface Using a command line

Create an External Trust

Creating an external trust

Using the Windows interface Using a command line

Continue to follow the instructions in the wizard.