In the previous article, we looked at some of the common problems that can popup during In-Place upgrades to Windows Server 2012 R2. More specifically, issues relating to WSUS, MMC snap-ins, and the Windows Firewall were discussed. In Part 2 of the article, we are going to take a look at several other Windows Server aberrations to be watchful of while performing in-place server upgrades. Let’s begin!
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).
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.
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.
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…
If you 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
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.