Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a Win2003R2 server that is intermittently crashing after some virus were introduced. I'm sure all virus have been cleaned thanks to Malwarebytes (were using McAfee - useless).

When it crashes you can't login (local or remote) but can still access files remotely and ping it. After a while even file sharing stops and have to kill power to restart it (no BSOD)

I need to either fix it (tried to reinstall SP2 and I tried to reinstall windows in repair mode but the repair option was not available when I booted from installation disks) or move it's functionality to another DC (another 2003R2 server).

The server that's crashing is old with SCSI drives while the new server uses SATA drives and faster so it seems like a good idea to just transfer roles and ditch the old box. Finding replacement SCSI drives looks expensive if they ever fail.

What would I need to transfer roles. If I just move the 5 FSMO roles and copy over the file shares. Would the new server have enough to run without the old server?

Never done something like this, just want some tips.


share|improve this question

closed as not a real question by MDMarra, Ward, John Gardeniers, Iain Sep 30 '12 at 7:08

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

There is just so much wrong with all of this. – MDMarra Sep 30 '12 at 0:05
"Never done something like this, just want some tips" - Last time I heard this, I ended up taking over after a few hours, doing serious disaster recovery. You need to educate yourself before taking any action. – Mathias R. Jessen Sep 30 '12 at 0:19
That's the point of this post...educate me. – user1305332 Sep 30 '12 at 0:33
The position you are in requires someone who knows what he/she is doing. You are very clearly not that person, so I suggest you hire someone with the appropriate skill set. Please read the FAQ and you will understand why this question will very soon be closed. – John Gardeniers Sep 30 '12 at 3:53
This is just such a disaster and there's just so much wrong in your post, that the only thing "some tips" or a little education are going to do is enable you to turn this into a much bigger mess. (A little knowledge being a dangerous thing and all.) At this point, you could probably find a good consultant to fix this for you in a few hours and several hundred dollars. Once you try to fix it and mangle your domain, it's going to take much longer and much more money to fix. – HopelessN00b Sep 30 '12 at 7:34

There is indeed a procedure for transfering a DC to a new machine, or retiring a DC.

  1. DCPromo up another domain controller if one does not exist. Ensure it is fully functional. If it already exists and you're just retiring the dying one, skip to step 3.
  2. Wait while everything settles. Don't get impatient. Impatience kills.
  3. While the dying DC is still up, transfer any FSMO roles to other domain controllers.
  4. Audit your DHCP configs to be sure the dying DC is not being supplied as a DNS server for clients.
    • If so, change the DHCP config and wait until the clients have cycled their leases. Not doing so will lead to extended resolution times and calls to their handy helper person wondering why things are so slow.
    • If not, carry on.
  5. Evacuate any non-Domain files that may be needed.

At this point the correct action would be to run 'dcpromo' on the faulty DC and demote it. However, it sounds like you can't do that.

However, you may have to follow the offline DC demotion process. It's best to run dcpromo if at all possible, but if you can't:

  1. On a valid DC, open a command-line and run ntdsutil
  2. At the prompt type metadata cleanup.
  3. Then remove selected server deadDC

But read the full KB article I linked for the entire contingency path.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.