You will all have heard about rolling cluster upgrades from Windows Server 202 R2 to Windows Server 2016 by now. The best and recommend practice is to do a clean install of any node you want to move to Windows Server 2016. However an in place upgrade does work. Actually it works better then ever before. I’m not recommending this for production but I did do a bunch just to see how the experience was and if that experience was consistent. I was actually pleasantly surprised and it saved me some time in the lab.
Today, if you want to you can upgrade your Windows Server 2012 R2 hosts in the cluster to Windows Server 2016.
The main things to watch out for are that all the VMs on that host have to be migrated to another node or be shut down.
You can not have teamed NICs on the host. Most often these will be used for a vSwitch, so it’s smart and prudent to note down the vSwitch (or vSwitches) name and remove them before removing the NIC team. After you’ve upgraded the node you can recreate the NIC team and the vSwitch(es).
Note that you don’t even have to evict the node from the cluster anymore to perform the upgrade.
I have successfully upgrade 4 cluster this way. One was based on PC hardware but the other ones where:
- DELL R610 2 node cluster with shared SAS storage (MD3200).
- Dell R720 2 node cluster with Compellent SAN (and ancient 4Gbps Emulex and QLogic FC HBAs)
- Dell R730 3 node cluster with Compellent SAN (8Gbps Emulex HBAs)
Naturally all these servers were rocking the most current firmware and drives as possible. After the upgrades I upgraded the NIC drivers (Mellanox, Intel) and the FC drivers ‘(Emulex) to be at their supported vendors drivers. I also made sure they got all the available updates before moving on with these lab clusters.
Issues I noticed:
- The most common issue I saw was that the Hyper-V manager GUI was not functional and I could not connect to the host. The fix was easy: uninstall Hyper-V and re-install it. This requires a few reboots. Other than that it went incredibly well.
- Another issue I’ve seen with upgrade was that the netlogon service was set to manual which caused various issues with authentication but which is easily fixed. This has also been reported here. Microsoft is aware of this bug and a fixed is being worked on.
When you do an in place upgrade of a Hyper-V virtual machine you’ll get a warning that Microsoft Hyper-V S3 Cap may not work after the upgrade and that you need to update the driver prior to the upgrade.This warning is logged to the Windows Compatibility Report.htm.
Microsoft Hyper-V S3 Cap is an old S3 Trio 765 emulated video device and the driver isn’t included anymore so you’ll get this particular warning. This will never give you an issues, all drivers needed are indeed in the install bits. You can safely ignore this and successfully upgrade.
Some people uninstall the device via device manager but basically that’s pure cosmetics & doesn’t really serve a purpose.
This warning is an artifact of the generation 1 virtual machines who still have this device on a PCI bus. Below is a screenshot of a VM with W2K12R2, generation 1. As you can see the Microsoft Hyper-V S3 Cap is perfectly fine. No worries.
As a matter of fact you will not even see this device on a generation 2 virtual machine and we should not see this with an upgrade of those.
I will have to wait on a public preview of Windows vNext to test an upgrade of a generation 2 machine to prove my thinking that this cosmetic error won’t be there anymore.
I recently did an in place upgrade of my Windows Server 2012 iSCSI Target host in my home lab to Windows Server 2012 R2 Preview. That went well for one “minor” issue. My iSCSI initiators could not connect to it anymore and where in perpetual “connecting mode”.
On the target the status remained in “Not Connected” for all the VHDs.
As you can imagine this sort of ruins the share storage experience on my test Hyper-V cluster. After checking the basics and the event logs I found nothing wrong with the iSCSI Target. It’s then that I turned to the firewall as I suspected that we could have an issue there. Sure enough, the inbound iSCSI rules on the target had not been enabled.
After taking care of that the iSCSI connections succeeded and live was good again in the home lab. You only need to enable the iSCSI target rules.
When doing an in place upgrade of Windows server 2012 to Windows Server 2012 R2 Preview you hit the following error:
There is not even a compatibility report generated. We have enough free space, no error events are logged except for this one in C:$WINDOWS.~BTSourcesPanther setuperr.logerror log that just mentions Error [0x0807a7] MIG Callback_CreateCompatibilityReport failed[gle=0x00000490]
The trick to deal with this is by not getting install updates online when offered as option in installation wizard.
Otherwise it downloads some bits and then creation of the compatibility report fails. I owe a big thank you to fellow MVP Tomica Kaniski for this tip. I saved me some trouble shooting & time.
My guess is Microsoft will soon have this fixed.
Anyway, now all physical hosts in my home lab are running Windows Server 2012 R2 Preview. We refer to this in our group as having seen the fish .