There are basically two approaches when it comes to server upgrades for going to Windows Server 2012 R2 – performing an in-place upgrade, or creating a new server and migrating over the applications/data.
While some administrators are adamant that proper server upgrades –must- be done this way, or that way, truthfully, both approaches come with their own share of advantages and disadvantages. Perhaps the biggest advantage of doing an in-place server upgrade is that most upgrades can be completed in a mere two hours or less; which includes not only the upgrade itself, but also the time necessary to install all applicable Windows Updates, post-upgrade. The alternative of creating a new server and migrating over the applications/data, is typically going to take FAR longer to accomplish (but in some cases, may still be the wisest choice!).
Today, we’re going to focus on some of the pesky things that might cause you some grief when doing an in-place upgrade from Windows 2008 R2 to Windows 2012 R2. I’ve probably done about 20 of these in-place upgrades over the last year or two. So far, the vast majority of them are completed with little headache and virtually no post-troubleshooting required. Please note however, IF your server is:
- Bloated with useless and unnecessary software/applications/data… -or-
- Experiencing technical issues or performance problems… -or-
- Is one of those “mystery” servers that hardly anyone knows anything about
…then I’d strongly advise against doing an in-place server upgrade on that server. However, if you believe your server is still a good candidate for an in-place upgrade, here are some important things you should know about BEFORE doing an in-place upgrade in hopes of making your life as an IT administrator easier.
If the server you’re planning on doing an in-place upgrade directly to Windows Server 2012 R2, and the server is currently running the WSUS (Windows Server Update Service) role version 3.2 (Windows 2008 R2 and earlier), you MUST uninstall the WSUS role before upgrading. If you do not, your WSUS installation will be completely broken afterwards and there is no known fix from Microsoft. The only known resolution is to format the drive and reinstall the operating system from scratch. Not fun. I learned that one the hard way on my first upgrade.
In some unexplained cases, certain MMC snap-ins will be broken post-upgrade. This has happened to me on occasion for the File Server Resource Manager MMC snap-in, and the Network Policy Server MMC snap-in (Figure 1).
The generic error message received will usually be “MMC could not create the snap-in”. This issue can be easily fixed by uninstalling the role, rebooting your server, and reinstalling the server.
The configuration settings you previously had for that server role will NOT be lost however. When uninstalling and reinstalling FSRM, you still retain your quota templates as well as folder/user quotas that had been defined. When uninstalling and reinstalling NPS, the policy settings and RADIUS clients you had configured will also remain and won’t be lost.
If you typically turn off the Windows Firewall services on your server, be aware that after an in-place server upgrade, you may suddenly find that the Windows Firewall services are now enabled and therefore blocking specific applications from properly running on your server. This doesn’t seem to happen every time you perform an in-place upgrade, but it’s happened enough for me to take note of it during my routine post-installation checks.
In a couple days, I will post up Part 2 for this article, where we will continue to identify more of those pesky quirks and gotchas that often make our lives as network or server administrators rather frustrating, often leading to us endlessly searching Google for resolution to these irritating and nonsensical post-upgrade problems.
The quirks of Windows Server 2012 r2 in-place upgrades: part 2