Jason Zandri’s latest article in the Learn Active Directory Design and Administration in 15 Minutes a Week series presents a more detailed breakdown of the Domain Naming Master Flexible Single Masters of Operation Domain Controller.
Welcome to the 15th 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 begin the more detailed discussion of the Windows 2000 Active Directory Single Masters of
Operation. This particular article is going to be a more detailed breakdown of the Domain Naming Master Flexible Single
Masters of Operation Domain Controller.
[NOTES FROM THE FIELD] – Some of the sections
below are a recap from my
Active Directory Single Masters of Operation article. It
does seem like overkill to a degree to include four
paragraphs from that column here, but rather than have the
reader go back and forth for reference, I have included only the
most important sections here.
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.