Presentation on theme: "Module 8: Designing an Active Directory Site Topology."— Presentation transcript:
Module 8: Designing an Active Directory Site Topology
Overview Using Sites in Active Directory Assessing the Need for Active Directory Sites Using Site Links in a Network Planning the Inter-Site Replication Topology Planning for Server Placement in Sites
Sites are used to organize well-connected computers within an organization to optimize network bandwidth. Excessive network traffic can occur between remote locations due to frequent exchange of large amounts of data and directory information. Designing an appropriate site topology in Microsoft® Windows® 2000 Active Directory™ directory service helps you better organize your Windows 2000 network and optimize the exchange of data and directory information.
At the end of this module, you will be able to: Describe the purpose of sites and their role in Active Directory replication. Assess the need for Active Directory sites. Plan for the creation of site links and site link bridges. Plan an inter-site replication topology. Plan for server placement in sites.
Using Sites in Active Directory Sites Control: Workstation logon traffic Replication traffic Dfs topology FRS Other Site-Aware Applications Paris Site 192.168.2.0 192.168.3.0 nwtraders.msft Redmond Site 192.168.4.0
A site is a collection of well-connected machines, based on Internet Protocol (IP) subnets. You use sites in Active Directory to define the physical structure of your network. A site consists of one or more subnets. For example, if a network has one subnet in Redmond and two subnets in Paris, the administrator can create one site in Redmond and one in Paris, and add the subnets to the local sites. Sites may contain domain controllers from one or more domains.
You can use sites to optimize network bandwidth in the following ways:
Workstation logon traffic. When a user logs on, Windows 2000 searches for a domain controller in the same site as the workstation.
Replication traffic. When a change occurs in Active Directory, sites can be used to control how and when the change is replicated to domain controllers in another site.
Distributed file system (Dfs) topology. When a shared file or folder has multiple locations, a user will be directed to a server in his or her own site, if one exists. Localizing the availability of servers in a site reduces traffic across slow links.
File Replication service (FRS). FRS is used to replicate the contents of the SYSVOL directory, which includes logon and logoff scripts, Group Policy settings, and system policies for Windows 95, Windows 98 and Windows NT® version 4.0. FRS uses sites to determine its replication topology.
By using other site-aware applications. A site-aware application is a directory-enabled application that connects a client with a server in its own site, if the server is available there. As third party applications are developed, they may also make use of sites to allow clients to connect to shares within their own sites. Dfs and FRS point clients to servers within their site before pointing them to servers outside their site.
Active Directory uses site information in the following ways: The Knowledge Consistency Checker (KCC) generates a replication topology that is primarily used within sites rather than between sites. This intra-site topology may increase network traffic, but will reduce replication latency. Windows 2000 client computers use site information to find nearby domain controllers for logon and query operations.
To optimize network bandwidth during replication, you must consider the factors that affect replication. The three significant replication factors include: Replication latency. The time needed for one domain controller to receive a change made on another domain controller. Replication efficiency. The ability to batch together the number of changes sent with each update. Replication cost. The amount of bandwidth needed to replicate the changes between domain controllers.
In a given network, optimizing one of these replication factors will impact the other factors. For example, a frequent replication interval lowers the replication latency and raises the replication cost and efficiency.
Intra-site Replication Replication latency within a site is low, because of the high network bandwidth available within a site. Low latency ensures that users within the site will have access to the most recent information at all times. Replication within a site will take place five minutes after a change has occurred. The originating server will notify its replication partners of the change, and they will, in turn, request the change.
Inter-site Replication Usually there is limited bandwidth available for replication between sites. Before being replicated, data is compressed to about 10 percent of original volume to reduce the amount of data on the network. To optimize the limited network bandwidth and replication efficiency even more, you can raise replication latency by scheduling when replication will occur between sites.
Assessing the Need for Active Directory Sites Planning Domain Controller Placement Evaluating Connectivity and Available Bandwidth Determining Replication Traffic
Before planning the site topology of a network, you need to assess the need for sites in the network. The unnecessary addition of sites in a network may result in replication across slow links and inefficient use of network bandwidth. There are several factors that will determine where site locations are required: Available bandwidth Anticipated replication traffic Placement of domain controllers
Begin the site design process by documenting the existing network infrastructure. Document the types of links between physical locations, the amount of available bandwidth, and the number of users and computers at each location.
In this lesson you will learn about the following topics: Planning domain controller placement Evaluating connectivity and available bandwidth Determining replication traffic
Philadelphia Pittsburgh Allentown Planning Domain Controller Placement At Least One Domain Controller Per Site for Best Performance For Sites with Few Users, Use a Slow Link Total – Used = Net Available nwtraders.msft
The first step in planning a site structure is to determine where a domain controller is required. A domain controller must be able to respond to client requests in a timely manner that suits the requirements of the clients. For best performance, place at least one domain controller in each site that contains users or computers of that domain. With a domain controller at each location in your network, all users will have a local computer that can service query requests for their domain over local area network (LAN) connections.
In some situations, however, it may make sense not to place a domain controller at each location. For example, if there is a location with only ten users, you may decide it is a better use of the available bandwidth to have those users log on and query the directory over a slow link.
To help determine domain controller placement, identify potential speed and net available bandwidth by using the equation total - used = net available, where total refers to the total bandwidth available to the network, used refers to the bandwidth that is being used up by the network, and net available bandwidth refers to the bandwidth available to other applications.
Evaluating Connectivity and Available Bandwidth Connectivity Fast, Reliable, Inexpensive If Use is Low Between Locations, Slower Connectivity May Be Sufficient Available Bandwidth Amount of Connectivity Use If Use is High Between Locations, Consider Separate Sites
You need to examine connectivity and available bandwidth when grouping subnets into sites. The decision to combine multiple subnets to form a Windows 2000 site is a function of both well-connected subnets and networks with a lot of available bandwidth.
Connectivity Only combine subnets that are connected by fast, inexpensive, and reliable links into a site. The definition of a fast link will vary from organization to organization, but a Windows 2000 site should be connected with links of 10 Megabits per second (Mbps) or greater. For example, a slow connection, such as a 56Kbit/s RAS connection, is sufficient if changes happen rarely. However, if employee turnover at an organization is high and group memberships change daily, even a medium- sized domain might take up considerable bandwidth on a 128 Kbps link.
Available Bandwidth Available bandwidth is also an important consideration in determining a site plan, because a connection that is fast, inexpensive, and reliable may be heavily used. For example, you may consider a 1.544-megabit network connection between two locations fast, inexpensive, and reliable. However, if 75 percent of this connection is used without any traffic from Active Directory or users logging on, it may be desirable to control the replication traffic and logon requests that use this connection. Even though the connection between locations is fast, inexpensive, and reliable, it still may be advantageous to create sites on both sides of the connection.
Determining Replication Traffic Compression Occurs Once Traffic Exceeds 50KB Use Active Directory Sizer to Determine Replication Traffic Size of Organization Is Poor Indicator of Traffic Increasing Latency Can Also Increase Efficient Use of Network
When assessing the need for sites, consider the estimated amount of traffic that replication will generate. Replication between sites is compressed, but only when the amount of traffic exceeds 50,000 bytes (50KB). Use the Active Directory Sizer utility available in the Windows 2000 Server Resource Kit to determine replication traffic. The size of an organization is not a good indicator of traffic. For example, a medium-sized organization may have regular staff changes, which will generate a significant amount of replication traffic, whereas a large organization may be fairly stable, with few changes occurring on a regular basis. If there are only very small changes occurring, inter-site replication may cause increased traffic because of the need to refer to additional naming contexts outside the site.
You can increase network efficiency by increasing replication latency. Increasing latency will increase the amount of traffic, but once the level of traffic exceeds 50KB, it is compressed, thereby reducing overall traffic. Note: Less information is replicated between domain controllers of different domains than between domain controllers in the same domain. The global catalog server replication only replicates a subset of the object attributes.
Using Site Links in a Network Paris Site Link: Par-Cha Redmond Charlotte Atlanta ATM Backbone Site Link: Red-Cha-Atl 56KB WAN Link Site Links Are Defined By: Transport Member Sites Cost Schedule Inter-Site Topology Spans All Sites in a Network
The connection between two sites is defined as a site link. Site links can be used for replication. Planning site links involves considering the best replication path and the replication schedule between sites. Replication paths can be prioritized by assigning costs to different replication paths.
Lesson Overview Site links are defined by the following components: Transport. The transport defines the type of protocol used, either RPC over IP or SMTP. Member sites. Two or more sites to be connected by the site link. Cost. A number that determines which site link will be used for replication when there are multiple site links between two locations. Schedule. The times when replication will occur.
Lesson Overview A typical site link connects two sites only and corresponds to a wide area network (WAN) link, although it could correspond to a backbone, which connects several sites together. Sites are connected by different network technologies, such as a T1 line, network, or dial-up link. Each site in a multiple-site environment must be connected by at least one site link. Otherwise, domain controllers within a site will not be able to replicate with domain controllers in any other site. Inter-site replication topology spans across all sites in the organization. As long as a replication route can be constructed between all sites in the enterprise, the replication topology is functional. You can create site links that allow domain controllers from any site to communicate with domain controllers in any other site.
Planning Site Link Schedules and Costs Redmond Charlotte Atlanta Red-Cha-Atl Site Link Cost=1 Available At All Times Red-Cha-Atl Site Link Cost=1 Available At All Times Red-Atl Site Link Cost=300 Available 8 PM to 6 AM Red-Atl Site Link Cost=300 Available 8 PM to 6 AM Paris Cha-Par Site Link Cost=500 Available 7 PM to 2 AM Cha-Par Site Link Cost=500 Available 7 PM to 2 AM Red-Par Site Link Cost=500 Available 7 PM to 1 AM Red-Par Site Link Cost=500 Available 7 PM to 1 AM Control Topology by: Setting Costs Scheduling Availability
Site links are based on the cost of replication, which reflects the speed and reliability of the underlying network, and its schedule, which defines a time period when replication is allowed over the link.
Site Link Schedules You have the option of controlling when replication will occur between sites. Unlike intra-site replication, inter- site replication does not use a notification process. Because there is no notification between the replication partners, a domain controller must check all replication partitions on the originating domain controller.Try to schedule inter-site replication when bandwidth utilization is low. For example, you may schedule the link to be used only outside of regular business hours. However, this scheduling will increase replication latency, and you may decide that updating once a day is unacceptable. You can offset the increase in latency by scheduling replication to occur only once an hour.
When setting schedules, be aware of connections that use multiple site links. For example, you may have a domain that resides in three sites, A, B, and C. If the site link for AB is available from 9 p.m. to 1 a.m., and the site link for BC is available from 2 a.m. to 6 a.m., the replication partners in A and C will never replicate directly with each other.
Site Link Cost Site link cost is a number that represents the priority an organization assigns to replication traffic between the sites identified in the site link. For example, an IP site link named Red- Cha-Atl connects three sites, Redmond, Charlotte, and Atlanta, with a cost of 1. This tells Active Directory that an IP message can be sent between all pairs of sites with a cost of 1. Higher cost numbers represent lower priority replication paths. If there are multiple site links between two sites, Active Directory replication will use the link with the lowest cost that is available. For example, if there is a site link named Red-Cha-Atl that connects Redmond and Charlotte with a cost of 1, and a site link called Red- Cha that connects Redmond and Charlotte with a cost of 300, any replication will attempt to use the Red-Cha-Atl link first.
Options for Controlling Site Links Any number of site links can connect a site to other sites. Each site in a multi-site directory must be connected by at least one site link. You can control and schedule each site topology independently.
You can control: Topology by setting the costs on site links. In a common scenario you might set cost = 1 for site links that are part of your backbone network, and cost = 100 for site links corresponding to slow connections to branch offices. Setting costs in this way ensures that a branch office replicates with a domain controller in a site that is part of the backbone, never directly with a second branch office. Replication frequency by setting the number of minutes between replication attempts on site links. In a common scenario you might set the global default replication frequency to 15 minutes, and set a longer frequency on site links corresponding to slow connections to branch offices. The longer frequency makes more efficient use of the link but increases replication latency. Link availability by using the schedule on site links. You would use the default schedule of 100 percent availability on most links, but you could block replication traffic during peak business hours on links to certain branches. By blocking replication, you give priority to other traffic but increase replication latency.
Assessing the Need for Site Link Bridges Red-Cha Site Link Cost = 3 Red-Cha Site Link Cost = 3 Cha-Atl Site Link Cost = 4 Cha-Atl Site Link Cost = 4 Red-Cha-Atl Site Link Bridge Cost = 7 Red-Cha-Atl Site Link Bridge Cost = 7 Par-Red Site Link Cost = 2 Par-Red Site Link Cost = 2 nwtraders.msft Redmond Charlotte Atlanta Paris
site link bridge connects two or more sites together by using multiple site links. Site link bridges model the routing behavior of a network. By default, all site links are considered transitive. That is, all site links for a given transport will implicitly belong to a single site link bridge for that transport. This means site link bridges are not necessary in fully routed IP networks. If your IP network is not fully routed, the transitive site link feature for the IP transport can be turned off. This will result in all IP site links being considered intransitive, so site link bridges will need to be configured to model the actual routing behavior of the network. Specifying two or more site links creates a site link bridge object for a specific inter-site transport, typically RPCs over IP.
For example: Site link Red-Cha connects sites Redmond and Charlotte through an IP with a cost of 3. Site link Cha-Atl connects sites Charlotte and Atlanta through an IP with a cost of 4. Site link bridge Red-Cha-Atl connects Red-Cha and Cha- Atl. The site link bridge Red-Cha-Atl implies that an IP message can be sent from Redmond to Atlanta with a cost of 3 plus 4, or 7.
Each site link in a bridge needs to have a site in common with another site link in the bridge. If not, the bridge cannot compute the cost from sites in one link to sites in other links of the bridge. Multiple site link bridges for the same transport work together to model multi-hop routing. Add the following objects to the preceding example: Site link Par-Red connects sites Paris and Redmond through an IP with a cost of 2. Site link bridge Par-Red-Cha connects Par-Red and Red-Cha.
Now the site link bridges Par-Red-Cha and Red-Cha-Atl together imply that an IP message can be sent from site Paris to site Atlanta with a cost of 2 plus 3 plus 4, or 9.
Planning the Inter-Site Replication Topology Choosing Inter-Site Replication Transports Delegating Bridgehead Servers Examining the Inter-Site Topology Generator Determining the Least-Cost Spanning Tree
Inter-site replication topology refers to the configuration of replication between sites in a network. Planning replication topology includes choosing a replication transport and delegating bridgehead servers. The topology will depend on the scenario in which it is being applied. For example, a reliable network connection may use a synchronous transport, while an unreliable network connection may use an asynchronous transport.
In this lesson you will learn about the following topics: Choosing inter-site replication transports Delegating bridgehead servers Examining the inter-site topology generator Determining the least-cost spanning tree
Choosing Inter-Site Replication Transports Remote Procedure Calls (RPCs) over TCP/IP Synchronous Transfer Requires Reliable Connections Generates Less Traffic Can be Used with DCs in Same Domain Simple Message Transport Protocol Asynchronous Transfer Used with Unreliable Connections Generates More Traffic Cannot be Used with DCs in Same Domain
You will need to select a transport method for inter-site replication. Windows 2000 provides two transport methods: Remote procedure calls (RPCs) and Simple Message Transport Protocol (SMTP).
Remote Procedure Calls over TCP/IP RPCs sent over a TCP/IP connection uses synchronous transport. The RPC transport will appear as the IP transport option. To send data using RPCs, a direct connection with the replication partner must be achieved. Thus, if the partner is unavailable, replication will not occur. With inter-site replication, the replication partner always pulls data in from its replication partner. There is no notification of changes.
Simple Message Transport Protocol SMTP sends replication data as asynchronous e-mail messages. Since SMTP is capable of storing messages and then forwarding them, it is the ideal transport in an unreliable network. Active Directory allows the underlying SMTP messaging system to take care of routing. Schedules set on a connection using SMTP are ignored. Because the replication data must be encapsulated within an SMTP packet, the SMTP transport generates from 80 percent to 100 percent more traffic than RPCs. The SMTP transport supports schema configuration and global catalog replication but cannot be used for replication between domain controllers that belong to the same domain. This is because some domain operations, such as Group Policy, require the support of the FRS, which does not yet support asynchronous transport for replication. Note: If you plan to use SMTP, you will need to use RPC for intra- domain replication. Refer to Notes from the Field by MS Press.
Delegating Bridgehead Servers Charlotte Redmond contoso.msft Bridgeheads for: contoso.msft Schema & Config Global Catalog Bridgeheads for: contoso.msft Schema & Config Global Catalog Bridgeheads for: Nwtraders.msft Bridgeheads for: Nwtraders.msft Global Catalog nwtraders.msft contoso.msft nwtraders.msft Schema & Config contoso.msft nwtraders.msft
A bridgehead server is a single server in each site used for replication between sites. Connection objects are created between bridgehead servers. The KCC automatically designates the bridgehead server, or you can manually assign one for the appropriate transport (IP for RPC over IP, or SMTP for SMTP over IP).
Manual Bridgehead Configuration If you choose to manually configure a single domain controller as the preferred bridgehead server for a site, the KCC will only use that server. If that server is unavailable, the KCC will not automatically assign another. The KCC only chooses another bridgehead if you have not designated a preferred bridgehead server. However, if you have configured multiple domain controllers in the same site as preferred bridgehead servers, the KCC will then arbitrarily select one of these servers.
Multiple Naming Contexts Because a bridgehead server must be designated for each naming context, you may need multiple bridgehead servers. For example, you have two sites, Redmond and Charlotte, and two domains, contoso.msft and nwtraders.msft. Each site has a domain controller from each domain. In this case, replication of the two domain naming contexts can occur between the two sites only if the domain controllers for nwtraders.msft and contoso.msft are selected as bridgehead servers in each site. Therefore, if there is a single domain controller for a domain in a site, that domain controller must be a bridgehead server in its site because it can replicate domain data to only a domain controller in its own domain. In addition, that single domain controller must be able to connect to a bridgehead server in the other site that also holds the same domain naming context.
Examining the Inter-Site Topology Generator Redmond contoso.msft Bridgeheads nwtraders.msft contoso.msft nwtraders.msft Charlotte contoso.msft Global Catalog Schema & Config ISTG
Topology generation for replication between sites is more complex than for replication within a site. In intra-site replication, the KCC assumes any server is capable of replicating with any other server. This is not the case with inter-site replication. With intra-site replication, the KCC on each domain controller plays a role in topology generation. Similarly, each site plays a role in inter-site topology generation. One domain controller in each site assumes the role of inter-site topology generator (ISTG). By default, this is the first domain controller in the site. The KCC on this domain controller is responsible for creating the connections between the domain controllers in its site and the domain controllers in other sites. The KCC creates inbound connection objects between the bridgehead servers in its own site and the other sites.
There is only one ISTG for each site, regardless of the number of domains represented in the site. The ISTG reviews the site topology and creates the appropriate inbound connections for the site in which it resides. If the ISTG determines that a connection object needs to be modified, it makes the change to its local Active Directory replica. The change propagates to the bridgehead servers in the site as part of normal replication. When the KCC on the bridgehead server reviews the new topology, it makes the received change.
Type of Network Link Proposed Assigned Cost Determining the Least-Cost Spanning Tree Backbone Link1 T1 to backbone200 56KB Link500 Branch Office 1000 International Link5000
The KCC uses a least-cost spanning tree algorithm to determine the replication topology between multiple sites and domains in the same forest. You set cost so the KCC will prefer certain routes. To maximize efficiency and minimize cost, the replication topology must consider your network environment, physical location, and business needs. While the KCC generates the inter-site topology automatically, the settings on the site links are the factors that the KCC uses to consider the topology. The default cost of a site link is 100. When setting costs, try to assign the same number to similar links. For example, if you have a T-1 connection that is at 30 percent utilization, and another T-1 at 35 percent utilization, assign the cost of 200 to each of them.
Planning for Server Placement in Sites Placing Global Catalog Servers Planning Placement of Operations Masters Demonstration: Active Directory Sizer
A site consists of domain controllers, global catalog servers, operation masters and bridgehead servers. For the appropriate utilization of these servers, it is important to plan their placement in sites. Planning server placement includes determining the need of a server in a network and, if it is required, determining the number of servers that will result in optimum utilization of the servers.
In this lesson you will learn about the following topics: Placing global catalog servers Planning placement of operations masters
Placing Global Catalog Servers Global Catalog Server LDAP query port 3289 Exchange 2000 Server
In an ideal environment, there would be a global catalog server at each site that can service query requests for the entire directory over the LAN. However, this many global catalog servers may significantly increase network traffic because of the partial replication of all objects from all domains.
Consider the following guidelines for placing global catalog servers: A global catalog server must have the capacity to hold partial replicas of all objects from all other domains in the Active Directory. The best query performance results from placing a domain controller designated as a global catalog server at small sites, thereby enabling the server to fulfill queries about objects in all domains in the Active Directory. Once a domain has been placed in native mode, a user will be unable to log on to the network without a global catalog server, unless the option allowing a user to log on using cached credentials is enabled.
Instead of placing a global catalog server at all sites, you can place one in each major site, in a regional Information Technology (IT) hub, or in a location on the WAN in which a large number of people and resources are present.
Microsoft Exchange 2000 Microsoft Exchange 2000 uses the Active Directory directory service as its directory. All mailbox names are resolved through queries that go through Active Directory. When a query occurs, Exchange queries a global catalog server. The number of queries a global catalog server must handle can increase extensively in a large Exchange environment. Try to place a global catalog server in each site that contains an Exchange server.
Operations masters control critical single master updates that cannot be easily resolved using multi- master replication. The placement of the operation masters needs to be considered.
Schema Master The schema master is the only domain controller on which you can make schema modifications. By default, it is the first domain controller in the Active Directory forest. There is one schema master per enterprise.
Domain Naming Master The domain naming master is used when domains are added or removed from the Active Directory forest. It allows the definition of new cross-reference objects representing domains and external directories, and prevents duplication of domain names. If the domain naming master is unavailable, you cannot add or remove domains. By default, the first server created in the forest is the domain naming master. There is one domain-naming master per enterprise.
Primary Domain Controller Emulator The Primary Domain Controller (PDC) emulator replaces a Windows NT 4.0 primary domain controller, but is necessary in Windows 2000-based networks as well. When a user changes his or her password, the change is sent to the PDC emulator immediately. If a user is unable to log on due to an incorrect password, the authenticating domain controller always checks with the PDC emulator before denying the logon request. If an account is locked out, this change is also immediately sent to the PDC emulator. There is one PDC emulator per domain.
Relative Identifier Master Each object created in Active Directory has a security identifier (SID), a number unique within the domain. A portion of that number is the relative identifier (RID). To ensure a unique SID within a domain, each domain controller is assigned a pool of numbers to use for the RID of each object. The RID master assigns these numbers to each domain controller in its domain. By default, once a domain controller has used 450 of its 500 numbers, it contacts the RID for a new pool of numbers. There is one RID master per domain.
Infrastructure Master The infrastructure master for a domain is responsible for updating the cross-domain references if the name of an object is changed. When an object name changes, the object receives a new distinguished name, and possibly a new SID if the object is moved to another domain. The infrastructure master removes any inconsistencies by matching the SID and the distinguished name of the object with its globally unique identifier (GUID). The infrastructure master updates these references locally and uses replication to bring all other replicas of the domain up-to-date. If the infrastructure master is unavailable, these updates are delayed. It is recommended that only domain controllers that are not global catalog servers act as infrastructure masters. A global catalog server would not identify inconsistencies in these cross-domain references because it has all objects in its directory database. There is one infrastructure master per domain.
Lab A: Planning Sites to Control Active Directory Replication
Review Using Sites in Active Directory Assessing the Need for Active Directory Sites Using Site Links in a Network Planning the Inter-Site Replication Topology Planning for Server Placement in Sites