I wanted to keep the environment running, so i created a second DC (this time virtualized) and transferred all roles accept the Schema Master role. Than due to all sorts off reasons i didnt get arround to move the schema master role, untill eventually the hard disk crashed and i was forced to seize the Shema master role.
Open a remote desktop connect to a server (does not need to be a DC), and open the command prompt.
Type to followuing:
NTDSUTIL
Roles -lets you manage FSMO roles, this way you can transfer them or seize them.
Conections -You need to connect to the DC where you want to move or seize the roles to.
Even if you are logged on to the dc where you want to move the roles to, you still need to make the connection.
Connect to server %Servername% -If successfully you will see that you are connect to the DC with logged on credentials. So make sure that the account used has enough rights to manage these roles.
Quit -Which returns you to the Roles menu.
Seize Schema Master -Now a warning is displayed, asking you if you are sure to move the Schema master rules to the connected DC. Seizing roles should only be performed as a last option.
In my case i got an access denied. Checked my account and saw it was not part of the Schema admin group. Added myself and tried again. Which failed again. Descided to relog as it could be that the Session granting ticket needed to be renewed. After relogging, i was able to successfully seize the schema master to the conected domain controller.
The red part shows you that NTDSUTIL will first try to move the role, before eventually seizing the role.
the blue part shows all the knows (belonging) roles on the connected domaion controller.
Which was all 5 in my case. Remember that the server where you seized the roles from, can never be brought online again. If for some miraclous reason the disk would turn up oke, you'll need to format that disk and install a fresh OS.
can never be brought online at all? or as a domain controller? what if i get the disk to work but demote it before putting it back on the domain?
ReplyDeleteDemoting and a metadata clean-up is sufficient. But in no way may the revived domain controller be able to comunicate with an existing DC aslong as the revived server has not been demoted, and the metadata has been cleaned.
ReplyDeleteOfficial documentation:
A domain controller whose FSMO roles have been seized should not be permitted to communicate with existing domain controllers in the forest. In this scenario, you should either format the hard disk and reinstall the operating system on such domain controllers or forcibly demote such domain controllers on a private network and then remove their metadata on a surviving domain controller in the forest by using the ntdsutil /metadata cleanup command. The risk of introducing a former FSMO role holder whose role has been seized into the forest is that the original role holder may continue to operate as before until it inbound-replicates knowledge of the role seizure. Known risks of two domain controllers owning the same FSMO roles include creating security principals that have overlapping RID pools, and other problems.