lets discuss what happens when a specific FSMO is not online/available:

Schema Master/FSMO unavailable: this is not visible to users directly as users do not
need it. Only admins need this FSMO to extend the AD schema. When not available
you cannot extend the AD schema to support your custom extensions or other
extensions to support other (Microsoft) products (e.g. Exchange, OCS/Lync, etc).
These activities are not done on a day to day basis, so relatively speaking it is not
critical when not available.

Domain Naming Master/FSMO unavailable: this not visible to users directly as users
do not need it. Only admins need this FSMO to add new partitions/naming contexts
(e.g. AD domains, application partitions) and cross-references to other partitions
outside the AD forest. When not available you cannot do what I mentioned earlier.
These activities are not done on a day to day basis, so relatively speaking it is not
critical when not available.

Infrastructure Master/FSMO unavailable: this may not be visible to users directly as

users or admins. Only admins may need to execute ADPREP (during AD upgrades) or
migrate objects between AD domains (intra-forest migrations only). The
infrastructure master (IM) keeps placeholder objects (so called phantoms) used in
references up-to-date. The following only applies to objects within the same AD
forest. For example, if a group in domain A contains a user from domain B. The IM will
create a placeholder object (a phantom) in domain A that represents the user from
domain B, but only if the IM is not a GC. The DC with the IM FSMO should not be a GC
if there is at least ANOTHER DC in the same AD domain that is ALSO NOT a GC. The
IM also keeps the phantom object up-to-date within information from the real object
(e.g. distinguishedName, objectGUID, objectSid). The IM is also used by ADPREP to
perform actions against domain NCs and application NCs. And if Im not mistaken, the
IM is also used for intra-forest migrations of objects (I need to blog about this!). Also
see "The Infrastructure Master FSMO And The GC Role" and "Phantoms,
tombstones and the infrastructure master". Remember that when the Recycle
Bin is enabled in a W2K8R2 AD, every DC becomes an infrastructure master. In that
last case the regular IM FSMO becomes unimportant. In a single domain AD forest,
the IM is also less important as it does not need to update phantoms and you cannot
perform an intra-forest migration as you only have one AD domain.

RID Master/FSMO unavailable: this is not visible to users directly as users do not need
it. Only admins and provisioning systems need this FSMO to be available to be able to
created security principals (groups, computers, users). In time, every RWDC (RODCs
do not!) has two RID pools, the current RID pool and the reserve RID pool and each is
a block of 500 RIDs. When the current RID pool is exhausted, the DC copies the value
of the reserve RID pool to the current RID pool. When the current RID pool is
exhausted for at least 50%, the RWDC requests a new RID pool from the RID FSMO
and stores the value in the reserve RID pool, etc., etc. When the RID FSMO is not
available, RWDCs cannot request RID pools. You can still create security principals on
a RWDC as long as its RID pools are not fully exhausted. When the RID pools are fully
exhausted on any RWDC, you can still use any other RWDC as long as its RID pools
are not fully exhausted. When the RID pools of all RWDCS in the AD domain are fully
exhausted. Did you know that the domain RID pool is limited? If you did not, it
actually is! The top limit is "1073741823" (over 1 billion RIDs!). Also see " RID Master
FSMO Explained".

PDC Master/FSMO unavailable: the RWDC with the PDC FSMO role is the most busy
FSMO as it performs all kinds of functions. This is actually also the FSMO role that will
 impact users most. The PDC FSMO performs the following functions: [1] act as the
central time sync authority within an AD forest (this only applies to the PDC FSMO in
the forest root AD domain). For this also see "Configuring And Managing The
Windows Time Service (Part 1)", "Configuring And Managing The Windows
Time Service (Part 2)", "Configuring And Managing The Windows Time
Service (Part 3)" and "Configuring And Managing The Windows Time Service
(Part 4)", [2] Any password changes or account lockouts that occur on any DC are
communicated to the RWDC with the PDC FSMO over the secure channel directly, [3]
When a logon is attempted against a RWDC that fails (because of an incorrect
password), that RWDC will check with the RWDC hosting the PDC FSMO if it has a
newer password, [4] Editing GPOs by default occur against the RWDC with the PDC
FSMO, [5] When root scalability mode is not enabled (the default), DFS root servers
get updates from the RWDC with the PDC FSMO. When root scalability is enabled, DFS
root servers get updates from the closest DC instead, [5] The PDC FSMO is the only
DC that applies the Password policy settings and the account lockout policy settings
specified at domain level and writes the information to the domain NC, [6] The
AdminSDHolder process is not executed to check protected groups/users and
reconfigure the ACLs if needed, [7] If you have NT style applications that want/need
to target the PDC, those apps will probably break as soon as the PDC is not available.

For more information about FSMO failures, see "Responding to operations master
failures"

So, the most critical FSMO would be the PDC FSMO!

TIP: If you want to shut down a RWDC that hosts any FSMO role, as a safe measure you
might want to consider to temporarily transfer the FSMO role to another RWDC until the
original RWDC is back up and running. At that time, you can transfer the FSMO role(s) back.
This is safer, then for whatever reason having the need to seize the FSMO role(s) because
the original RWDC dropped dead!.

What to do with FSMO roles...

 Brian Puhl

7 Dec 2005 8:45 PM

7
We recently hired a new engineer to a team which manages some of the internal MS environments...
We were discussing FSMO role placement and he sent me mail (snippet below slightly edited) which I
thought was interesting...

