Upgrade WinSrv2012 Hyper-V failover cluster straight to WinSrv2019

Environment:  
Windows Server 2012 (non-R2) Hyper-V Failover Cluster
--four host node servers
--iSCSI cluster shared volumes (NetApp SAN)
--four VLANs
--80 hosted VMs

Goal:  
Upgrade the failover cluster to Windows Server 2019.

Info:  
We're aware of the need to evict one or more nodes to build a "new" cluster with WinSrv2019, then connect the storage and "swing" the VMs over (a procedure no longer needed when upgrading a WinSrv2012-R2 or later cluster).

Questions:
--Can we perform the old-school "evict & build new" steps to upgrade straight to Windows Server 2019?  
--Or, is it advised to first upgrade from 2012 to 2012-R2, then perform rolling upgrades to 2019?
--If we upgrade straight to 2019, are there any known issues or "gotchas" to watch out for due to skipping 2012-R2 and/or 2016?
--Are there any documentation or white papers for upgrading from 2012 (non-R2) failover clustering straight to 2016/2019?  (Finding the docs just for 2012-2012R2 are difficult as it is.)

More info available upon request.  Thanks in advance for assistance.

Dimarc67
Frederick, MD
LVL 4
Dimarc67Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dimarc67Author Commented:
Looks like I found Microsoft's doc for our specific scenario.  The example they give is specifically upgrading a failover cluster from 2012 to 2019.

Upgrading Failover Clusters on the same hardware
https://docs.microsoft.com/en-us/windows-server/failover-clustering/upgrade-option-same-hardware

For the record, they specify creating the new cluster as 2016, then upgrading the rest to 2019, finishing with the first node.
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
Cluster Rolling Upgrade would be the option but it requires 2012 R2 as the minimum starting place.

So, the next option is to do the following:
 + Live migrate all VMs to Nodes 1 & 2
 + Flatten nodes 3 & 4
 + Install Server 2019 edition needed & configure
 + Configure SAN Storage for new cluster nodes
 ++ Can either be existing LUNs or set up dedicated LUNs for the new cluster
 + Shared Nothing Live Migrate VMs to new cluster & storage (if needed)
 + Flatten Nodes 1 & 2
 + Install OS and configure
 + Join the existing cluster one at a time
 ++ Test Live Migration and Storage Migration in between each

Make sure all workloads are backed up prior to running the above operation.

Benefit: Gives a completely fresh install.
Coolie SheppardSystems EngineerCommented:
I created a step by step article on how to do this which can be done over RDP or on site.  This is important especially if you have teamed networks which will break when upgrading.

Your only path to upgrade to 2019 from 2012 is to go to 2016 if you have a cluster you don't want to shut down.

See below:

https://www.experts-exchange.com/articles/33515/Upgrading-Windows-2012-R2-Failover-Cluster-with-Teaming-to-Windows-2019-over-RDP.html
Dimarc67Author Commented:
Thanks for responses.  As I mentioned, I located Microsoft's documentation specific to our implementation scenario:

Upgrading Failover Clusters on the same hardware
https://docs.microsoft.com/en-us/windows-server/failover-clustering/upgrade-option-same-hardware

The given example is specifically for upgrading a failover cluster from 2012 to 2019, and directly answers my original question (must install 2016 on the first node of the new cluster).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
In-place upgrade is okay for most things, currently not domain controllers, but it is not something we would do for cluster nodes. There have been enough Microsoft KBs out since in-place became a part of the deployment scope for Windows Server that we still don't do it in those environments.

The principle thing to keep in mind is in the drivers. Make sure they are up to date as is the firmware on the various components in each node. So long as the hardware is not too old you should be okay. But, given the FROM version and the TO version I'm not sure things will go as planned.

Please make sure to have a known good backup.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2019

From novice to tech pro — start learning today.