1.Designing the Site Topology
Designing the Site Topology
A directory service site topology is a logical representation of your physical network. Designing a site topology for Active Directory Domain Services (AD DS) involves planning for domain controller placement and designing sites, subnets, site links, and site link bridges to ensure efficient routing of query and replication traffic.
Designing a site topology helps you efficiently route client queries and Active Directory replication traffic. A well-designed site topology helps your organization achieve the following benefits:
- Minimize the cost of replicating Active Directory data.
- Minimize administrative efforts that are required to maintain the site topology.
- Schedule replication that enables locations with slow or dial-up network links to replicate Active Directory data during off-peak hours.
- Optimize the ability of client computers to locate the nearest resources, such as domain controllers and Distributed File System (DFS) servers. This helps to reduce network traffic over slow wide area network (WAN) links, improve logon and logoff processes, and speed up file download operations.
Before you begin to design your site topology, you must understand your physical network structure. In addition, you must first design your Active Directory logical structure, including the administrative hierarchy, forest plan, and domain plan for each forest. You must also complete your Domain Name System (DNS) infrastructure design for AD DS.
2.Understanding Active Directory Site Topology
Understanding Active Directory Site Topology
Your site topology significantly affects the performance of your network and the ability of your users to access network resources. Before you begin to design your site topology, become familiar with the functions for sites in Windows Server 2008 , the different network topologies that organizations commonly use, the role of the site topology owner, and some Active Directory replication concepts.
Site Functions Topology
Routing replication Topology
Active Directory Domain Services (AD DS) uses a multimaster, store-and-forward method of replication. A domain controller communicates directory changes to a second domain controller, which then communicates to a third, and so on, until all domain controllers have received the change. To achieve the best balance between reducing replication latency and reducing traffic, site topology controls Active Directory replication by distinguishing between replication that occurs within a site and replication that occurs between sites.
Within sites, replication is optimized for speeddata updates trigger replication, and the data is sent without the overhead required by data compression. Conversely, replication between sites is compressed to minimize the cost of transmission over wide area network (WAN) links. When replication occurs between sites, a single domain controller per domain at each site collects and stores the directory changes and communicates them at a scheduled time to a domain controller in another site.
Domain controllers use site information to inform Active Directory clients about domain controllers present within the closest site as the client. For example, consider a client in the Seattle site that does not know its site affiliation and contacts a domain controller from the Atlanta site. Based on the IP address of the client, the domain controller in Atlanta determines which site the client is actually from and sends the site information back to the client. The domain controller also informs the client whether the chosen domain controller is the closest one to it. The client caches the site information provided by the domain controller in Atlanta, queries for the site-specific service (SRV) resource record (a Domain Name System (DNS) resource record used to locate domain controllers for AD DS) and thereby finds a domain controller within the same site.
By finding a domain controller in the same site, the client avoids communications over WAN links. If no domain controllers are located at the client site, a domain controller that has the lowest cost connections relative to other connected sites advertises itself (registers a site-specific service (SRV) resource record in DNS) in the site that does not have a domain controller. The domain controllers that are published in DNS are those from the closest site as defined by the site topology. This process ensures that every site has a preferred domain controller for authentication.
SYSVOL is a collection of folders in the file system that exists on each domain controller in a domain. The SYSVOL folders provide a default Active Directory location for files that must be replicated throughout a domain, including Group Policy objects (GPOs), startup and shutdown scripts, and logon and logoff scripts. Windows Server 2008 can use the File Replication Service (FRS) or Distributed File System Replication (DFSR) to replicate changes made to the SYSVOL folders from one domain controller to other domain controllers. FRS and DFSR replicate these changes according to the schedule that you create during your site topology design.
DFSN uses site information to direct a client to the server that is hosting the requested data within the site. If DFSN does not find a copy of the data within the same site as the client, DFSN uses the site information in AD DS to determine which file server that has DFSN shared data is closest to the client.
By publishing services such as file and print services in AD DS, you allow Active Directory clients to locate the requested service within the same or nearest site. Print services use the location attribute stored in AD DS to let users browse for printers by location without knowing their precise location. For more information about designing and deploying print servers, see Designing and Deploying Print Servers
Site Topology Owner Role
The administrator who manages the site topology is known as the site topology owner. The site topology owner understands the conditions of the network between sites and has the authority to change settings in Active Directory Domain Services (AD DS) to implement changes to the site topology. Changes to the site topology affect changes in the replication topology. The site topology owner’s responsibilities include:
- Controlling changes to the site topology if network connectivity changes.
- Obtaining and maintaining information about network connections and routers from the network group. The site topology owner must maintain a list of subnet addresses, subnet masks, and the location to which each belongs. The site topology owner must also understand any issues about network speed and capacity that affect site topology to effectively set costs for site links.
- Moving Active Directory server objects representing domain controllers between sites if a domain controller’s IP address changes to a different subnet in a different site, or if the subnet itself is assigned to a different site. In either case, the site topology owner must manually move the Active Directory server object of the domain controller to the new site.
3.Active Directory Replication Concepts
Active Directory Replication Concepts
Before designing site topology, become familiar with some Active Directory replication concepts.+
- Connection object
- Failover functionality
- Site link
- Site link bridge
- Site link transitivity
- Global catalog server
- Universal group membership caching
Active Directory Replication Connection object
A connection object is an Active Directory object that represents a replication connection from a source domain controller to a destination domain controller. A domain controller is a member of a single site and is represented in the site by a server object in Active Directory Domain Services (AD DS). Each server object has a child NTDS Settings object that represents the replicating domain controller in the site.
The connection object is a child of the NTDS Settings object on the destination server. For replication to occur between two domain controllers, the server object of one must have a connection object that represents inbound replication from the other. All replication connections for a domain controller are stored as connection objects under the NTDS Settings object. The connection object identifies the replication source server, contains a replication schedule, and specifies a replication transport.
The Knowledge Consistency Checker (KCC) creates connection objects automatically, but they can also be created manually. Connection objects created by the KCC appear in the Active Directory Sites and Services snap-in as and are considered adequate under normal operating conditions. Connection objects created by an administrator are manually created connection objects. A manually created connection object is identified by the name assigned by the administrator when it was created. When you modify an connection object, you convert it into an administratively modified connection object and the object appears in the form of a GUID. The KCC does not make changes to manual or modified connection objects.
The KCC is a built-in process that runs on all domain controllers and generates replication topology for the Active Directory forest. The KCC creates separate replication topologies depending on whether replication is occurring within a site (intrasite) or between sites (intersite). The KCC also dynamically adjusts the topology to accommodate the addition of new domain controllers, the removal of existing domain controllers, the movement of domain controllers to and from sites, changing costs and schedules, and domain controllers that are temporarily unavailable or in an error state.
Within a site, the connections between writable domain controllers are always arranged in a bidirectional ring, with additional shortcut connections to reduce latency in large sites. On the other hand, the intersite topology is a layering of spanning trees, which means one intersite connection exists between any two sites for each directory partition and generally does not contain shortcut connections. For more information about spanning trees and Active Directory replication topology.
On each domain controller, the KCC creates replication routes by creating one-way inbound connection objects that define connections from other domain controllers. For domain controllers in the same site, the KCC creates connection objects automatically without administrative intervention. When you have more than one site, you configure site links between sites, and a single KCC in each site automatically creates connections between sites as well.
KCC improvements for Windows Server 2008 RODCs
There are a number of KCC improvements to accommodate the newly available read-only domain controller (RODC) in Windows Server 2008 . A typical deployment scenario for RODC is the branch office. The Active Directory replication topology most commonly deployed in this scenario is based on a hub-and-spoke design, where branch domain controllers in multiple sites replicate with a small number of bridgehead servers in a hub site.
One of the benefits of deploying RODC in this scenario is unidirectional replication. Bridgehead servers are not required to replicate from the RODC, which reduces administration and network usage.
However, one administrative challenge highlighted by the hub-spoke topology on previous versions of the Windows Server operating system is that after adding a new bridgehead domain controller in the hub, there is no automatic mechanism to redistribute the replication connections between the branch domain controllers and the hub domain controllers to take advantage of the new hub domain controller.
Sites ensure that replication is routed around network failures and offline domain controllers. The KCC runs at specified intervals to adjust the replication topology for changes that occur in AD DS, such as when new domain controllers are added and new sites are created. The KCC reviews the replication status of existing connections to determine if any connections are not working. If a connection is not working due to a failed domain controller, the KCC automatically builds temporary connections to other replication partners (if available) to ensure that replication occurs. If all the domain controllers in a site are unavailable, the KCC automatically creates replication connections between domain controllers from another site.
A subnet is a segment of a TCP/IP network to which a set of logical IP addresses are assigned. Subnets group computers in a way that identifies their physical proximity on the network. Subnet objects in AD DS identify the network addresses that are used to map computers to sites.
Sites are Active Directory objects that represent one or more TCP/IP subnets with highly reliable and fast network connections. Site information allows administrators to configure Active Directory access and replication to optimize usage of the physical network. Site objects are associated with a set of subnets, and each domain controller in a forest is associated with an Active Directory site according to its IP address. Sites can host domain controllers from more than one domain, and a domain can be represented in more than one site.
Site links are Active Directory objects that represent logical paths that the KCC uses to establish a connection for Active Directory replication. A site link object represents a set of sites that can communicate at uniform cost through a specified intersite transport.
All sites contained within the site link are considered to be connected by means of the same network type. Sites must be manually linked to other sites by using site links so that domain controllers in one site can replicate directory changes from domain controllers in another site. Because site links do not correspond to the actual path taken by network packets on the physical network during replication, you do not need to create redundant site links to improve Active Directory replication efficiency.
When two sites are connected by a site link, the replication system automatically creates connections between specific domain controllers in each site that are called bridgehead servers. In Windows Server 2008 , all domain controllers in a site that host the same directory partition are candidates for being selected as bridgehead servers. The replication connections created by the KCC are randomly distributed among all candidate bridgehead servers in a site to share the replication workload. By default, the randomized selection process takes place only once, when connection objects are first added to the site.
Site link bridge
A site link bridge is an Active Directory object that represents a set of site links, all of whose sites can communicate by using a common transport. Site link bridges enable domain controllers that are not directly connected by means of a communication link to replicate with each other. Typically, a site link bridge corresponds to a router (or a set of routers) on an IP network.
By default, the KCC can form a transitive route through any and all site links that have some sites in common. If this behavior is disabled, each site link represents its own distinct and isolated network. Sets of site links that can be treated as a single route are expressed through a site link bridge. Each bridge represents an isolated communication environment for network traffic.
Site link bridges are a mechanism to logically represent transitive physical connectivity between sites. A site link bridge allows the KCC to use any combination of the included site links to determine the least expensive route to interconnect directory partitions held in those sites. The site link bridge does not provide actual connectivity to the domain controllers. If the site link bridge is removed, replication over the combined site links will continue until the KCC removes the links.
Site link bridges are only necessary if a site contains a domain controller hosting a directory partition that is not also hosted on a domain controller in an adjacent site, but a domain controller hosting that directory partition is located in one or more other sites in the forest. Adjacent sites are defined as any two or more sites included in a single site link.
A site link bridge creates a logical connection between two site links, providing a transitive path between two disconnected sites by using an interim site. For the purposes of the intersite topology generator (ISTG), the bridge implies physical connectivity by using the interim site. The bridge does not imply that a domain controller in the interim site will provide the replication path. However, this would be the case if the interim site contained a domain controller that hosted the directory partition to be replicated, in which case a site link bridge is not required.
The cost of each site link is added, creating a summed cost for the resulting path. The site link bridge would be used if the interim site does not contain a domain controller hosting the directory partition and a lower cost link does not exist. If the interim site contained a domain controller that hosts the directory partition, two disconnected sites would set up replication connections to the interim domain controller and not use the bridge.
Site link transitivity
By default all site links are transitive, or “bridged.” When site links are bridged and the schedules overlap, the KCC creates replication connections that determine domain controller replication partners between sites, where the sites are not directly connected by site links but are connected transitively through a set of common sites. This means that you can connect any site to any other site through a combination of site links.
In general, for a fully routed network, you do not need to create any site link bridges unless you want to control the flow of replication changes. If your network is not fully routed, site link bridges should be created to avoid impossible replication attempts. All site links for a specific transport implicitly belong to a single site link bridge for that transport. The default bridging for site links occurs automatically, and no Active Directory object represents that bridge. The Bridge all site links setting, found in the properties of both the IP and Simple Mail Transfer Protocol (SMTP) intersite transport containers, implements automatic site link bridging.
Global catalog server
A global catalog server is a domain controller that stores information about all objects in the forest, so that applications can search AD DS without referring to specific domain controllers that store the requested data. Like all domain controllers, a global catalog server stores full, writable replicas of the schema and configuration directory partitions and a full, writable replica of the domain directory partition for the domain that it is hosting. In addition, a global catalog server stores a partial, read-only replica of every other domain in the forest. Partial, read-only domain replicas contain every object in the domain but only a subset of the attributes (those attributes that are most commonly used for searching the object).
Universal group membership caching
Universal group membership caching allows the domain controller to cache universal group membership information for users. You can enable domain controllers that are running Windows Server 2008 to cache universal group memberships by using the Active Directory Sites and Services snap-in.
Enabling universal group membership caching eliminates the need for a global catalog server at every site in a domain, which minimizes network bandwidth usage because a domain controller does not need to replicate all of the objects located in the forest. It also reduces logon times because the authenticating domain controllers do not always need to access a global catalog to obtain universal group membership information.
4.Collecting Network Information
Collecting Network Information
The first step in designing an effective site topology in Active Directory Domain Services (AD DS) is to consult your organization’s networking group to collect information and communicate with them regularly about your physical network topology.
Creating a location map
Create a location map that represents the physical network infrastructure of your organization. On the location map, identify the geographic locations that contain groups of computers with internal connectivity of 10 megabits per second (Mbps) or higher (local area network (LAN) speed or better).
Listing communication links and available bandwidth
After creating a location map, document the type of communication link, its link speed, and the available bandwidth between each location. Obtain a wide area network (WAN) topology from your networking group. For a list of common WAN circuit types and their bandwidths, see “Determining the cost” section in Creating a Site Link Design. You will need this information to create site links later in the site topology design process.
Bandwidth refers to the amount of data that you can transmit across a communication channel in a given amount of time. Available bandwidth refers to the amount of bandwidth actually available for use by AD DS. You can obtain available bandwidth information from your networking group, or you can analyze traffic on each link by using a protocol analyzer such as Network Monitor, which is a component that ships with Windows Server 2008 . For information about installing Network Monitor, see Monitoring network traffic (https://go.microsoft.com/fwlink/?LinkId=107058).
Document each location and the other locations that are linked to it. In addition, record the type of communication link and its available bandwidth. For a worksheet to assist you in listing communication links and available bandwidth, see Job Aids for Windows Server 2003 Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558), download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open “Geographic Locations and Communication Links” (DSSTOPO_1.doc).
Listing IP subnets within each location
After you document the communication links and the available bandwidth between each location, record the IP subnets within each location. If you do not already know the subnet mask and IP address within each location, consult your networking group.
AD DS associates a workstation with a site by comparing the workstation’s IP address with the subnets that are associated with each site. As you add domain controllers to a domain, AD DS also examines their IP addresses and places them in the most appropriate site.
For a worksheet to assist you in listing the IP subnets within each location, see Job Aids for Windows Server 2003 Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558), download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open “Locations and Subnets” (DSSTOPO_2.doc).
Listing domains and number of users for each location
The number of users for each regional domain that is represented in a location is one of the factors that determine the placement of regional domain controllers and global catalog servers, which is the next step in the site topology design process. For example, plan to place a regional domain controller in a location that contains more than 100 regional domain users so they can still log on to the domain if the WAN link fails.
Record the locations, the domains that are represented in each location, and the number of users for each domain that is represented in each location. For a worksheet to assist you in listing the domains and the number of users that are represented in each location, see Job Aids for Windows Server 2003 Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558), download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open “Domains and Users in Each Location” (DSSTOPO_3.doc).
5.Planning Domain Controller Placement
Planning Domain Controller Placement
After you have gathered all of the network information that will be used to design your site topology, plan where you want to place domain controllers, including forest root domain controllers, regional domain controllers, operations master role holders, and global catalog servers.
In Windows Server 2008 , you can also take advantage of read-only domain controllers (RODCs). An RODC is a new type of domain controller that hosts read-only partitions of the Active Directory database. Except for account passwords, an RODC holds all the Active Directory objects and attributes that a writable domain controller holds. However, changes cannot be made to the database that is stored on the RODC. Changes must be made on a writable domain controller and then replicated back to the RODC.
An RODC is designed primarily to be deployed in remote or branch office environments, which typically have relatively few users, poor physical security, relatively poor network bandwidth to a hub site, and personnel with limited knowledge of information technology (IT). Deploying RODCs results in improved security and more efficient access to network resources.
Planning Forest Root Domain Controller Placement
Forest root domain controllers are needed to create trust paths for clients that need to access resources in domains other than their own. Place forest root domain controllers in hub locations and at locations that host datacenters. If users in a given location need to access resources from other domains in the same location, and the network availability between the datacenter and the user location is unreliable, you can either add a forest root domain controller in the location or create a shortcut trust between the two domains. It is more cost efficient to create a shortcut trust between the domains unless you have other reasons to place a forest root domain controller in that location.+
Shortcut trusts help to optimize authentication requests made from users located in either domain. For more information about shortcut trusts between domains, see Understanding When to Create a Shortcut Trust (https://go.microsoft.com/fwlink/?LinkId=107061).
Planning Regional Domain Controller Placement
To ensure cost efficiency, plan to place as few regional domain controllers as possible. First, review the “Geographic Locations and Communication Links” (DSSTOPO_1.doc) worksheet used in Collecting Network Information to determine whether a location is a hub.+
Plan to place regional domain controllers for each domain that is represented in each hub location. After you place regional domain controllers in all hub locations, evaluate the need for placing regional domain controllers at satellite locations. Eliminating unnecessary regional domain controllers from satellite locations reduces the support costs required to maintain a remote server infrastructure.
In addition, ensure the physical security of domain controllers in hub and satellite locations so that unauthorized personnel cannot access them. Do not place writable domain controllers in hub and satellite locations in which you cannot guarantee the physical security of the domain controller. A person who has physical access to a writable domain controller can attack the system by:
- Accessing physical disks by starting an alternate operating system on a domain controller.
- Removing (and possibly replacing) physical disks on a domain controller.
- Obtaining and manipulating a copy of a domain controller system state backup.
Add writable regional domain controllers only to locations in which you can guarantee their physical security.
In locations with inadequate physical security, deploying a read-only domain controller (RODC) is the recommended solution. Except for account passwords, an RODC holds all the Active Directory objects and attributes that a writable domain controller holds. However, changes cannot be made to the database that is stored on the RODC. Changes must be made on a writable domain controller and then replicated back to the RODC.
To authenticate client logons and access to local file servers, most organizations place regional domain controllers for all regional domains that are represented in a given location. However, you must consider many variables when evaluating whether a business location requires its clients to have local authentication or the clients can rely on authentication and query over a wide area network (WAN) link. The following illustration shows how to determine whether to place domain controllers at satellite locations.
Onsite technical expertise availability
Domain controllers need to be managed continuously for various reasons. Place a regional domain controller only in locations that include personnel who can administer the domain controller, or be sure that the domain controller can be managed remotely.
In branch office environments with typically poor physical security and personnel with little information technology knowledge, deploying an RODC is often the recommended solution. Local administrative permissions for an RODC can be delegated to any domain user without granting that user any user rights for the domain or other domain controllers. This permits a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver. However, the branch user cannot log on to any other domain controller or perform any other administrative task in the domain. In this way, the branch user can be delegated the ability to effectively manage the RODC in the branch office without compromising the security of the rest of the domain or the forest.
WAN link availability
WAN links that experience frequent outages can cause significant productivity loss to users if the location does not include a domain controller that can authenticate the users. If your WAN link availability is not 100 percent and your remote sites cannot tolerate a service outage, place a regional domain controller in locations where the users require the ability to log on or exchange server access when the WAN link is down.
Certain organizations, such as banks, require that users be authenticated at all times. Place a regional domain controller in a location where the WAN link availability is not 100 percent but users require authentication at all times.
Logon performance over WAN links
If your WAN link availability is highly reliable, placing a domain controller at the location depends on the logon performance requirements over the WAN link. Factors that influence logon performance over the WAN include link speed and available bandwidth, number of users and usage profiles, and the amount of logon network traffic versus replication traffic.
WAN link speed and bandwidth utilization
The activities of a single user can congest a slow WAN link. Place a domain controller at a location if logon performance over the WAN link is unacceptable.
The average percentage of bandwidth utilization indicates how congested a network link is. If a network link has average bandwidth utilization that is greater than an acceptable value, place a domain controller at that location.
Number of users and usage profiles
The number of users and their usage profiles at a given location can help determine whether you need to place regional domain controllers at that location. To avoid productivity loss if a WAN link fails, place a regional domain controller at a location that has 100 or more users.
The usage profiles indicate how the users use the network resources. You do not need to place a domain controller in a location that contains only a few users who do not frequently access network resources.
Logon network traffic vs. replication traffic
If a domain controller is not available within the same location as the Active Directory client, the client creates logon traffic on the network. The amount of logon network traffic that is created on the physical network is influenced by several factors, including group memberships; number and size of Group Policy objects (GPOs); logon scripts; and features such as offline folders, folder redirection, and roaming profiles.
On the other hand, a domain controller that is placed at a given location generates replication traffic on the network. The frequency and amount of updates made on the partitions hosted on the domain controllers influence the amount of replication traffic that is created on the network. The different types of updates that can be made on the partitions hosted on the domain controllers include adding or changing users and user attributes, changing passwords, and adding or changing global groups, printers, or volumes.
To determine if you need to place a regional domain controller at a location, compare the cost of logon traffic created by a location without a domain controller versus the cost of replication traffic created by placing a domain controller at the location.
For example, consider a network that has branch offices that are connected through slow links to the headquarters and in which domain controllers can easily be added. If the daily logon and directory lookup traffic of a few remote site users causes more network traffic than replicating all company data to the branch, consider adding a domain controller to the branch.
If reducing the cost of maintaining domain controllers is more important than network traffic, either centralize the domain controllers for that domain and do not place any regional domain controllers at the location or consider placing RODCs at the location.
For a worksheet to assist you in documenting the placement of regional domain controllers and the number of users for each domain that is represented in each location, see Job Aids for Windows Server 2003 Deployment Kit (https://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).
Planning Global Catalog Server Placement
Global catalog placement requires planning except if you have a single-domain forest. In a single-domain forest, configure all domain controllers as global catalog servers. Because every domain controller stores the only domain directory partition in the forest, configuring each domain controller as a global catalog server does not require any additional disk space usage, CPU usage, or replication traffic. In a single-domain forest, all domain controllers act as virtual global catalog servers; that is, they can all respond to any authentication or service request. This special condition for single-domain forests is by design. Authentication requests do not require contacting a global catalog server as they do when there are multiple domains, and a user can be a member of a universal group that exists in a different domain. However, only domain controllers that are designated as global catalog servers can respond to global catalog queries on the global catalog port 3268. To simplify administration in this scenario and to ensure consistent responses, designating all domain controllers as global catalog servers eliminates the concern about which domain controllers can respond to global catalog queries. Specifically, any time a user uses Start\Search\For People or Find Printers or expands Universal Groups, these requests go only to the global catalog.
In multiple-domain forests, global catalog servers facilitate user logon requests and forest-wide searches. The following illustration shows how to determine which locations require global catalog servers.
In most cases, it is recommended 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.
- Infrastructure operations master role incompatibility: Do not place the global catalog on a domain controller that hosts the infrastructure operations master role in the domain unless all domain controllers in the domain are global catalog servers or the forest has only one domain.
Adding global catalog servers based on application requirements
Certain applications, such as Microsoft Exchange, Message Queuing (also known as MSMQ), and applications using DCOM do not deliver adequate response over latent WAN links and therefore need a highly available global catalog infrastructure to provide low query latency. Determine whether any applications that perform poorly over a slow WAN link are running in locations or whether the locations require Microsoft Exchange Server. If your locations include applications that do not deliver adequate response over a WAN link, you must place a global catalog server at the location to reduce query latency.
Read-only domain controllers (RODCs) can be promoted successfully to global catalog server status. However, certain directory-enabled applications cannot support an RODC as a global catalog server. For example, no version of Microsoft Exchange Server uses RODCs. However, Microsoft Exchange Server works in environments that include RODCs, as long as there are writable domain controllers available. Exchange Server 2007 effectively ignores RODCs. Exchange Server 2003 also ignores RODCs in default conditions where Exchange components automatically detect available domain controllers. No changes were made to Exchange Server 2003 to make it aware of read-only directory servers. Therefore, trying to force Exchange Server 2003 services and management tools to use RODCs may result in unpredictable behavior.
Adding global catalog servers for a large number of users
Place global catalog servers at all locations that contain more than 100 users to reduce congestion of network WAN links and to prevent productivity loss in case of WAN link failure.
Using highly available bandwidth
You do not need to place a global catalog at a location that does not include applications that require a global catalog server, includes less than 100 users, and is also connected to another location that includes a global catalog server by a WAN link that is 100 percent available for Active Directory Domain Services (AD DS). In this case, the users can access the global catalog server over the WAN link.
Roaming users need to contact the global catalog servers whenever they log on for the first time at any location. If the logon time over the WAN link is unacceptable, place a global catalog at a location that is visited by a large number of roaming users.
Enabling universal group membership caching
For locations that include less than 100 users and that do not include a large number of roaming users or applications that require a global catalog server, you can deploy domain controllers that are running Windows Server 2008 and enable universal group membership caching. Ensure that the global catalog servers are not more than one replication hop from the domain controller on which universal group membership caching is enabled so that universal group information in the cache can be refreshed. For information about how universal group caching works, see How the Global Catalog Works (https://go.microsoft.com/fwlink/?LinkId=107063).
For a worksheet to assist you in documenting where you plan to place global catalog servers and domain controllers with universal group caching enabled, see Job Aids for Windows Server 2003 Deployment Kit (https://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). See the information about locations in which you need to place global catalog servers when you deploy the forest root domain and regional domains.
Planning Operations Master Role Placement
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.+
Operations master role holders must be able to write some information to the Active Directory database. Because of the read-only nature of the Active Directory database on a read-only domain controller (RODC), RODCs cannot act as operations master role holders.
Three operations master roles (also known as flexible single master operations or FSMO) exist in each domain:
- The primary domain controller (PDC) emulator operations master processes all password updates.
- The relative ID (RID) operations master maintains the global RID pool for the domain and allocates local RIDs pools to all domain controllers to ensure that all security principals created in the domain have a unique identifier.
- The infrastructure operations master for a given domain maintains a list of the security principals from other domains that are members of groups within its domain.
In addition to the three domain-level operations master roles, two operations master roles exist in each forest:
- The schema operations master governs changes to the schema.
- The domain naming operations master adds and removes domains and other directory partitions (for example, Domain Name System (DNS) application partitions) to and from the forest.
Place the domain controllers hosting these operations master roles in areas where network reliability is high, and ensure that the PDC emulator and the RID master are consistently available.
Operations master role holders are assigned automatically when the first domain controller in a given domain is created. The two forest-level roles (schema master and domain naming master) are assigned to the first domain controller created in a forest. In addition, the three domain-level roles (RID master, infrastructure master, and PDC emulator) are assigned to the first domain controller created in a domain.
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 (https://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).
Requirements for infrastructure master placement
The infrastructure master updates the names of security principals from other domains that are added to groups in its own domain. For example, if a user from one domain is a member of a group in a second domain and the user’s name is changed in the first domain, the second domain is not notified that the user’s name must be updated in the group’s membership list. Because domain controllers in one domain do not replicate security principals to domain controllers in another domain, the second domain never becomes aware of the change in the absence of the infrastructure master.
The infrastructure master constantly monitors group memberships, looking for security principals from other domains. If it finds one, it checks with the security principal’s domain to verify that the information is updated. If the information is out of date, the infrastructure master performs the update and then replicates the change to the other domain controllers in its domain.
Two exceptions apply to this rule. First, if all domain controllers are global catalog servers, the domain controller that hosts the infrastructure master role is insignificant because global catalogs replicate the updated information regardless of the domain to which they belong. Second, if the forest has only one domain, the domain controller that hosts the infrastructure master role is insignificant because security principals from other domains do not exist.
Do not place the infrastructure master on a domain controller that is also a global catalog server. If the infrastructure master and global catalog are on the same domain controller, the infrastructure master will not function. The infrastructure master will never find data that is out of date; therefore, it will never replicate any changes to the other domain controllers in the domain.
Operations master placement for networks with limited connectivity
Be aware that if your environment does have a central location or hub site in which you can place operations master role holders, certain domain controller operations that depend on the availability of those operations master role holders might be affected.
For example, suppose that an organization creates sites A, B, C, and D. Site links exist between A and B, between B and C, and between C and D. Network connectivity exactly mirrors the network connectivity of the sites links. In this example, all operations master roles are placed in site A and the option to Bridge all site links is not selected.
Although this configuration results in successful replication between all of the sites, the operations master role functions have the following limitations:
- Domain controllers in sites C and D cannot access the PDC emulator in site A to update a password or to check it for a password that has been recently updated.
- Domain controllers in sites C and D cannot access the RID master in site A to obtain an initial RID pool after the Active Directory installation and to refresh RID pools as they become depleted.
- Domain controllers in sites C and D cannot add or remove directory, DNS, or custom application partitions.
- Domain controllers in sites C and D cannot make schema changes.
6.Creating a Site Design
Creating a Site Design
2016, Windows Server 2012 R2, Windows Server 2012
Creating a site design involves deciding which locations will become sites, creating site objects, creating subnet objects, and associating the subnets with sites.
Deciding which locations will become sites
Decide which locations to create sites for as follows:
- Create sites for all locations in which you plan to place domain controllers. Refer to the information documented in the “Domain Controller Placement” (DSSTOPO_4.doc) worksheet to identify locations that include domain controllers.
- Create sites for those locations that include servers that are running applications that require a site to be created. Certain applications, such as Distributed File System Namespaces (DFSN), use site objects to locate the closest servers to clients.
If your organization has multiple networks in close proximity with fast, reliable connections, you can include all of the subnets for those networks in a single Active Directory site. For example, if the round-trip return network latency between two servers in different subnets is 10 ms or less, you can include both subnets in the same Active Directory site. If the network latency between the two locations is greater than 10 ms, you should not include the subnets in a single Active Directory site. Even when latency is 10 ms or less, you may elect to deploy separate sites if you want to segment the traffic between sites for Active Directory-based applications.
- If a site is not required for a location, add the subnet of the location to a site for which the location has the maximum wide area network (WAN) speed and available bandwidth.
Document locations that will become sites and the network addresses and subnet masks within each location.
Creating a site object design
For every location where you have decided to create sites, plan to create site objects in Active Directory Domain Services (AD DS). Document locations that will become sites in the “Associating Subnets with Sites” worksheet.
Creating a subnet object design
For every IP subnet and subnet mask associated with each location, plan to create subnet objects in AD DS representing all the IP addresses within the site.
When creating an Active Directory subnet object, the information about network IP subnet and subnet mask is automatically translated into the network prefix length notation format /. For example, the network IP version 4 (IPv4) address 172.16.4.0 with a subnet mask 255.255.252.0 appears as 172.16.4.0/22. In addition to IPv4 addresses, Windows Server 2008 also supports IP version 6 (IPv6) subnet prefixes, for example, 3FFE:FFFF:0:C000::/64. For more information about IP subnets in each location.
Associate each subnet object with a site object by referring to the “Associating Subnets with Sites” (DSSTOPO_6.doc) worksheet in “Deciding Which Locations Will Become Sites” section to determine which subnet is to be associated with which site.