Welcome back to your free Active Directory training course. This video will look at the
placement for operation master roles and global catalog servers in your organization. First
of all I will look at operational master role placement.
When you install your first domain controller in your first forest all the operational master
roles are going to be on this server. Also the first domain controller in the domain
is automatically made a global catalog server. On any reasonably sized network, it is more
than likely there will be more than one domain controller on the network for redundancy.
Without a second domain controller, if the first domain controller were to fail then no
one would be able to log on to the network. Unless moved by an administrator, notice that
when the second domain controller was added to the network the operation master role stayed
on the first domain controller. See the previous video on how to move operation master roles
from domain controller to domain controller. There are a lot of reasons why operation master
roles are moved around the network. Firstly there is availability. Having operation master
roles on different domain controllers means that if the server was to become unavailable
only the roles on that server would become unavailable. This is basically not putting
all your eggs in the one basket. When choosing which domain controllers to
put which operation master roles on you should also consider how much load the server is
going to be put under. Some operation master roles put more load on the server then others.
If you have a busy server that handles a lot of authentication requests, it may be best to put
the operational master role on a domain controller that is used less.
First of let’s have a look at the forest wide operation master roles, the schema and
domain naming master roles. The forest wide operation master roles schema
and domain naming master don’t get used that often. It not that they are not important
it is just that if these roles becomes unavailable you would no longer be able to add domains
or change the schema. On some networks these two roles could be off line indefinitely if
the schema was never changed or domains added or removed. If these roles are not available
for a long time you will get an error messages in the event log that these roles are not
available but this will won’t stop your network from running.
Even on a large network, it is doubtful that either schema changes or domain name changes
activities happen very often. For this reason, to make these roles easy to administrator
you can put both these roles on the same server. Since the domain naming master will contact
the global catalog server when adding domains it is a good idea to make the domain controller
that is holding these roles a global catalog all thought it is not necessary.
The other forest wide role is the schema master role which does not require a global catalog
server. For this reason the schema master can be put on any domain controller in your
enterprise. In a multiple domain environment, even though
not required, most administrators will place the schema and domain name master on a domain
controller in the root domain of the forest. Since the schema and domain naming affect
the whole forest it makes sense to keep these roles in the root domain. The root domain
will be the last domain to be removed if you changed your domain name space so placing
forest wide roles in the root space makes sense.
That’s the two forest wide roles covered, now for the domain wide roles the PDC emulator,
infrastructure and RID master. When deciding where to put the PDC emulator
you should considering putting the role on the network that has the most users. This
is because the PDC emulator is the final authority on password based requests and thus
it make sense to put it on the network that has the most authentication requests on it.
It does not matter if the PDC emulator is a global catalog server or not. On a very
busy domain controller holding the PDC emulator, administrators may remove the global catalog
from the domain controller in order to reduce the load. If there are no performance problems
on your domain controller it does not hurt to make this domain controller a global catalog
server. Next you have the RID master. The RID master
allocates blocks of RID’s and thus does not have to be on the fastest link or the
fastest server. Don’t get me wrong, all operation master roles are important so you
should always do you best to run any domain controller on reliable hardware. On a domain
with very few objects being created the RID master could be unavailable at times and no
one would notice. If you have a domain where a lot of objects are being created or you
run a job which creates a lot of Active Directory objects, the RID master becomes very important
and it being down for a period of time will cause certain operations to fail.
The PDC emulator generally uses more RID’s then other domain controllers. For this reason
administrators will often put the RID master on the same domain controller as the PDC
emulator although this in not required. Once again like the PDC emulator, the RID operation
role is not affected if the domain controller is or is not a global catalog server.
The next role is the infrastructure master role. This is used to keep references between
different domains up to date. If there is only one forest and one domain the placement
of the infrastructure master role is not that important since you won’t have any cross
domain objects to keep track of. You can make this domain controller a global catalog server
or leave it as just a domain controller in a single domain environment.
When you have a multi domain environment the infrastructure master roles becomes more important
since there are multi domain objects to keep track of. If you make the domain controller
holding the infrastructure master role a global catalog server problems can occur.
The problem occurs when the infrastructure master attempts to update a cross domain object.
When the infrastructure master is a global catalog server it consults the global catalog
server to see if the object is up to date. The global catalog is always up to date so
the infrastructure master thinks nothing needs to happen which is where the problem comes
in. The role of infrastructure master is to identify
cross domain reference changes and inform other servers on the network about these changes.
When the infrastructure master role is on a global catalog server this may not occur.
This is because it consults the global catalog server which may already have the change in
it. The infrastructure master thinks the change has already been made and ignores the change
not telling any other servers about the change. Microsoft has reported this problem fixed
with Windows Server 2008. The problem can still occur if you have Windows Server 2000
or 2003 domain controllers. The simplest way to fix this is to make all your domain controllers
on the network global catalog servers. By default Windows Server 2008 will make all
new domain controllers global catalog servers. If you can’t make all domain controllers
into global catalog servers, simply ensure the infrastructure master is not a global
catalog server. This will ensure that it will always communicate any reference problems
it finds to other domain controllers. For ease of administration it is easiest to
ensure that all domain controllers are global catalog servers. This won’t affect any operations
in the forest but does have some draw backs. Making all domain controllers global catalog
server does require more bandwidth and hard disk space. Now day’s networks are faster
than they use to be when Windows Server 2000 came out so this may not be problem. If you
don’t want to make all your domain controllers global catalog servers then simply make sure
your infrastructure master is not a global catalog server. Once this is done, you are
free to select or deselect any domain controller to be or not to be a global catalog server.
If you decide not to make all your domain controllers global catalog servers then you
should give some thought to the placement of the global catalog servers. Applications
like exchange make a lot of use of global catalog servers. If the exchange server has
to go over a wide area network to reach a global catalog server this may affect performance.
For this reason if you are using exchange or a product like exchange that makes a lot
of calls to a global catalog server you should have a global catalog server on your local
network. Microsoft recommend global catalog placement
if you have over 100 users in the one location or a location that has a lot of roaming users.
The reason roaming users require a global catalog is when a roaming user logs onto a
network from remote the global catalog server needs to be contacted.
Global catalog servers are used to determine membership when users are in universal groups.
Universal groups are simply groups that can have users from multiple domains in them.
Without access to a global catalog server universal group membership can’t be worked
out and thus the user may not be able to login. Covered in a later video, I look at how at
a feature called universal group caching. This allows previous universal group look
ups to be cached on a domain controller to improve later performance.
Now that you understand about global catalog placement, let’s go to a Windows Server 2008
domain controller and look at how to make it or stop it from being a global catalog
server. First of all, open Active Directory users and
computers from the start menu. From Active Directory Users and computers expand down until
you get to domain controllers. This will show all the computer accounts for all the domain
controllers in the domain. To get to the global catalog settings, right
click the domain controller computer account that you want to change and open its properties.
From here select the button at the bottom NTDS settings. Once you have the NTDS
settings open, tick or un tick the tick boxs global catalog. That’s it, close all
the dialog box and Windows will handle the rest.
You should now have a good understanding of which domain controllers to make global catalog
servers and which domain controllers you should select to hold which roles, but what happens
when the domain controller holding one of these roles is no longer available. A very
bad hardware crash could cause the domain controller that is holding an operation master
role to never be able to be booted up again. So what do you do when this occurs?
In the next video I will look at just that, seizing operation master roles when the domain
controller holding that role is no longer available. Thanks for watching this free video
and please feel free to check out are other free videos from are other free courses. See
you next time.