I wanted to ask if there a good reason to do a clean install of Windows Server 2012 and redo my configurations (a lot of hassel and hours of work) or just go with the straight upgrade of my Windows Server 2008 R2 machine. Are there any pitfalls or limitations anyone has encountered I should be aware of? Please advice.

closed as not constructive by Sven, Bryan, Michael Hampton, Ward, jscott Dec 13 '12 at 3:28

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • should ask what roles are installed? – tony roth Dec 12 '12 at 16:11

Most people that perform clean installs have good reasons for doing so. Over the years, issues can develop, and starting with a known good configuration is one way to leave issues behind. It also facilitates a much quicker final cutover during transition of roles.

Turning up a replacement server with a clean install and moving the role(s) over to that server is very common in large organizations. The only time in recent memory when we performed an in-place upgrade was to replace standard edition with enterprise because the server was setup with an incorrect image, and we did not have time to re-provision.

Small businesses with limited resources may not have a separate server to move to, or the time, expertise and documented configuration to perform this type of clean transition.

The main caveat you may encounter is if the upgrade goes sideways, and you cannot resolve the issues, do you have a functional backout? That typically means restoring at a minimum the System/boot partition and System State. If you have not done that or are uneasy about it, the risk exposure of an in-place upgrade is very high. One way to mitigate that risk is to P2V the server to a VM, and attempt to perform the in-place upgrade there before attempting the upgrade on the real server, and also test the backup restore of the System partition and System State on the VM. Another risk mitigation may be to perform a local backup to a reasonably fast USB hard drive just before the upgrade. That usually facilitates the quickest possible restore.

  • +1 for the backout plan - if this goes pear shaped, how do you get back to a working state? – Driftpeasant Dec 12 '12 at 15:36
  • yea run disk2vhd on the root partition, then to test things prior to the upgrade create a new vm without a network connection and boot this vm, obviously it will complain about running a hypervisor within a hypervisor but if it boots you are good to go. if a fall back is required just configure the server to native boot the vhd file you just created. – tony roth Dec 12 '12 at 15:48
  • forget the part about running a hypervisor within a hypervisor if you are not running hyper-v, don't know why I assumed you were running hyper-v. – tony roth Dec 12 '12 at 15:57

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