Upgrading a DC in place from Server 2008 R2 to Server 2012 R2

Question

This is not a question but more of an information post. I've found lots of posts regarding the upgrade of a DC and most say that you should do a clean install and migrate services and then decommission the old server. But I was more interested in an in-place
upgrade of a DC. I only found one post on here that said it was possible, so I gave it a try and it worked perfectly.
Here's what I've got and what I did:
Server 2008 R2 Std (Virtual Server using VMWare)
AD, DHCP, DNS, Certificate Services, Office KMS Host
I did the whole adprep /forestprep /domainprep routine and then installed Server 2012 R2. I selected the upgrade option and then sat back and watched the process. It took about 30 minutes to complete. Once it had installed, I logged in and the only issue
I noticed was that one service hadn't started, and this was just due to the OS waiting to be activated. Once I had done that there were no more errors/issues.
For the Office KMS server I then had to install the new version of KMS host as this has changed for 2012, and this is quite a simple task too. The only issue I have is waiting for the minimum of 5 PC's to activate...

Answer 1

Yes. That is of course a different situation. however, I would still not do it for acouple of reasons, which may or may not apply to you.
I work in a controlled environment (regulatory requirements) and for any change we need QA approval. Allowed downtime is very low. preparing a new DC and then swapping it out means far less downtime and much easier to manage from a QA perspective. Especially
since you can do a lot of acceptance testing up front.
Upgrades always carry the risk of certain things being reset, or changed unknowningly. Scratch installs are always the same. The possibility that after the QA release something may not work as expected can create a huge problem for me. We always prepare
and test installation procedures up front.
That's why we always try to follow best practices and procedures that allow as much pre-configuration as possible, and which allows us to fall back to existing configuration. Timeslots for downtime come around only once per year. And if it causes more than
a couple of hours downtime, only once every couple of years. the amount of sitewide effort involved and the financial risks are massive.
Basically it all boils down to this: is it a problem for you if somethign unexpected happens, do you have the possibility (time) to do much troubleshooting or the time needed to restore backups, and how acceptable is the risk of not being able to finalize
the proposed changes.
When there are millions of $$ on the line and a schedule slip could cost further hundreds of thousands of dollars ... , and aborting the site upgrade would be a huge failure for the site ... you want stability, predictability, and as few changes
as possible where you don't know the success in advance.