Windows Server 2019 in place upgrade testing
In theory in place upgrade testing is easy. You just validate Microsoft’s efforts and testing that went into the process. If it succeeds all is well. Well, not really. The amount of permutations in real life are so large it can never be done for all of them. But even today in this era of “services as cattle” they have a role to play. I would say, even more than before. That means that Windows Server 2019 in place upgrade testing is also important.
In place upgrade paths to Windows Server 2019
In-place upgrade allows an administrator to upgrade an existing installation of Windows Server to a newer version, retaining settings and installed features.
The following (Long Term Service Branch) LTSC versions and editions of Windows Server with their supported path for in-place upgrade are shown below:
Please note that when you are performing cluster operating system rolling upgrades this can only be done from N-1 to N. This means that you can only do those from Windows Server 2016 to Windows Server 2019.
The ability to perform cluster operating system rolling upgrades is just one benefit you get by keeping your environment current.
Conclusion
Currently Myself and a couple of fellow MVPs are busy doing some testing on “real” hardware. That means servers, the kind you’d use in a professional environment, not the PC lab. Testing on virtual machines rocks and those are heavily used in real life, but you can’t test everything you need to verify hardware deployments. Think about S2D, Persistent Memory, SET, vRSS/VMQ/VMMQ etc.
Part of that testing is in place upgrades. Yes, there are times and places when I will avoid them, there are also moments where I leverage them. I do think they are important and they have their place. Doing them depends on the value it can offer.
Whatever you do, you test, you verify and your break stuff in the lab before casually on a Monday morning upgrading a cluster to a new version of the Operating System. I hope I don’t need explain this anymore anno 2018? Or actually I do, we always have new talent join us and we all have to learn. So big tip, learning on the job doesn’t always equal learning in production. That will happen anyway, but don’t default to it.
You wrote out what paths are working for in-place upgrading, does this apply regardless to server core/GUI etc?
You may be better aware (than me and my google search) about a link that show all server 2016 roles which can be directly upgraded to new server 2019? For example AD-FS, Direct Access or IS role…
I’m running a win2012R2 to win2019 upgrade. After running for about 4 hours, the “Installing Windows Server 2019” is sitting at 20%. The disk read is very low and the CPU usage for SetupHost.exe is pegged at 99%.
I can’t imagine exactly what it needs to process. The only thing on this server is a couple of MySQL/Postgresql databases and a website in inetpub/wwwroot. That’s it.
I am experiencing a similar issue with a 2012 R2 to 2019 upgrade. It is taking forever. It’s been running for approximately 3 hours and I’m currently at 16%. Anyone know the expected upgrade time?
Hard to say, if you can stick with it and see what happens … it might pull through but I have seen anything between 1-5 hours. single vCPU VMs can take a while on slow storage.
QUick Update: After approximately 8 hours, the upgrade completed successfully. Network settings were a bit messed up but that was a quick fix. Otherwise, all seems good with the 2012 R2 to 2019 upgrade.
Good to hear and thx for sharing. Normally from Windows Server 2016 to 2019 the Network upgrade experience has improved a lot, very happy with that.
I am attempting to run an in-place upgrade form 2012r2 to 2019 using SCCM. For some reason it keeps failing and I am at a loss as to what is causing it. I have verified the Network Access Account in SCCM as well as updated the server with the latest patches. The error I am receiving is 0x4005(16389). Thoughts?
i have 2012 r2 std, but i can not upgrade to 2019 std desktop experience, because the setup say that the version is not the same.
is it because is an evaluation copy?
Probably, if the source is an evaluation edition try an upgrade with Windows Server 2019 Evaluation edition to see if that helps.
Hello, I performed an in-place upgrade from Windows Server 2012R2 to Windows Server 2019, as well as SQL Server 2012 to SQL Server 2019 running on the same box/s.. All went well. All Running in VSphere..
I upgraded 20+ Servers running mostly SAP ECC and Portal, and a few IIS and FTP Servers. The Windows in-place upgrade took approx 30 min to run, and the SQL upgrade took approx 10 min.
The whole process for each Server took a few hours with snapshots, SAP specific steps, and other steps install SQL Mgnt Tools, .etc..
We’ve been running the In-Place Upgraded 2019 Servers in Production for approx 2 months with no issues..
Just wondered if you had any documentation around your processes. My organization has 800+ servers, and 500+ need moved off 2012r2. +/- 80% the 500 will be side-by-side. I personally have 44 that will all be in-place upgrade of 2012r2 Standard to 2019 Standard. 37 that should be fairly simple as they are just SCCM Secondary boxes with SQL express. I do have servers that have SQL 2012 install locally and are central/primary servers (along with proxy MP’s and CMG).
I will be opening an advisory case with Microsoft but would like to gather idea from others to make sure I ask the right questions going forward. Just looking for anything specific you had related to OS and SQL upgrades of the same box.
Thanks!
Brian
Do test migrations per workload (role\features) to figure out what are the things that need fixing pre- and post-upgrade. Then automate the upgrades where feasible. Plan for some servers that will fail to upgrade. See f that is fixable or requires a swing migration. With virtual machineS, checkpoints are your friend! You can do SQL upgrade pre or post OS upgrade, depending on whether the SQL version is supported on the OS. In place, SQL upgrades might require a bit of housekeeping afterward.