One of our (now ex) technicians mistakenly renamed a workstation the exact same name as our DC that holds FSMO roles. Then, realizing his mistake, renamed the PC. The result is our DC was renamed in AD Users and Computers but the DC still has the old name. When we try to log into the DC we predictably get the message “The security database on the server does not have a computer account for this workstation trust relationship”. I read through many articles about the error but this exact situation seems unique to us.
So far to remedy the situation we have taken these steps: Changed the renamed DC attributes in AD to the old name (GUIDS still won't match); logged on to another DC and seized the FSMO roles; powered down the renamed DC; removed all DNS entries; added the IP address to a spare NIC in the new FSMO role holder; altered the settings in DNS to allow DNS queries on the new FSMO holder (so machines looking for a DNS server would be routed to one able to handle the request).
My question is threefold: (1) did we shoot ourselves in the foot by having another DC seize the FSMO roles?; (2) is there any way to salvage the renamed DC without a complete rebuild? (3) If we do need to rebuild the server what steps, outside of deleting the orphaned DC attributes from AD, do we need to take?
Any insight will be appreciated.