Forum Discussion
Is there on the internet any article explain the result of FSMO roles owner duplication
Hi
usually when an AD Server crash admins seize the roles on one server to the other, and the dead server is literally dead and won't come to life.
But in some cases, the server is fixed and brought online which causes a duplication/conflict of FSMO roles.
What I am looking for is the impact of having a duplicate of each role on the infra and how to recover.
Is there any document on the internet that goes into detail about this ?!!
Thanks
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
6 Replies
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.
- I know, but this helps in understanding the possible issues of having such conflict.
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
