FSMO back ground

(AD) is a directory service created by Microsoft, and it comes as a set of processes and services in most versions of Windows Server operating systems.

You can imagine AD as a database or a safe location that stores all the attributes of your users such as usernames, passwords, and more. This central repository automates many tasks such as management of user data, provision of security, and inter-operations with other directories.

In the initial versions of AD, there were many chances for conflicts. For example, let’s say, a domain controller added a new employee to the database. Since the change was made to the AD, it was reflected throughout the enterprise, and that’s fine. A few seconds later, another domain controller wanted to delete the records of employees who no longer worked in the enterprise. Accidentally, it deleted this employee from the AD as well.

The conflict management system that existed then followed the “last writer wins” policy, so the change made by the second domain controller was valid while the change made by the first domain controller was discarded. This means, the new employee was no longer in the system and couldn’t access the system’s resources, which is obviously not right.

To prevent such conflicts, a single-master model was introduced. In this model, only one domain controller (DC) could perform a particular type of update. In the above case, if only the first DC was in charge of adding and removing employees and the second DC was in charge of security, then such a conflict wouldn’t have occurred.

However, this came with limitations too. What happens when the first DC goes down? You can’t add or delete employees until it comes back up again. Such heavy dependence on a single controller is never good from an operational standpoint.

So, Microsoft went a little further in subsequent versions to include multiple roles for each DC and to give each DC the ability to transfer the entire role to any other DC within the same enterprise. The obvious advantage here is no role is bound to any particular DC, so when one goes down, you can automatically transfer this role to another working DC