DC fsmo role issue
-
A customers FSMO role holder DC (DC-A) was infected with ransomware. However, the best back up they have is 1 month old from Windows Server Backup. The problem is that prior to infection there was some FSMO role organizing as DC-A was holding "most" of the FSMO roles, except the Schema and Infrastructure, which was held by DC-B. 3 Weeks ago those 2 roles were transferred from DC-B to DC-A, so all the FSMO roles could be held by 1 DC (DC-A). The problem is since DC-A has been restored back to the state it was a month ago, it now thinks DC-B is holding the Schema and Infrastructure role and DC-B thinks DC-A is holding those roles. How should I go about correcting this? Should I seize the roles from another DC? There's a total of 7 DC's, 1 in each of the 7 branch offices.
-
Alas, I don't have experience with transferring or seizing FSMO roles, but here's a thought that might spur better ideas. Was DC-A offering services other than AD and DNS? Perhaps it's worth taking it offline, having another DC seize the roles, make a new domain controller for DC-A and just let AD replicate.
-
Yeah. This type of scenario and even worse ones are why seizing FSMO roles is a thing. In this situation, you should have just chalked up the infected DC-A as a complete loss (in terms of AD) and just seized the roles on DC-B. Restoring a DC would only be done if all DCs were wiped out.
-
After seizing the roles on DC-B, you could then remove DC-A from AD, DNS, etc (if it is an older version, you would have to do metadata cleanup in ADSIedit). Afterward, you could add a new server, promote it to a DC and be back up and running.
-
@wrx7m said in DC fsmo role issue:
Yeah. This type of scenario and even worse ones are why seizing FSMO roles is a thing. In this situation, you should have just chalked up the infected DC-A as a complete loss (in terms of AD) and just seized the roles on DC-B. Restoring a DC would only be done if all DCs were wiped out.
Agreed. Restoring a DC (especially FSMO role holder) back that far is just asking for trouble.
I would seize the roles on whatever DC you want to hold your forest roles. Pick any one you like. After that, go through DNS and start removing anything with that old server. Might have to look for it in ADSI Edit as well, if it no longer exists in Active Directory.
-
@bbigford said in DC fsmo role issue:
@wrx7m said in DC fsmo role issue:
Yeah. This type of scenario and even worse ones are why seizing FSMO roles is a thing. In this situation, you should have just chalked up the infected DC-A as a complete loss (in terms of AD) and just seized the roles on DC-B. Restoring a DC would only be done if all DCs were wiped out.
Agreed. Restoring a DC (especially FSMO role holder) back that far is just asking for trouble.
I would seize the roles on whatever DC you want to hold your forest roles. Pick any one you like. After that, go through DNS and start removing anything with that old server. Might have to look for it in ADSI Edit as well, if it no longer exists in Active Directory.
Yes, that’s true and also avoid any USN rollbacks.
-
Thanks everyone. I did put DC-A offline and seized the roles to 2012 DC (newer). Theres a total of 7 DC. I was able to get one of them to replicate, but it still thinks the “Deleted DC” is holding 4 of the 5 roles, but shows the 2012 DC holding the Domain Naming Role. However, the 2012 DC sees itself as the fsmo holder for all roles. I have not deleted the DC-A from ADSAS yet, only the computer object and dns records.
-
Restoring a DC to a month ago when there were other working controllers was a mistake. because at that point all kinds of things were going to get conflicted.
Restoring a DC is nothing in a SMB with only a single DC.
But you just intentionally broke all the replication.
I honestly have no idea how to fix something this messed up.
-
@jaredbusch said in DC fsmo role issue:
But you just intentionally broke all the replication.
I honestly have no idea how to fix something this messed up.
Wasn't intentionally, but definitely a lesson learned.
-
@wrx7m said in DC fsmo role issue:
After seizing the roles on DC-B, you could then remove DC-A from AD, DNS, etc (if it is an older version, you would have to do metadata cleanup in ADSIedit). Afterward, you could add a new server, promote it to a DC and be back up and running.
The PDC was 2008r2. The new PDC is 2012 standard while other remaining DC is 2008. Does metadata cleanup apply to 2008?
-
-
@fredtx said in DC fsmo role issue:
@wrx7m said in DC fsmo role issue:
After seizing the roles on DC-B, you could then remove DC-A from AD, DNS, etc (if it is an older version, you would have to do metadata cleanup in ADSIedit). Afterward, you could add a new server, promote it to a DC and be back up and running.
The PDC was 2008r2. The new PDC is 2012 standard while other remaining DC is 2008. Does metadata cleanup apply to 2008?
Applies to all the DCs when removed and failing to be removed properly.
-
@jaredbusch said
Restoring a DC is nothing in a SMB with only a single DC.
As has been discussed many times here on ML, it really is so easy, it's a wonder why it isn't done more. (AKA, the single DC route.)
-
@brrabill said in DC fsmo role issue:
@jaredbusch said
Restoring a DC is nothing in a SMB with only a single DC.
As has been discussed many times here on ML, it really is so easy, it's a wonder why it isn't done more. (AKA, the single DC route.)
Wouldn’t users in sites that don’t have a local DC experience performance issues?
-
@fredtx said in DC fsmo role issue:
@brrabill said in DC fsmo role issue:
@jaredbusch said
Restoring a DC is nothing in a SMB with only a single DC.
As has been discussed many times here on ML, it really is so easy, it's a wonder why it isn't done more. (AKA, the single DC route.)
Wouldn’t users in sites that don’t have a local DC experience performance issues?
Not typically, AD does essentially nothing. The amount of time it takes to pass a password around in this day and age is milliseconds. A few milliseconds during a login operation is not something people notice in the least.
