For many of us that have been in our industry for a long time there are a good number of horror stories from days gone by when we did in-place upgrades for NT3, NT4, and then Windows Server 2000.
Our last one was over ten years ago and we plan on keeping it that way.
Why?
Because whatever line of reasoning draws one to the conclusion that an in-place upgrade is the best option is flawed at best.
There is _absolutely no way_ to account for the unknown setting or configuration sitting in that existing OS that will rear its head post-upgrade to bite us and bite hard.
- Microsoft Support KB2775484 Unable to convert to Server with a GUI from Server Core on an upgraded Windows Server 2012 machine
- Three registry settings left over from the upgrade put a full-stop to the requested change.
Now, the above is but one example of something hidden that jumps out to cause a problem. Unfortunately, as much as Microsoft and others have run through various scenarios for in-place upgrades one cannot account for changes made to the source server especially in the SMB space.
So, what do we recommend doing?
SwingIT (www.sbsmigration.com) for a DC that requires the destination to hold the same name as the source.
Using Swing we can end up with a freshly installed Windows Server 2012 DC that has the same name as the original server.
With most of our clients having some headroom on their servers we can also migrate AD to a new DC very simply then detach that VHD and attach it to the newly configured DC VM.
Now, when it comes to an application server such as a Remote Desktop Services delivering desktop and RemoteApp sessions there is most certainly the possibility to hold onto that setup and do an in-place upgrade.
However, starting with a freshly installed operating system we do not inherit all of the bloat that comes with OS age (patching for one) plus it gives us the opportunity to evaluate what applications are relevant and which ones can be deprecated.
Starting fresh also gives us the opportunity to purge all former user profiles on the existing server.
In the end just like anything else we evaluate the risks of any procedure. In our case we will be watching out for the in-place upgrade problems and forum posts about things having gone awry for now.
IMNSHO, in-place upgrade should be the absolutely last option considered or tossed off the table altogether.
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book
No comments:
Post a Comment