I had an interesting experience today. Without boring you with the details let's
just say I'm no richer for the experience save for providing the catalyst for
the following instructional tidbit. The
catalyst in this case was a question posed to me. I was asked what the difference was between a
Role and a Feature when configuring a Windows server.
Now most of you who have any experience at all in Windows
Administration may not necessarily be comfortable with the concepts of Server
Roles and Features. It's been a slow but
steady evolution from an abstract label to a shortcut in Server Manager.
Since Windows 2000's introduction of Active Directory, the
concept of a server role took on new meaning.
Instead of being limited to just designating a server as a Primary or
Backup Domain controller now we had multiple roles that made the old labels
moot.
Yeah, I'm talking about the most confusing collection of
server "Roles" ever introduced to the Windows Universe, the FSMO or
Flexible Single Master Operation. 5
labels that have confused Windows Administrators for a decade.
I mean, the PDC
emulator is fairly intuitive, for example.
We know what that's for right?
Well only partially because that role handles a lot more than just Primary Domain Controller services for Windows NT (non AD) networks. It also provides Time synchronization, Group
Policy replication, and account lockout and password change services for an
entire windows domain. If the server
that holds this role fails you're going to have a very bad day until you move
it to another server.
Relative ID master? All that does is keep all the names on your
network unique. It's function is to keep
combining computer or user object Identifiers (SIDS) with a pool of unique
Identifiers managed by this role (RID)
Combining the two values ensures that no two objects on an AD network
are alike even if everything else about them is the same. The RID master can't allow its pool of RIDS
to go empty or it won't have anything to combine with the new SIDS that come
from a new user or computer account.
Yeah, that's real obvious.
How about the Infrastructure
Master? It's a role and its function
is... uhh...Oh yeah, it makes sure that if someone from one domain gets rights
to something in another domain their specific information is recognized
properly. How come such a serious
sounding name for such a tiny function that's so rarely used? Whatever..
Those three roles are considered the "Domain"
roles in Active Directory networks. That
means they only affect the immediate domain they serve. There are two other roles that are considered
Forest or Enterprise level roles. That
means they live at the top of your AD network above all the domains (assuming
there's more than 1) that branch off of the "trunk" of your
"forest".
In case all this talk of Directories and Forests is
confusing try a different metaphor.
Think of AD in the context of a Phone Book instead of a forest. You usually have one Phone book for a town
and it contains all the names and numbers of the people with phones. Those names and numbers can be thought of as
domains.
Now say your aunt Bessie changes her phone number. The phone book is going to need to be updated
to reflect the change or she'll be very lonely because nobody will be able to call
her anymore. That would be sad for Aunt
Bessie and nobody wants that!
If the phone company decides to change the area code for
your town then all the people listed in the phone book have to tell their out of
state relatives what the new area code is or they won't be able to call them
anymore. Changing the area code, by the
way, would be considered an enterprise event to the people listed in the
phone book. So would changing the name of
the town by the way.
It's the concept of changing names within an organization
that leads us to the first of the two "Forest" or "Enterprise"
level roles in Active Directory.
Coincidentally, it's called the Domain
Naming Master and the simplest way to explain its role is to refer back to
our theoretical phone book.
Remember when Aunt Bessie changed her number? Well she's a spry old gal and decided to get hitched up to a nice older gent. That meant her last name changed. To make sure everyone can find the happy newlyweds we'll need to get the phone book entry updated. To accomplish that, she had to call the phone
company and ask them to change it. The
phone company is responsible for changing Bessie's name in the phone book and they are the
only ones that could do it. If the phone
company is closed nothing changes just as no domain names throughout the
enterprise can change if the Domain Naming Master goes offline.
The second and final enterprise FSMO role is easier to
understand since its name is a little more descriptive than the others. It's the Schema
Master and if you have any experience with databases its function will be
instantly recognizable. If you remember
that all the information in Active Directory is stored in a database then you
know that something has to control the way its organized. That's the function of the Schema Master
along with copying (replicating) any changes that occur to the Schema to the
rest of the Enterprise.
Going back to the phone book example, the Schema Master would
be the guy who decides how the phone book is going to be organized. Will it be sorted by name or phone number? How
much information will each listing contain?
These questions are all answered by the guy printing the phone
book. He is the Schema Master.
Ok maybe not so dramatic but the Schema Master is an
important Role. Without it Active
Directory couldn't exist.
I've actually went a bit deeper into FSMO roles than I
planned but it's important information.
It's also important to know how Microsoft tends to overload their
terminology.
In the previous discussion I've laid out what Microsoft
defines as a "Role" in the context of functions that support Active
Directory. There's another definition of
a server role, however, that has nothing to do with supporting Windows but
rather defines services for users.
You may have noticed that I haven't said much about "Features"
to this point. That has everything to do
with Microsoft's overloaded terminology again.
In the context of an FSMO role a feature is nothing more than a facility
for management of a given role.
In the context of a Server Role, however, features become
very important. A Server Role in Windows
2000 and later is designated set of services that support user
activities. Examples are File and Print
services, Application Server and DNS Server roles. Each of these roles is task based defining a
set of services to be offered to users by the server.
Server Roles can be viewed more as containers than
mechanisms. They are comprised of
programs and services tailored to the support of the role. Features are usually the programs and
services that provide the functionality of the role. Think of it as the option list on a new car.
A new car has one role, to provide transportation. It's price, however, is dependent on the
number of features it has. A base model
won't have as many amenities but will still satisfy the core requirement to provide
transportation. Many times you can
specify additional equipment to tailor its function to better match your needs. This affords additional functionality or
"Features" without affecting the core requirement of providing
transportation.
It's really that simple.
Roles define a task and features support it.
That's about enough, I really don't want to write the word
"Role" anymore..
:-)
