ACTIVE DIRECTORY WORKING WITH SITES CLASS NOTES NT1330
MR. GRAHAM
10/14/13
Sites overview
Sites in Active Directory® represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects in the directory, to build the most efficient replication topology. You use Active Directory Sites and Services to define sites and site links. A site is a set of well-connected subnets. Sites differ from domains; sites represent the physical structure of your network, while domains represent the logical structure of your organization.
Using sites
Sites help facilitate several activities within Active Directory, including: * Replication. Active Directory balances the need for up-to-date directory information with the need for bandwidth optimization by replicating information within a site more frequently than between sites. You can also configure the relative cost of connectivity between sites to further optimize replication. * Authentication. Site information helps make authentication faster and more efficient. When a client logs on to a domain, it first searches its local site for a domain controller to authenticate against. By establishing multiple sites, you can ensure that clients authenticate against domain controllers nearest to them, reducing authentication latency and keeping traffic off WAN connections. * Active Directory-enabled services. Active Directory-enabled services can leverage site and subnet information to enable clients to locate the nearest server providers more easily. For information about services, see Services.
Defining sites using subnets
In Active Directory, a site is a set of computers well-connected by a high-speed network, such as a local area network (LAN). All computers within the same site typically reside in the same building, or on the same campus network. A single site consists of one or more Internet Protocol (IP) subnets. Subnets are subdivisions of an IP network, with each subnet possessing its own unique network address. A subnet address groups neighboring computers in much the same way that postal codes group neighboring postal addresses. The following figure shows several clients within a subnet that defines an Active Directory site.

Sites and subnets are represented in Active Directory by site and subnet objects, which you create through Active Directory Sites and Services. Each site object is associated with one or more subnet objects.
Computers are assigned to sites based on their Internet Protocol (IP) address and subnet mask. Site assignment is handled differently for clients and member servers than for domain controllers. For a client, site assignment is dynamically determined by its IP address and subnet mask during logon. For a domain controller, site membership is determined by the location of its associated server object in Active Directory. For more information, see "Active Directory Replication" at the
In Active Directory, sites map the physical structure of your network, while domains map the logical or administrative structure of your organization. This separation of physical and logical structure provides the following benefits: * You can design and maintain the logical and physical structures of your network independently. * You do not have to base domain namespaces on your physical network. * You can deploy domain controllers for multiple domains within the same site. You can also deploy domain controllers for the same domain in multiple sites.

For more information about domains, see Domains

A site represents a region of uniformly good network access, which can be interpreted as being generally equivalent to local area network (LAN) connectivity. LAN connectivity assumes high, inexpensive bandwidth that allows similar and reliable network performance, regardless of which two computers in the site are communicating. This quality of connectivity does not indicate that all servers in the site must be on the same network segment nor that hop counts between all servers must be identical * Sites: 1. are based on ip subnets within a physical network 2. subnets are created within AD on the physical design of the network 3. user logon causes a query of the AD site topology to locate closest domain controller to do authentication 4. domain controllers use the site topology to establish replication partners
Replication is a fundamental component of any enterprise disaster recovery (DR) solution, ensuring that critical data and applications can be reliably and efficiently replicated to a different site or a separate infrastructure. While enterprise IT architects have many technology options, there are two replication capabilities that are requisite for any successful enterprise DR initiative. * Per-VM backup – The ability to designate certain VMs for backup to a different site is particularly useful in branch office environments. Typically, only a subset of VMs running in a branch location require regular back up to a central site. Such per-VM level of granularity, however, is not possible when replication is built on traditional storage arrays. In these legacy environments replication is performed at a coarse grain level, entire LUNs or volumes – making it difficult to manage replication across multiple sites. * Selective bi-directional replication – In addition to replicating selected VMs, a flexible replication solution must also accommodate a variety of enterprise topologies. It is no longer sufficient to simply replicate VMs from one active site to a designated passive site, which can be ‘lit up’ in event of a disaster. Supporting different topologies demands that data and VMs can be replicated bi-directionally. 1. Two-way mirroring – The ability to mirror VM replication between multiple sites is necessary in environments where all sites must support active traffic. Consider a two-site example. Site 2 is used as the target for selected workloads running on Site 1. At the same time, Site 1 serves as the DR target for designated workloads running at Site 2
Replication within a site is driven by changes. The high speed and reliability of LAN connectivity lends itself to on-demand data transfer. When a change is applied to a specific replica, the replication engine is triggered. The replication engine waits for a configurable interval (by default, five minutes) and then notifies the first replication partner.

Replication between sites is scheduled so that you can control replication costs and keep replication from overwhelming your communication links. Several factors contribute to the speed of replication between sites, including the nature of the physical connections and how expensive they are to use. Active Directory supports site connections in all speed ranges, from T3#160;links on the high end to dial-up lines on the low end. You use the speed of the connection between your sites to assign a cost to the communication link, and replication uses the cost to establish the least expensive route for replication traffic

3. Many-to-One – In a hub and spoke architecture workloads running on site 1 and 2, for example, can be replicated to a central site 3. Centralizing replication to a single site may improve operational efficiency for geographically disperse environments. Remote and branch offices (ROBO) are a classical use case of a many-to-one topology

Active Directory uses site information in the following ways: * When a client requests a connection to a domain controller (for example, when logging on), sites are used to enable the client to connect to a domain controller with good connectivity whenever possible. Fast connections reduce network latency and conserve network bandwidth. * When the KCC configures replication connections between domain controllers, it creates more connections between domain controllers in the same site than between domain controllers in different sites. The results are lower replication latency within a site and less replication bandwidth between sites. * Replication messages between domain controllers within a site are uncompressed, which means that fewer CPU cycles are used on the domain controllers. Replication messages between domain controllers in different sites are compressed, which means that less network bandwidth is used. * Replication between domain controllers within a site is triggered by the arrival of updates, which thereby reduces replication latency within a site. Replication between domain controllers in different sites is performed on a schedule, which thereby conserves network bandwidth between sites.
Sites are not tied in any way to the Active Directory namespace that is used by the domain directory partitions. The name of a domain directory object does not reflect the site or sites in which the object is stored.

When to Define a New Site
When you have slow links between network segments, it is recommended that you create two sites and place domain controllers into the sites according to the following general rules: * Deploy at least one Global Catalog per site. * Deploy DNS servers on a site level. 2. The first domain controller in the forest is designated automatically as a Global Catalog server. When you create additional sites, you can use Active Directory Sites and Services to select the Global Catalog option in the properties for the NTDS Settings object of the server that you want to be the Global Catalog. Having a Global Catalog server in each site improves search performance because searches do not have to cross site boundaries. In addition, a Global Catalog server is required for logging on to the domain; if a connection between sites is not available, logging on is not possible. 3. If a Global Catalog server is not available in one site but there is another Global Catalog server in a remote site, the server in the remote site can be used for the logon process. If no Global Catalog is available in any site, the logon process proceeds with cached logon information. * The availability of DNS directly affects the availability of Active Directory. Clients rely on DNS to be able to find a domain controller, and domain controllers rely on DNS to find other domain controllers. As a general rule, you configure at least one DNS server in every site. * When you create sites and put servers into the sites, you connect the sites with site links and configure the links to reflect the network characteristics in terms of how often you want replication to occur on the link. * Data sent to the host by SNA Server may not be compressed, even though the compression parameters for SNA Server have been configured. Data received from the host by SNA Server is compressed. An SNA node message trace shows the bind sent by SNA Server with the Length-Checked Compression Control Vector (0x66) included, but the bind response does not contain this vector. A VTAM trace taken simultaneously shows that the compression vector was included when the bind response was sent by VTAM