each one of them fails then below are the effects of the same:-
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. 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. Infrastructure Master - No cross domain updates, can't run any domain preps - Domain preps are planned (again). But no cross-domain updates. That could be important if you have a multi-domain environment with a lot of changes occurring.
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).
PDC - Time, logins, password 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. 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.
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. 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. Infrastructure Master - No cross domain updates, can't run any domain preps - Domain preps are planned (again). But no cross-domain updates. That could be important if you have a multi-domain environment with a lot of changes occurring.
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).
PDC - Time, logins, password 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. 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.
No comments:
Post a Comment