Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

This weekend we replaced a Windows server of a few years old, with a new one. Despite having imported computers and users from Active Directory on the old, to the new server (with loss of password, but that is not very important), and the whole experience was close to a nightmare.

The PCs were not recognized by the server, people could not log in (something about "computer not in security database of server"? I forgot the exact wording.). We had to:

  1. Remove each PC from the domain by adding it to a workgroup instead (on the PC, not on the server)
  2. Add the PC back to the domain, and restart it
  3. For Windows 7, it also required that we removed the old entry for that computer from the Active Directory on the server, or we'd get a conflict that the computer name was already in use. (For XP that was apparently not necessary.)

That's not the end of it: when the user logged in a new profile was generated on the PC, complete with new settings and a new "my documents" folder, with loss of (Outlook) email as a result.

Trying to Google for this problem, the only solution we found was precisely what we did. Which is just way too impractical.

Okay, because we have more server upgrades planned, I have to ask: did we overlook something? Is there an approach that we can take, preferably on the server itself, so all users can still just log in from their PC (possibly with a temporary password), and retain all their personal data (settings, my documents, ...) that was stored on it?

p.s. The old server was Windows Server 2003, the new one is Windows Server 2008 (upgraded to R2), if that makes a difference.

share|improve this question

3 Answers 3

You absolutely overlooked something. You should have added your new server as an additional domain controller to your old domain, then switched over DNS, then demoted the old one. Your AD would have been up throughout the transition, and you user database (including passwords and everything else) would still be alive. I would very much recommend that you read up on Active Directory before your next transition.

Oh, and you wouldn't even have to touch your computers, as long as they got IPs from a DHCP service.

share|improve this answer
    
Additional DC, not secondary. That died years ago, while I was still at school in fact! I went and changed that for you. –  Ben Pilbrow Jul 13 '11 at 17:17

As Trondh stated in his answer, if you would have installed and promoted an additional DC/DNS server you would have avoided all of the problems that you encountered.

I'm leaving out the specifics of the migration that you would have needed to address, such as DHCP, File and Print services, Schema update, etc. but the long and short of it is that adding an additional DC/DNS server would have saved you a lot of time, sweat, and user unhappiness.

share|improve this answer
    
Do not forget to add you need to move FSMO roles to new server before demoting the old server and ensure the roles have moved successfully. –  xeon Jul 13 '11 at 17:32
1  
The process of demoting the FSMO role holder will move the FSMO roles to the remaining DC automatically, there's nothing that needs to be done manually. –  joeqwerty Jul 13 '11 at 17:35
    
I did not know that. But I still would rather do it manually to ensure it moved properly and is stable. –  xeon Jul 13 '11 at 17:38

I'm a bit curious as to what would make someone think that this approach would work. There certainly is no documentation or procedures that I am aware of that would recommend this approach. If there is any takeaway from this, it could serve as a cautionary tale. Even with zero knowledge, only a few simple tests would have confirmed that the new server was not working as expected and the backout should have been initiated.

There are two basic approaches. Depending on the role, you can add the server as an additional server, move roles and functions to that server over time, and have a final cutover where the remaining data and functions are moved. Even in this scenario, you should not blaze the old server straight away. Rather, unplug the old server network cable and monitor for at least two weeks to see if anything breaks. Depending on the role or other server products, this may not be a valid approach for all functions or roles.

Another approach is to make a Windows backup of the old server and restore it to the new hardware. Some server roles (such as domain controllers) require extra steps, to ensure that the symbolic link/junction that is created for sysvol is working, however most of this can be sorted out during the validation phase. Products that have license compliance enforcement may require new license keys if it detects the hardware has changed. If there is a lot of data to restore, there could be an initial restore on one day, and on another day, perform a delta copy/backup and restore to the new server. I have successfully performed several hundred server replacements this way, including physical to virtual and virtual to physical, and to dissimilar hardware.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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