Designing an Active Directory Services Site Topology

An Active Directory site is basically a collection of well-connected IP subnets. The links between the subnets within a site are generally fast, reliable, and capable of supporting replication.

graphics/note_icon.gif

Because the creation of sites is based on the physical topology, a site can contain IP subnets from multiple domains.


Creating sites enables you to control and optimize the following events:

  • User authentication When a user logs on to the network, a domain controller within the same site is contacted to authenticate the user. This means the logon process is more efficient because the user does not have to log on over a slow, unreliable link.

  • Controlled replication Creating multiple sites allows replication across slow, unreliable links to be controlled by specifying a schedule, frequency, and cost.

  • Site-aware applications An application that is site-aware, such as the Distributed File System (DFS), can take advantage of the site top ology by attempting to connect to a domain controller within the same site before attempting to connect to a domain controller in another site.

Active Directory sites are created to optimize replication. Replication within a site occurs differently than it does between two separate sites. Intrasite replication is designed to take advantage of the fact that the IP subnets within a site are connected by fast, reliable links. Replication between sites (intersite replication) is designed to occur differently because it is assumed that the links connecting two sites are slow, unreliable, and possibly already heavily utilized. Table 4.3 summarizes the differences between intrasite and intersite replication.

Table 4.3. Intrasite Versus Intersite Replication

Intrasite Replication

Intersite Replication

Information replicated within a site is uncompressed

Information replicated between sites is compressed to optimize bandwidth.

Domain controllers within a site notify each other when a change occurs, which reduces the time for changes to appear throughout a site.

To optimize bandwidth, there is no notification process between sites, which means that information on domain controllers might not always be up to date.

Domain controllers within a site poll each other for changes on a regular basis.

Domain controllers between sites poll each other at a preconfigured interval during scheduled times.

Replication occurs between multiple domain controllers.

Replication between sites occurs between specific domain controllers only.

Designing Sites

Creating sites gives an administrator the ability to control workstation logons and replication throughout a network infrastructure. When planning and defining the site boundaries, your main focus will be on the physical topology of the network. At this point, it would be a good idea to refer to the diagram you created when performing an assessment of WAN links and available bandwidth. When planning site boundaries, use the following guidelines:

  • Create a site for each group of IP subnets connected by fast, available, and reliable links.

  • For a network compromised of a single LAN, a single site is usually sufficient.

  • Create a separate site for those IP subnets connected by slow, unreliable, and heavily utilized links.

  • For sites that don't have a domain controller located within them, consider merging them with another nearby site.

These are just some basic guidelines to follow when determining how many sites to create.

Identifying Site Links

Site links are similar in concept to trust relationships. A trust is the link between two domains; a site link is the connection between two Active Directory sites. The site link that is established between two sites is used to control replication across the physical link.

Site links are transitive by default. That means if a site is defined between sites A and B, and another is defined between sites B and C, it is automatically assumed that sites A and C can communicate. These transitive site links basically establish a replication path so that information can be replicated throughout the organization. When you're defining a site link, certain options are used to control replication over the link (see Figure 4.6).

Figure 4.6. Properties of a site link.

graphics/04fig06.gif

This can be used to allow remote sites with poor connectivity access through a nearby site with better connectivity; on the other hand it could cause replication overload on the intermediate site.

A site link is defined by the following characteristics, each of which is discussed in detail later in this chapter:

  • Schedule The schedule defined for a site link specifies the times when replication can occur over the link.

  • Interval The frequency that intersite replication occurs across a link. The default is every 180 minutes (every 3 hours).

  • Link cost The value assigned to the site link. If there are multiple site links, the one with the lowest cost is tried first.

  • Replication protocol The protocol used to transfer data between two sites. You can use one of two methods: RPC over IP or SMTP.

Schedule

Another option an administrator has in controlling replication between sites is scheduling when site links are available. Intersite replication does not use the process of notification. If changes occur within one site, the other sites are not notified. Instead, a domain controller in one site periodically checks for changes by contacting a domain controller in another site.

To optimize this process, an administrator can schedule certain times when the site link can be used for intersite replication. Doing so ensures that replication does not occur when the link is already heavily utilized.

One of the drawbacks of placing a schedule on a site link is that it can increase replication latency. Replication latency is the time it takes for changes made on one domain controller to appear on another domain controller. Placing a schedule on a link obviously implies that information between sites might not always be up to date.

However, if a link used for RPC replication is saturated when a replication cycle begins, the replication might fail with an RPC timeout. Therefore, although latency can be a problem in a multiple-master environment such as Active Directory, setting site link schedules could actually improve replication performance.

Interval

As already mentioned, the interval indicates how often replication occurs during the times when replication is allowed to occur. The default interval is 180 minutes. Lowering this value reduces latency and keeps the domain directory partitions up-to-date, but doing so increases the amount of replication traffic.

Link Cost

One of the advantages of using site links is that they can be assigned a site cost. A site cost is basically a number that is assigned by an administrator to a site link. By assigning a cost to a site link, an administrator can basically define a preferred route for replication when multiple routes exist (similar to the metrics used in routing tables).

When assigning a cost to a site link, keep in mind that a site link with a lower value is preferred to a site link with a higher value. However, the route used is ultimately up to the route path defined in the routing tables.

Replication Protocol

When planning for sites and site links, you also need to decide on the protocol to use to replicate information. You can use RPC over IP or SMTP.

The default transport that can be used for intersite replication is RPC over TCP/IP. This transport can be used for intersite as well as intrasite replication. RPC uses synchronous transfer, meaning there must be a direct connection with the destination server before any information will be replicated. This poses a problem for WAN links that are unreliable because if a connection cannot be established, replication does not occur. Also, if the WAN link is slow or congested, RPC timeouts can occur, causing replication to fail. RPC is inadvisable for link speeds under 128Kbps. RPC timeouts and replication failures can also occur when using VPN connections, even at 128Kbps or higher. The reason for the timeouts is the unpredictable latency of VPN circuits, which depend on the Internet to transmit data from one location to another.

One of the main advantages of using RPC over IP is that it can support intersite replication traffic between all servers, including domain controllers from the same domain. RPC is also more efficient as an intersite transport.

SMTP basically sends information to be replicated between sites as email messages. Unlike RPC, it provides asynchronous data transfer, meaning that a direct connection with the remote server is not required. It also uses the store-and-forward method of sending information, meaning that if the destination host is not available, the message can be stored. This transport is an ideal choice if the link between two sites is unreliable. For example, when the link is not available, the message can be stored and sent when the destination server is available. However, note that the schedules set on a site link by an administrator are ignored when the SMTP protocol is used.

graphics/alert_icon.gif

Using SMTP as an intersite transport has some limitations because it can be used to replicate only the configuration, schema, and application directory partitions. It cannot be used to replicate the domain directory partition, and therefore cannot be used to replicate information between domain controllers in the same domain. In such cases, RPC must be used. The primary reason is that Sysvol replication, which is required to replicate part of a group policy object, must use RPC. Even if no GPOs are configured, Windows Server 2003 will not replicate the domain naming context via SMTP.




MCSE Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure Exam Cram 2
MCSE Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure Exam Cram 2 (Exam Cram 70-297)
ISBN: 0789730154
EAN: 2147483647
Year: 2003
Pages: 152

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net