The Importance of a Domain - Sites
(Page 9 of 11 )
So far, the components we have looked at have been logical components, forests, trees, domains, and OUs. We can design these items. However, there are some physical components, the physical location of your users, computers, servers, and the connectivity between these locations that you cannot 'design' in the normal sense; instead, you have to document these to the Active Directory to aid in its function.
To document your physical structure in a way that can be understood by the Active Directory, use IP subnets. Since Active Directory is based around DNS, which in turn requires TCP/IP, it is the most logical choice. IP subnets are always a local LAN area, e.g. a floor of a building. (If you have a single subnet over a wide area network you need to correct this before implementing AD.) It is very common for one location to use multiple subnets (if, for example, it has too many machines to be covered by one subnet).
The first step is to define all the IP subnets in your environment and then enter your physical locations with the IP subnets linked in those locations. The Active Directory now has the name of each site and knows what IP addresses reside within it. Since every computer has an IP address, its physical location can be determined due to the link between IP subnets and sites.
Which IP subnets should be placed in a site? As long as the subnets are geographically within the same area and are connected via a LAN, for example over 10Mbps (although a speed as low as 512Kbps can be adequate), they can be configured in a site. A site is a group of computers communicating via high-speed, reliable connectivity.
Once the links between the sites are manually defined, which includes the speeds of the links (which are defined by costs; the lower the cost, the faster the link), the availability of the links is also defined (for example, a link may not be available at night).
In this company, in the preceding figure, four geographical locations are used with the various IP subnets defined. The network speeds are also documented (although these would be converted to a cost when defined in the Active Directory). Notice that for this company Dallas is really the hub; although San Antonio and Houston do have some limited communication, it would still be faster for them to communicate via Dallas.
Defining all the sites when the connectivity between them is a lot of work initially—why does the Active Directory need to know the physical locations of the machines on the network? This is for two main reasons:
Firstly, one of the major problems with Windows NT 4 domains was replication over WAN links. Very little control was possible regarding replication; NT 4 had no way of knowing where the domain controllers physically resided or the connectivity between them, and so, very little configuration was possible.
With the sites defined, the Active Directory is aware of where the domain controllers are physically located and the network connectivity between them. This knowledge is used by the Knowledge Consistency Checker ( KCC), to create replication connection objects between domain controllers to define a replication topology used for the replication of the Active Directory data.
The second main use is that since clients have IP addresses they know which physical location they reside in. If the client needs a service (say, a domain controller), it can be told to use a domain controller in its local location (or a closest location, if no domain controller is available in its local site). This is known as site awareness and most major Active Directory services are site aware, minimizing traffic sent over slower WAN-type links by sending clients to services in their local site, where possible.
By default, the KCC component runs every 15 minutes checking that the topology generated is the most efficient. The KCC runs on every domain controller, which may lead you to believe it would be possible for domain controllers to create different topologies leading to problems with the replication; but such problems do not arise. Each domain controller uses the same algorithm to create the topology, and has the same information about sites and the domain controllers within them. The same inputs to an algorithm will lead to the same result.
The actual connection objects created by the KCC vary if the connection objects are created within (intra) a site or between (inter) sites. Remember that within a site, a high bandwidth network, a LAN, connects all the computers and so network bandwidth is plentiful and replication can be based around the fastest update of all the domain controllers in the site; the traffic generated is not a concern.
To this end within a site, a ring topology replicates information. Every domain controller has at least two connections to other domain controllers within the site; sometimes more connections are created to ensure there are never more than three hops between any two domain controllers. This replication is trigger based; whenever a change is made within a defined time (five minutes by default) the domain controller with a change, will notify its replication partners and they will pull the change. No compression is used when sending the data, as the CPU time required to perform the compress/decompress would be more expensive in terms of resources than the additional network use.
Between sites, the network may not be fast and reliable and so the number of connections and replication traffic are minimized. To achieve this instead of a ring, a least-cost spanning tree is used, which ensures that all sites are connected in the cheapest way possible. Because the network is slower, replication is based around a schedule, for example, every 30 minutes replication occurs between site A and B. To save network bandwidth the information is compressed if it is over 32KB in size.
In this example, each site has its own ring of replication and then both San Antonio and Houston have a single replication connection object for the inter-site replication
One big change from NT 4 is that for intra-and inter-site replication only the modified attribute is replicated. Previously if a single attribute changed the whole object would be replicated, but now only the modified attribute is replicated, saving a lot of bandwidth and computational processing.
Site definitions and site links are stored in the Configuration naming context; this means it is common to the entire forest. You do not have to define your sites for every domain, and you define them once for the entire enterprise so that domain controllers from different domains can reside in the same site. This is important as it's not just the domain information that has to be replicated, but also the schema, configuration, and application partitions. These also need their own replication topologies so as to replicate across domain boundaries and, like domains, different rings/spanning trees are created depending on domain controller site location. As we will see later on, there are multiple rings of replication running within a site performing different functions.
There is far more to sites and the replication used and we'll cover this in much more detail when we get to the appropriate scenario, as this is one of the key areas that, when implemented well, results in an efficient, well connected directory service environment.
FSMO Roles
The other physical component is the domain controllers themselves. As we have seen, in the Active Directory all the domain controllers are equal. There is no PDC or BDC; all the controllers are equal, performing multi-master replication.
We have also seen that NT 4 BDCs can participate in an Active Directory domain. How is this possible since NT 4 BDCs have to pull information from the PDC, which no longer exists?
Some domain controllers are more equal than others. In fact, there are five special roles that certain domain controllers hold to perform functions that cannot work in a multi-master fashion. These are known as Flexible Single Master Operation or FSMO roles. The first of these relates to handling NT 4 BDCs; that's not all it does, but it's a start.
PDC Emulator FSMO Role
A single domain controller in each domain holds only the PDC FSMO role. You always have one PDC FSMO role per domain in the same way that you used to have one PDC per NT 4 domain.
The PDC FSMO performs a number of functions:
- It provides the replication point for NT 4 BDC's in the domain.
- Each PDC FSMO in the forest synchronizes its time with the other PDC FSMOs within the forest. The PDC FSMO in the root domain of the forest is the source of the time synchronization and is normally configured to synchronize its time with an external time source. All clients and servers within each domain synchronize their time with their domain's PDC FSMO.
- It provides down-level clients support for password updates. Since non AD– aware clients know BDCs are for read-only, they would always attempt to change passwords with the PDC.
- It acts as the Master Domain Browser if the service is enabled.
- Password changes at any DC are always replicated to the PDC FSMO first. This is because replication can take time to propagate the password change and if a user has just changed their password and attempts to authenticate again against a different domain controller the new password may not have replicated and so the authentication attempt would fail. To avoid this, if the authentication fails at a domain controller instead of rejecting the request the domain controller will first contact the PDC FSMO role holder to attempt a second authentication before a failure is passed back to the user.
- Due the criticality of locking out an account, this is always processed at the PDC FSMO to provide a central location for checking the status of accounts.
- Where possible the PDC FSMO will be contacted for Group Policy maintenance (edit/create). However, other DCs can be used via configuration.
As seen, even when there are no NT 4 BDCs or non-AD clients the PDC FSMO role is still required though its workload would be reduced.
The normal site awareness of replication does not apply to NT 4 BDCs, which, as seen in this figure, will always replicate with the PDC FSMO role holder, regardless of which site it resides in and the cost involved. This becomes an important factor when considering the placement of your FSMO role holders.
Next: RID Master FSMO Role >>
More IIS Articles
More By PACKT Publishing
|
 This article is taken from chapter one of the book Windows Server 2003 Active Directory Design and Implementation: Creating, Migrating, and Merging Networks by John Savill (PACKT Publishing, 2005; ISBN: 1904811086). Check it out at your favorite bookstore. Buy this book now.
|
|
