Here we go for the next free Active Directory
training video for the 70-640 course. In this video I will look at the five operation
master roles that are found in Active Directory. Active Directory is a multi-master replication
system but some operations are best performed on one server at a time. By having
these operations performed in one place at a time allows one server to be responsible
for these changes. Having the operation only on the one server ensures that when an operation
is performed the result is consistent across all the Active Directory databases and also
eliminates the possibility of replication conflicts.
In Active Directory there are 5 operational master roles otherwise known as FSMO roles.
FSMO stands for flexible single master operation. Some of these master roles work on the whole
forest and others work at the domain level. You are free to move these operational master
roles from one domain controller to anther domain controller. When deciding which domain
controllers these roles should be on it is important to ensure that they are available
when required. If an operational master role is not available, certain Active Directory
operations can fail. Depending on the operational role it
will affect either a single domain or the entire forest. I will start with the forest
wide roles which there are two. The first role is the schema master. The schema
master contains the layout or structure of all the data in the Active Directory database.
For example, a user account by default can include information such as the persons job
title and phones numbers. If for example you wanted
to add a person pay grade, you could change the schema to include this information.
Some software such as exchange will expand the
schema to fit more information in. Making changes to the schema is a very important
decision because once you add additional attributes or objects to the Active Directory database
they cannot be removed. Since the schema defines the Active Directory
database across a forest there is only ever one schema operation role per forest. If the
server with the schema role is not present then you cannot make changes to Active Directory
schema. If you want to test changes to the schema before trying them in your production
environment you would first create a new forest in a test environment. If you want to make
schema changes in an environment with multiple forests you would need to make changes to
all the schema masters in all the different forests. Once a change is made on the domain
controller holding the scheme master role, the scheme master is responsible for ensuring
that this change is replicated to the other domain controllers.
The next forest wide operational master role is the domain naming master. The domain naming
master is used whenever you add a domain or remove a domain from a forest. The domain
naming master ensures that two domains are not added with the same name. If the domain
naming master is not available, you will not be able to add or remove any domains in the
forest. Once again, this role is only on one domain
controller in the forest. Due the scheme master and domain naming master not being used very
often, Microsoft recommend both of these roles be stored on the same server for ease of administration.
The last 3 operational master roles are domain wide. For each domain in your forest you will
have 3 of these operational master roles. The first of these 3 operational master roles
is the RID master. The RID master, RID standing for relative identifiers is responsible for
allocating RID Pools. These RID pools are essentially a lot of sequential numbers used
in a SID's. Every object in Active Directory has a SID
or security identifier associated with it. This SID is basically a unique number which
Active Directory uses to identify the object. Every user account will have a SID and also
a user name associated with it. The user name is used by us humans as it is easy for us
to remember, the SID is used by Windows as computers work better with numbers.
Since Active Directory user accounts primary work against a SID, this is why you can easily
change a user name and not have to change any of the permissions assigned to that user.
Any file that has permissions assigned to that user will be referenced back to that
SID. When a username changes, Windows will simply display the new username that is associated
with that SID. If you delete a user or an object in Active Directory that SID is lost.
Even if you straight away create a new user account with the same name the SID will be
different and thus the new user account will not have any of the access that the old user
account had. The RID master gives out relative ID's
which are part of the SID. To demonstrate how the
RID forms part of a SID I will open a command prompt on my domain controller. From the command
prompt I will run a query that will show all the user Sid's in my domain. Since
this is a new domain there aren't too many
users created as yet.
Notice that all the SID's listed here have
a number appended on the end starting from 500. This is the relative ID. The relative
ID is a sequence of numbers that is allocated by the RID master. Having said this, the RID
master gives out RID's in blocks. For this reason, you don't need a super fast connection
back to the RID master. Also a domain controller will request more relative ID's from
the RID master before it runs out. If the RID
master is down for a little while it should not have an impact on your organization. Having
said this, you would want to make sure the outages are small as if the RID mater is down
and your servers run out of relative ID's no new objects in Active Directory can be
created. Keep RID master availability in mind if you have a need to create a lot of active
directory objects at once. For example, if you need to create a large amount of users
accounts at once. You don't want your domain
controller to run out of relative ID's half
way through the process of creating a large amount of users and the RID master is not
contactable. The next domain wide role is the
PDC emualtor. The PDC emulator or primary domain controller emulator was originally
put in place to provide a bridge between windows 2000 domain controllers and windows NT domain
controllers. In a Windows NT domain, changes could only be made on the primary domain controller.
When you upgraded a domain from windows NT to a Windows 2000 domain, any Windows NT domain
controllers left in the domain could only communicate with PDC emulator.
Back in those days it was a very important role. Now days, it is unlikely that you will
have any windows NT domain controllers and in fact windows NT domain controller are not
supported when you install a windows server 2008 domain controller. Even though the need
of the PDC emulators is depreciated, it still does perform some important tasks in your
domain. The first task that the PDC eliminator is
responsible for is keeping the time accurate in the domain. Usually you would ensure your
PDC emulator is syncing it time with an official external time source. These official external
time sources are very accurate as they usually use an atomic clock to keep time. Atomic clocks
are the most accurate clock every build. Microsoft keeps a list of trusted external time clocks
on their web site. It is best to use the closest of these official time sources to your site
to keep your PDC emulator time accurate. The other domain controllers in the domain
will sync their time off the PDC emulator. The clients on the network will in turn will sync
their time from their local domain controller. For this reason it is important to ensure
that the clock on your PDC eliminator is as accurate as possible as all other computers
in your domain will directly or indirectly get there time from it.
The next task the PDC emulator performs is when a password is changed in the domain.
When a password is changed, the password is replicated to the PDC using urgent replication.
This means the PDC emulator is considered the most up to date source of password changes.
For this reason, if an incorrect password is given to a domain controller, the domain
controller can contact the PDC emulator who will have the finally say if that user is
allowed on the network with that password. If you are using distributed file system or
DFS the PDC emulator plays and important part in keeping DFS up to date and consistent.
When changes are made to DFS these changes are made on the PDC emulator. If this causes
to much load which can occur on large DFS implications, this can be disabled so the
PDC emulator is not required to make DFS changes. Lastly, when you modify group policy, the
group policy editor will automatically default to the PDC emulator and make the changes there.
You can change this and use a different domain controller, but it is important to understand
that this is the default location. The idea being the changes are made on the PDC emulator
and replicated out to the other domain controllers. Keep this in mind if you have just changed
group policy and the change does not seem to have taken effect. To speed up the process
you may need to perform a manual replication or change the group policy editor to a different
domain controller to make changes. The last of the five roles is the Infrastructure
master role. This role is important for keeping changes in object references consistent across
domains. It does things such as track object moves, renames and deletes across domains.
It also updates multi domain references in active directory when changes occur.
If you are using a single forest with a single domain the following does not apply. If you
are using multiple domains you need to consider the following when placing your Infrastructure
master. In a multi domain environment, the Infrastructure
master updates references to multi domain objects when changes occur. If the domain
controller holding the Infrastructure master role is a global catalog server this can cause
problems. This occurs because when the Infrastructure master finds a change it refers to the local
global catalog which will always be up to date. Since the Infrastructure master thinks
the change and already been made it will not notify any other domain controllers a change
has occurred. To fix the problem, ensure that all domain
controllers in the forest are global catalog servers so they always have up to date changes.
If you can't do this, make sure the Infrastructure master is not a global catalog server. Remember
that if you are using a single forest and a single domain you don't need to worry
about this. This problem only occurs in a multi domain environment.
This concludes how the 5 operations master roles work in active directory. In the next
video I will look at how you can move these roles around from domain controller to domain
controller. Thanks for watching are always free training videos.
