Forum Discussion
Is there on the internet any article explain the result of FSMO roles owner duplication
The article below is a reasonable overview from both the theoretical and practical standpoints on why former FSMO role holders must not be re-introduced as-is into Active Directory.
It outlines or infers the issues you can encounter for the PDC and RID master, though it should be obvious why the functionality provided by each of the five cannot and must not be duplicated, which is why any domain controller that has had its FSMO role(s) must not be brought back online as-is.
The section entitled "Considerations when repairing or removing previous role holders" discusses how to return a failed domain controller to service, but it essentially comes down to wiping, rebuilding and then re-promoting it - so the same steps as if it were new.
Transfer or seize FSMO roles - Windows Server | Microsoft Docs
The second article (below) is important when reviewing the placement (relevant when seizing) of the infrastructure master, as the red breakout warning box from the first article doesn't provide an additional but very important caveat (which the second article does):
If all the DCs in a domain also host the global catalog, all the DCs have the current data. It isn't important which DC holds the infrastructure master role.
Many ankle biters today won't really understand the infrastructure master callout (from the first article) or the important caveat (quoted above from the second article) but it was an important decision pre Windows 2003. The quote above (i.e. where all domain controllers host the global catalog) applies to so many customer environments today (in my experience, at least) that I haven't come across an example of where placement matters in well over a decade.
You can readily search for and find technical articles outlining FSMO seizure-related issues but the reductionist version is "because Microsoft said so". If you do otherwise, you're in unsupported territory, and in business language, that's an unacceptable outcome. So, you don't even need to turn this into a technical discussion since I can't imagine any business deliberately seeking to become unsupported - that's just bonkers.
Cheers,
Lain
But in some cases, the server is fixed and brought online which causes a duplication/conflict of FSMO roles.
This should never be attempted. There's no reason for it.
Also, there are several cases on the internet for ppl has similar issues and looking to recover, as one server crashed and was brought online by mistake after the roles are seized.
The article below is a reasonable overview from both the theoretical and practical standpoints on why former FSMO role holders must not be re-introduced as-is into Active Directory.
It outlines or infers the issues you can encounter for the PDC and RID master, though it should be obvious why the functionality provided by each of the five cannot and must not be duplicated, which is why any domain controller that has had its FSMO role(s) must not be brought back online as-is.
The section entitled "Considerations when repairing or removing previous role holders" discusses how to return a failed domain controller to service, but it essentially comes down to wiping, rebuilding and then re-promoting it - so the same steps as if it were new.
Transfer or seize FSMO roles - Windows Server | Microsoft Docs
The second article (below) is important when reviewing the placement (relevant when seizing) of the infrastructure master, as the red breakout warning box from the first article doesn't provide an additional but very important caveat (which the second article does):
If all the DCs in a domain also host the global catalog, all the DCs have the current data. It isn't important which DC holds the infrastructure master role.
Many ankle biters today won't really understand the infrastructure master callout (from the first article) or the important caveat (quoted above from the second article) but it was an important decision pre Windows 2003. The quote above (i.e. where all domain controllers host the global catalog) applies to so many customer environments today (in my experience, at least) that I haven't come across an example of where placement matters in well over a decade.
You can readily search for and find technical articles outlining FSMO seizure-related issues but the reductionist version is "because Microsoft said so". If you do otherwise, you're in unsupported territory, and in business language, that's an unacceptable outcome. So, you don't even need to turn this into a technical discussion since I can't imagine any business deliberately seeking to become unsupported - that's just bonkers.
Cheers,
Lain
Thanks for your comment.
It's totally known in the entire community it's not supported and very bad practice to have duplicated roles.
I guess I will do it in a lab and see what will crash and how it impact the lap environment.
I understand your curiosity but there's really no benefit to doing so. As Dave Patrick already said above: one should never attempt to bring a former FSMO role holder back online.
Seizing a role is a final admission of defeat where the the former FSMO holder should either be rebuilt from scratch (most likely course of action) or permanently left offline.
For the sake of education, here's some additional information.
If you do not have replication islands, you will find the former FSMO role holder once started will identify that it is a duplicate, will report as much in event viewer and then cease to act in that role. However, as there is no coming back from this status, you're back to rebuilding.
The more complicated scenario is where it comes up with communications issues causing a replication island and believes it it still the role holder (i.e. at least one inbound partner can still talk to it - again, this is covered in the article.) Things start getting truly ugly with the PDC and RID masters at this point. It's no better for the remaining three roles, however, as they change infrequently, they can be less disruptive.
As the linked articles discuss the PDC and RID master issues, I won't go into depth, but in short:
- RID master: Is particularly bad as you end up with overlapping SID values being issued to new objects. Recovering from this is not trivial and almost guaranteed as disruptive to users (depending on how long the defunct RID master is online for);
- PDC master: Is disruptive to everyone - including end users - almost as soon as you fire it up, as you end up with orphaned password resets, lockouts, etc. which need to be reconciled when the former PDC role holder is finally evicted by the administrator.
There is zero reason to try and navigate these issues (has always been this way) since the only supported action is to remove then. Even if you enumerate all the symptoms like event IDs and so on, you're still back to removing the broken FSMO host from existence.
Cheers,
Lain
looking to recover, as one server crashed and was brought online by mistake after the roles are seized.
I'd suggest taking it offline ASAP