Learn AD in 15 Minutes a Week: Active Directory Single Masters of Operation

Download the authoritative guide: Data Center Guide: Optimizing Your Data Center Strategy

Download the authoritative guide: Cloud Computing: Using the Cloud for Competitive Advantage

by Jason Zandri

Welcome to the eighth installment of Learn Active Directory Design and Administration in 15 Minutes a Week, a weekly series aimed at current IT professionals preparing to write the new Windows Active Directory Design and Administration exams (70-219 and 70-217 respectively), as well as newcomers to the field who are trying to get a solid grasp on this new and emerging directory service from Microsoft. This installment is going to discuss the Windows 2000 Active Directory Single Masters of Operation. This particular article is going to be a general overview and the next few, in the weeks to come, will break each individual role down in more detail.

Jason Zandri's latest article in the Learn Active Directory Design and Administration in 15 Minutes a Week provides a general overview of the Windows 2000 Activie Directory Single Masters of Operation.



In the Windows 2000 Active Directory, there are certain specific domain controllers that are assigned the extra role of Operations master. Sometimes referred to as Flexible Single Masters of Operation (FSMO) servers, these roles are special roles assigned to one or more domain controllers in an Active Directory domain and forest. The domain controllers assigned these roles perform single-master replication of the data they are in charge of (or, if they have more than one role placed on them, multiple replication, albeit, independently of one another). Some of these servers hold forest-wide operations master roles and others hold domain-wide operations master roles.

The Windows 2000 Active Directory design supports multimaster replication of the Active Directory domain database partition between all domain controllers in the domain. This basically means that you can make changes to the domain database partition at any given domain controller, such as functions at a user level like changing your domain password all the way up to a Domain Administrator adding new users to the domain at a remote site by hitting the local domain controller at that site.

[NOTES FROM THE FIELD] - Back in the NT4 days this was not the case. All changes from user passwords to new user creation happened only on the Primary Domain Controller. This meant that if your headquarters (and PDC) was in England and you were at the New York offices and changed your password, that change had to "travel" back to the PDC in London to take effect. The same would be true if you were a Domain Administrator temporarily working out of the Los Angeles office. You would have to "connect" to the PDC in London to perform the administration.

When you simply logged on to the domain in New York, LA, or wherever, you could authenticate against the Backup Domain Controller, which held a read-only Accounts database. The read-only database allowed the remote people to log on using it rather than requiring them to hit the PDC.

Other types of changes are impractical to perform in multimaster fashion, such as those to the Schema and Configuration Partitions. Since these partitions and other types of changes are too sensitive to be done in a multimaster fashion, specific domain controllers are assigned to handle these operations. Since these specific domain controllers handle these particular functions (sometimes referred to as single-master operations), these are the only places within the domain or forest where the copies of these databases are read/write. Everywhere else any copy of these databases reside, it is a read-only copy.

[NOTES FROM THE FIELD] - The read-only database copies of the Schema and Configuration partition operate just like the old domain (SAM) data did under NT4.

Any changes to the SAM database in NT4 had to go to the PDC. Any changes that need to be made to the Schema, for example, go to the Schema Master.


This article was originally published on Jun 20, 2002
Page 1 of 3

Thanks for your registration, follow us on our social networks to keep up-to-date