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.
This Wisconsin manufacturer needed to modernize its IT infrastructure to support rapid business growth.
Discover what they didWSUS
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.
MMC
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.
Windows Firewall
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.
NIC card settings
Why on earth this little foible happens, I’ve absolutely no idea. But please, double-check your NIC card settings after an in-place upgrade. There have been numerous times that my Server 2012 R2 upgrades have resulted in the server’s NIC card settings getting changed from using a static IP address to a DHCP address without any explanation as to why. For what it’s worth, I’ve only experienced this problem in a virtual (VMWare) environment so far (although, to be honest, I don’t really manage too many physical servers or Hyper-V virtual machines anymore).
Services
Before upgrading, I always make sure I take a screenshot of all the services and their individual “Startup-Type” that appears in the services.msc applet so I can see whether a service was set for Automatic, Manual, or Disabled. Then I compare the services and their “Startup-Type” before and after the upgrade. Why? Unfortunately, there are times when doing an in-place server upgrade to Windows 2012 R2 will inexplicably set random services as Disabled, even though they were previously set for Automatic before the upgrade. This has happened to services such as:
- Net.Msmq Listener Adapter
- Net.Pipe Listening Adapter
- Net.TCP Listener Service
- Net.TCP Port Sharing Services
- Windows Process Activation Services
- SQL Services
- World Wide Web Services
Furthermore, -please- be aware… Services in Windows 2012 can no longer contain an underscore character (“_”). I learned this the hard way while doing an upgrade on an application server, and a key service for that application just completely disappeared (poof!), resulting in the application a full reinstall after the upgrade.
KMS
If your server is acting as a KMS server, be aware that the KMS services will no longer be functioning properly post-upgrade. You will need to re-enter your KMS keys (using the /IPK parameter) and run the activation (using the /ATO parameter) against those keys. Furthermore, in some cases, you may need to recreate the VLMCS record in DNS as the current VLMCS record may end up getting deleted once its TTL value has expired. Paying attention to those peculiarities will allow your desktops and servers to continue functioning without interruption or warning that they can no longer contact the local KMS licensing server.
Windows updates
You may find that your server will no longer be able to perform Windows Updates after an in-place upgrade to Windows Server 2012 R2. Checking for updates may result in an 8024404C error. Most often this is quickly fixed by running the following command (regardless of whether the updates come from Microsoft or from your local WSUS server)
- Wuauclt /detectnow
- Wuauclt /resetauthorization /detectnow
- Wuauclt /reportnow
Reclaiming disk space
You can delete the Windows.old directory on your system partition after the upgrade. However, you will not be able to delete the folder completely without first taking complete ownership of the Windows.old folder and all its subfolders, and then applying Full Control permissions at the NTFS level for your Administrator account to the Windows.old folder and all its’ subfolders. At least it’s an easy fix…
Management Agents
If your server is not virtualized (believe it or not, there are still a few of those floating around here and there!), you will very likely want to re-install, or update, the HP/Dell Management Agents. In the case of HP servers, that means, updating the following software:
- System Management Homepage
- WBEM Providers
- Insight Manager Agents
- Integrated Management Log Viewer
Conclusion
For the most part, those are the stumbling blocks I’ve come across during my in-place Windows Server 2012 R2 upgrades. None of them are too critical or destructive, although some are more than others obviously, so long as you’re adequately prepared to deal with them if the issues arise. As with any upgrade, please be sure you take appropriate data backups, bare metal recovery backups, snapshots, etc. using whatever backup application you choose to rely on, BEFORE you start the in-place upgrade process. It very well may save your bacon and countless hours of rebuilding a botched upgrade.