The reason why we separated the roles at my last company was due to the FSMO role seizure process. You are correct,
although the server is still a single point of failure, we can mitigate this single point of failure by placing the forest roles on
one box and the domain roles on another. In the event that we unexpectedly lose a DC that is either a forest or domain
FSMO role holder, the process of seizing the roles is minimized (less roles to seize). Also, it had been our experience that
the forest roles aren't really used that often. You are correct, FSMO roles are still a single point of failure, however, unless
we really need to perform any forest related stuff, the single point of failure (from a forest FSMO perspective) is a non-
issue. This is not the case with the domain FSMO roles, specifically the PDCE. At my last company, we felt that due to the
PDCE functions it was necessary to place the domain FSMO roles on a separate box...

I wanted to share this, because it reminded me of a FSMO related interview question which I've used in
some variation or another:

Suppose you're paged in the middle of the night and told that one of the 150 domain controllers in your single domain
forest crashed. You're first thought is likely "So what, I'll deal with it in the morning." but then you remember it's the
one holding all 5 FSMO roles. If you could only pick one FSMO role to sieze, which one would let you go back to sleep
without worrying about the next day?

There are many people that I've asked this question to...the large majority of who answered, "The Schema Master, because
without the schema the AD can't function."... Hopefully they aren't reading this blog from their whichever other job they
landed...

So back to the the whole FSMO single-point of failure and redundancy thing...

I figured there were 2 possible reasons that they arrived at the idea that seperating FSMO roles based
on forest/domain division was logical:

1. There was some sort of fault tolerance between FSMO roles which could be preserved in a
failure

2. There was some urgency (specifically user impact) to getting a role holder back online
immediately should a failure occur

The first reason is obviously false. FSMO is the "Flexible Single Master Operations" with the emphasis
on "single"...the whole point of these roles was that even though Active Directory is a distributed
system, there were just some things that could only be done in one place at a time. So let's just take
the generally accepted knowledge that each FSMO role provides specific functionality which only exists
in that role.

The second reason takes a bit more thought, but what really happens when a FSMO role holder fails?
Looking at each role, what the impact of it being offline is, and the urgency:

Schema Master Schema updates are not available These are generally planned changes, and the
first step when doing a schema change is normally something like "make sure your environment is
healthy". There isn't any urgency if the schema master fails, having it offline is largely irrelevant until
you want to make a schema change.
Domain Naming Master No new domains or application partitions can be added This sort of falls
into the same "healthy environment" bucket as the schema master. I don't know of anyone who has
just randomly decided to add a new domain to a forest without much thought or planning...of course,
then again, I don't know all that many people either... You might wonder why I mentioned app
partitions there as well...personal experience. When we upgraded the first DC to a beta Server 2003
OS which included the code to create the DNS application partitions, we couldn't figure why they
weren't instantiated...until we realized that the server hosting the DNM was offline (being upgraded) at
the same time. Sure enough, it came online and there they were... But I've never said we were
perfect here...

Infrastructure Master No cross domain updates, can't run any domain preps Domain preps are
planned (again)...But no cross-domain updates. Hmmm...that could be important if you have a multi-
domain environment with a lot of changes occurring...but wait...the IM tasks are throttled to run over a
2 day period (by default), so how much urgency does that really imply? I guess you'd have to call it as
you see it in your environment but it's probably not 3am urgency...for my buddy the new engineer,
he's only working in single domain forests anyways, so urgency = zero.

RID Master New RID pools unable to be issued to DC's This gets a bit more complicated, but let
me see if I can make it easy. Every DC is initially issued 500 RID's. When it gets down to 50% (250) it
requests a second pool of RID's from the RID master. So when the RID master goes offline, every DC
has anywhere between 250 and 750 RIDs available (depending on whether it's hit 50% and received
the new pool). So the urgency question is how long will it take your environment to exhaust the RIDs
on a given DC? My guess is that in most environments, this isn't that urgent either. Oh yeah, and
don't forget that if you do seize the RID master during a failure...that's an automatic flatten and rebuild
of the server, you can't bring it back online.

PDC Time, logins, pw changes, trusts So we made it to the bottom of the list, and by this point
you've figured that the PDC has to be the most urgent FSMO role holder to get back online...the rest of
them can be offline for varying amounts of time with no impact at all...so what about this one? Yes,
you should get the PDC back online whenever you can but it's not even something that I'd jump out of
bed to do...let's call it the "first thing in the morning" list. Time synch's are important, but w32time
does a pretty good job and nothings going to diverge between today and tomorrow enough to impact
you...users may see funky behavior if they changed their password, but replication will probably have
completed before they call the help desk so nothing to worry about, and trust go back to that whole
"healthy forest" thing again... The biggest impact we see internally at Microsoft from the PDC being
offline are all of the applications which were written in NT4.0 timeframe that are biased towards it.
Now that's something to consider.

So when it really comes down to it, is there any benefit to seperating the forest and domain roles onto
seperate servers? Probably not...is there any harm in it? Nahh...let's just chalk it up to "operational
preference" since the guys who are watching this stuff day to day need to be comfortable with the way
the environments are configured.

Pop Quiz Time:

Raise your hand, if when your phone rings in the middle of the night and you get that call...you
transfer the PDC role and go back to sleep...

...

...
now keep your hand in the air if you reconfigured the server that you transferred the role to, to also be
authoritative for time? I think I found a topic for my next blog...

If I don't see you before then, Merry Christmas, Happy Holidays...or like that commercial says, Merry
Chrismahanakwanzaka.