(2011-07-11) The Impact Of FSMO Roles Not Being Available

AD uses a multi-master replication mechanism, meaning that updates can originate on any RWDC. For all kinds of services AD is highly redundant assuming you have more than one RWDC. Within AD some operations cannot operate using the multi-master principle, but rather use the single-master principle to ensure consistency. The roles for those operations are the so called Flexible Single Masters of Operations (FSMO). From a forest perspective two forest wide FSMO roles exist and from a domain perspective three domain wide FSMO roles exist. Below you will find which one is which.

When FSMOs become unavailable, depending on the scenario you may need to transfer or seize the corresponding FSMO role(s). With regards to FSMO role transfer or seizure, please see "Moving FSMO Roles From One DC To Another DC". After a seizure the old FSMO role owner should never be brought online again. It should at least be force demoted while not connected to the network and its metadata in the AD should be cleaned.

–

For lots of ways to transfer/seize FSMO roles check out: Transferring And Seizing FSMO Roles Through GUI, Command Line Or PowerShell

–

For more information about FSMO roles see "Operations master roles" and "FSMO Roles".

–

In addition to that, 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 I’m 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!.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————