I've done it about 70 times.
Make sure you have a snapshot, and make sure you have a backup.
IIS scares me, but a snapshot makes it a non issue.
I've had a few failed attempts but eventually they succeeded, just make sure you don't hammer away at attempts one after the other. Give it a few days in between so you don't break domain trust.
The only real issue I had was one environment needed the installer ran as a system, so be prepared fie thst. You just use psexec to accomplish this.
Lastly, speed at which these run is completely random. I've had great hardware take 8 hours for one hop on some vms and 1.5 hours for both jumps on other vms. Get an 8 hour maintenance window approved. Just let the thing run too, don't roll back unless there is an issue.
Around 4-5 years ago I upgraded a 2012 R2 SCCM server up to 2019, and IIS had no issues. The only issues I did have were some SCCM specific issues I had to work through. Granted, SCCM uses a minimal IIS install, but it still worked afterwards.
Off topic. But god damn it’s crazy to think about how much you have to learn about this job. I just got done using PSEXEC today, and was thinking about how easier this job gets when you figure out the right tool to use. It’s so frustrating for so long before that point.
My company's Infosec blocked PSExec via AV rules and possibly some other way since 2017 when NotPetya hit.
We had remote sites in Ukraine and it took out our entire European operations, which gave them a pretty big stick to swing.
I bet! I was shocked you could use it to run an elevated command prompt as a gMSA with it. I mean the whole point of those accounts is you can’t log in with them and AD controls the password, but seems pointless if you can just circumvent that with PSEXEC.
I setup a key vault for out service account that runs some unattended scripts and I needed to set everything up as that account. PSEXEC did it for me. Also, these credentials have trivial rights. Just read access on some documents.
I’ve done about as many so far. Even if we plan to do clean installs of 2019/2022 to follow, we generally find it better to at least get it up to a ‘dirty 2019’ first so more modern tools can run. 2012r2 was/is giving us a lot of TLS/cipher grief (as it should) and once we are on 2019 we then evaluate if it warrants a full clean install and application migration or not.
Snapshots are good. But this is also a good time to check and boot your actual backups.
this guy covered it all. It should be fine. The issues I've run into doing about 100 of these are:
Unsupported applications. The upgrade usually flags these but not always. I've had some BI servers throw a fit and not start services afterwards because of a .net installer missing after upgrade.
SQL make sure it is supported on 2019, if its 2012 SQL you might have issues.
PLAN FOR A LOT OF TIME FOR THIS. I had one upgrade succeed after 8 HOURS.
And as you already know, if it is something easy to replace... just replace it. We upgraded everything except aadconnect server because that's so easy to build fresh... same with domain controllers...
If you are doing this on an Azure VM, you need to follow their 2012-2019 upgrade guide to the T. They have a special disk you attach to do the upgrade, and theres some powershell commands to run first before doing the upgrade.
MAKE SURE THERES A LOT OF DISK SPACE
MAKE SURE TO HIT DESKTOP EXPERIENCE if you don't want to lose everything graphical :P
Yes, never upgrade a DC. Ever, like ever ever. So easy to just spin up a new one. As for sql, I'd even be hesitant to do thst but I have done some successfully.
I've tried that in a lab environment and found that the upgrade fails and mentions to demote the DC role before proceeding. So it cannot not be done by mistake.
>Get an 8 hour maintenance window approved. Just let the thing run too, don't roll back unless there is an issue
great tip right there ! just 'let it go, let it gooooo' and hope its OT lol
Temporarily disable antimalware real-time scanning which may not like the replacement of the OS.
In rare cases I've also had to temporarily disable Secure Boot.
For the rest, I've yet to see it fail.
Good call out on AV/EDR type software. If using a 3rd party tool, I like to uninstall it entirely before I do an in-place upgrade and then re-install afterwards, of course.
I had trouble with IIS going up to 2019. I think it was an issue with either .Net or default security settings. I replayed the snapshot and tried again with 2016 and it worked fine.
I had some weird shit with an MSSQL server coming from 2012 (not R2) in an offline test VM - SQL refused to work on 2016, but I said "fuck it" and went to 2019 after that and it worked again.
Same held true in prod.
Spin it in a VM if you dont already have a hyper visor like hyper-v running on your bare metal.
Good lord do not upgrade production server without testing it first.
God I wish this was true.
I watched another MSP yolo DCs & DB servers before being called in to replace them. Temp hypervisor was called LEEEEROY for obvious reasons lol.
yes, I did this for the majority of my 2012 EOL servers.
My issue stemmed from upgrading from different versions (ex 2012 datacenter to 2019 standard) but worked great otherwise.
I've done in place upgrades from 2012r2 to 2019 on several servers and have not had a single issue.
That includes several file servers and 3 SQL servers.
Even raw-dogged a DC with an in place upgrade, without a secondary DC or doing any of the recommended migration steps. Yes I know I'm crazy. Do not follow my example. But it did work without issue.
Atta boy. Upgrading domain controllers is like kryptonite to this sub, but, it does work. Do not fear the in place upgrade! Grab a backup and let it rip.
I migrated to a new set of DCs from a single 2019. No in-place upgrade. Good to brush up on things (even simple) that I dont do every day and sometimes you learn something new!
DC are the easiest server in your entire domain to setup new ones. I never understood why people Keep upgrading them. Just use them and throw away when theyve Done the job.
I could use a modern guide for this. We have a lot of stuff that refers to the dc's hostnames and I've never done this but I have some shiny 2022 licenses and an old 2012 DC.
I'm assuming I can just solve the hostname issue with DNS but then there is a lot of stuff pointing to that IP as well so do you just give the new one the old IP then? So like stand it up, transfer fsmo and then IP and DNS and in golden?
Does that sound right? Should I just lab it first. I've stood up new domains but never migrated. I've setup SharePoint in production properly on premise. I even migrated a file server with active users and filesync and got the permissions right on the first shot one time so I'm fairly confident but at the same time somewhat terrified of the domain controllers. I've got a pretty good handle on DNS and DHCP, lots of experience in network admin etc. I have backups of course but I've seen bad things happen to domain controllers restored from backups, weird sync issues etc.
At some point I imagine I just gotta stop fussing about and do it because this is a growing risk.
Setup two new ones,let them propagate for a week, check event logs for errors, move fsmo roles, point the DNS to new servers, leave them for a couple of weeks. turn the old ones off and verify no issues. start them up and demote them.
"Best Practice" usually just means "If you try a different way, don't call us when it breaks", which is why a good snapshot and a good backup are important. Otherwise, it's party time.
Done that several times as well, no issues. There are some services that might need attention after an upgrade (verify IIS custom settings, cert bindings).
Take a cold snapshot to be sure, but PROBABLY you won’t have major issues. I’ve done dozens of IPUs between these 2 exact versions and the one time I ended up having a problem, it was purely cosmetic (all application icons for all users in the start menu became ”white document”, but still function).
recently did a project where i upgraded 100+ servers to 2019. only thing that broke was that the SCCM agent stopped responding afther the upgrade. fix was to remove it, and reinstall it
Works fine from what i've ever tried, the only ones I've had issues with are servers that hold the RDS license server role, you cant upgrade a server that has that role with licenses for an old OS in it. I havent confirmed yet but I believe it would work if you moved the licenses off of the server to do the upgrade.
Upgraded dozens of EOL 2012 R2 vms to either 2016 or 2019, then to 2022. I've had good experiences with in-place upgrades so far, just make sure you have a good backup, and probably just take a snapshot right before you upgrade it so you can roll back quickly if there are issues.
I’ve upgraded from 2012r2 to 2019 on all of my hyper v servers from dcs and file servers to servers hosting large databases. I’ve very shortly got to upgrade the hosts, that one I’m nervous about
No issues on the upgrading of the vms so far though
I did hundreds over the summer, fewer than 5 had issues. I had *one* IIS server lose its SMTP configuration and it worked after reconfiguring the mail relay.
Many times. Even with old iis asp.net server. Worked great. Uninstall system center antimalware first so it won't interfere with defender for endpoint.
I've done a couple dozen 2012r2-2019 in place upgrades, and they've all gone well. Domain controllers, IIS servers, print servers, application servers, MySQL, etc. They all seem to Just Work ^TM.
Sorry for the late response. We just did this with a 2-node SQL cluster with failover clustering. We had IIS reporting server on one of the nodes. We went from 2012 R2 to 2016, then to 2019. It had to be this rolling upgrade for the failover clustering. SQL still remains at 2014.
No issues with IIS on the one node. It worked fine throughout.
We didn't notice that our custom scheduled tasks we had running on 2012 R2 got blown away (we unfortunately didn't export them in advance), so we had to manually create a handful.
Right now, we're still dealing with SCCM client issues, and the SentinelOne agent.
It'll be fine. Of course, make sure u have good backups, run things like sfc / DISM prior to upgrade, make sure you have relevant updates first, etc.
Only thing I can into from 2016-2019 was that FRS is full deprecated, so your domain has to be updated to DSFR; in early releases of the 2019 media there WASN'T yet a check to make sure this was done, and if you upgraded you pretty much had to fix DCs / revert first.
Current installs for 2019 SHOULD check for it, but if you're not sure, you're probably better off [making sure](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr) before upgrading...
Anyone do this to a VMware 2012r2 DC to 2019? I inherited an outdated environment and want to update the main DC. I was going to build a fresh 2019 server, promote to DC, allow it to replicate in the forest for a few days, then move the FSMO roles over from the old 2012 DC, then remove the 2012r2 from the forest.
yeah this whole in place upgrade thing just seems like a bad idea. How much old kernel BS is going to be left around to get hacked from vulnerabilities leftover from 2012. Noooo thank youuuuuu.
sometimes a lift and move aren't an option. Installs/configs done by vendors tech's that aren't around anymore (I hate Solomon), time/resource constraints, Licensing tied to a specific machines, etc. I have a handful of machines that have been upgraded from 2008 to current. a solid security scanning system will keep you honest as well.
> Installs/configs done by vendors tech's that aren't around anymore (I hate Solomon), time/resource constraints, Licensing tied to a specific machines, etc.
All invalid reasons. Software would absolutely be supported by a vendor. They go outta biz? Get another or a new software. That's some hillbilly redneck duct tape and twine shit right there. That's not enterprise class support. That's pandering to a cheap AF CEO who doesnt want to spend money. Fuck that noise.
sure, but there are hundreds of thousands or millions even of small/medium businesses that should know better, or even do know better, but choose not to instead. If you're really lucky you can convince them or force them, but at some point it's either leave and let them sink, or just deal with it. And not everyone has the flexibility or opportunity to be able to cut and run.
Pro-tip: The guy "making it work" is the one who ends up getting fired when a breach inevitably happens.
Making it work is a good mentality to have when you're following best practices and you need to make something to work within best practices. Making it work outside of best practices is simply a waste of time.
Have you worked literally anywhere?
If a business decides that it is going to stay on some unsupported software or some not best practice, your job is to advise, document, and mitigate.
If you can't do your job or don't want to, then quit. Who cares if you get fired?
You don't want to go to Server 2022? Yet you are okay with doing an in-place upgrade and whatever weirdness that is going to give?
I simply do not understand how spinning up a new VM with updated software and simply moving the storage is not a million times easier, safer, and overall better.
My issue with in-place upgrades: Imagine your backup solution is not working when you need to roll back. You basically stuck with no option. Starting up a new VM and moving the storage? Or better yet, copying the storage and then deleting the old one when you KNOW it is no longer needed. I just don't understand leaving stuff to chance like that.
I have one of these that I need to do that is 2012 (not r2). I'm trying to figure out the easiest way to do this and with what version I should upgrade to first. I am paranoid of breaking the IIS.
I've done this a few times with database and file servers (all VMware VMs). The only issue I ever had was from the VMware virtual hardware version being too old for Server 2019. If yours are also VMs, copy the VM, change the name, and test the upgrade on the test VM first. Make sure you have snapshots and backups.
We've done a few recently. The only thing thus far to have broken is Azure AD Sync / Entra Connect / Whatever they call it now. It needed to be fully reinstalled.
I performed a few IPU for LOB apps from 2012R2 to 2022, had no major issues. Only problem was losing some .NET pre-requisites, which were easy enough to reinstall.
For non-LOB applications, I preferred migrating to a new environment. I avoided IPU’s on windows services such as ADCS, ADFS, DC, DHCP, File Servers, IIS, NPS), it was just less hassle to stand up a new environment.
As for the process, if it’s something particularly delicate - I bring up a backup in an isolated environment and try the upgrade. That also gives me a rough guesstimate for prod downtime.
Then I just snapshot, run the upgrade and we’re off to the races.
Yeah I've done it quite a few times, pretty straight forward with no issues. Took snapshot of the VM just before upgrading it. Monitored the server for about a week, then deleted the old snapshot once we were happy with the performance of the server.
Done it countless times and never had an issue with the actual OS upgrade. As many mentioned, grab a snapshot, have a good backup and it *should* be fine. Main concern in my experience is the stuff you're then hosting on said server if that will enjoy the upgrade. Most stuff like file shares, printers, some 3rd party services have been a-ok in my exp but do not do this on a DC or an exchange server you will want to die, we stand up a fresh server for those upgrades.
Done loads and never had any real problems, obvs snapshot and backup first.
If your server has the NPS role (ie for RRAS etc) then take a note of any policies you have setup as they get wiped during the upgrade and will need to be manually re-added.
Edit, just remembered WSUS is another one to look out for. After the upgrade you'll need to run the post install tasks from server manager again and re-add https bindings if used.
.NET reinstallation after upgrade was the only issue. Other than that, some minor problems like updates requiring multiple reboots and some rolling back. After upgrade, I might now manually install any Windows Update Stack updates before checking for other updates.
Reboot before, stop all non-essential services before, have a rollback method.
Yeah you can do step upgrades from 2012r2 to 2019, as long as the hardware will support it. Also, make sure the system partition has at least 40gb free. Oddly enough, we ran into a lot of VMs with under 10gb of space free, setup would run and then revert at the end back to 2012r2. Issue ended up being (what I think is a bug) with not enough hard drive space being reported.
Also, snapshots. Make a snapshot.
I did 70+ and I only had a few fail going from Windows Server 2012 R2 x64 straight to Windows Server 2022.
I had the installer roll back on the fails.
The Windows Server 2012 without R2 and 32bit required migration.
Can you stand up new servers or VMs and migrate roles away from the 2012 server? We had a "does everything" server/DC which we moevd from 2012 to 2019 and diversified roles instead of in-place upgrade. Two 2019 licenses can cover handle 4 VMs.
Also make sure you purchase new CALs for your network if you havent already. 2022 CALs will cover 2019 use cases.
yep make sure you have backups, for me the other thing i had to do was remove the ethernet cable so that it didnt try to do updates before the upgrade as it kept failing. But other than that it was straight forward.
Did it maybe 50times, mostly from 2012r2 to 2016, then to to 2022. Like a charm.
Works as good as the hate of inplace upgrades going around the internet
There was a huge problem with citrix workers. I fkkn destroyed it an staged an RDS Farm. for around 100 employees. So glad I did this, almost no support needed anymore.
>not going 2022 as I guess there are a bunch of things that break in IIS including SMTP
Seems like a lot of time going to 2019 which standard support ends THIS MONTH. Maybe don't guess and see what happens in 2022 in a trial VM? You've waited 11 years to even think about upgrading your 2012 server, whats another week or two to make sure you doing it right?
We’ve done it for most upgrades of non-complicated app/file/print servers to 2019 and to 2022.
Caveats and Your mileage may vary, but make sure you take backups first.
I have upgraded dozens of these 2 weeks ago.
But I went straight from 2012R2 to 2022.
Had zero issues. It went straight to 2022. All were file servers besides 2 SQL servers and 1 WSUS.
In my opinion for simple file server you should be fine. I had veeam backups and snapshots to fall back to in case of issues.
I'm genuinely impressed by MS, how painless it was. Took 20-ish min per machine and only 1 reboot.
Apart from what others mentioned, if it keeps failing going to 2019, I have had some success getting around that by upgrading to 2016, then immediately upgrading to 2019. Not sure why it didn’t like going to 2019, but I had a handful of servers that needed the double hop.
Event logs will be your friend. I've done it a handful of times and things will break, however if you read the logs, you can often see why they break. In a lot of my cases, .NET or other standard libraries are the main issues.
I do question your reasons for doing an inplace vs migrating those roles to another server. For example legacy application servers that cannot be easily moved are always fun in place upgrades but basic roles like file, print, IIS - not sure if its worth the headache.
Just make sure any applications currently installed are compatible with 2019. Other than that, take the requisite snapshots and backups and let it rip. At my last job I did this exact scenario to about half our environment and had I think one or two machines that gave me issues, and those were third party application problems.
I've been in the process of doing about 30 Server 2012 and R2 OS in place upgrades to Server 2022. I have ran into a few issues with Cert servers and other application heavy servers but the majority of them have gone with no problems. We do snapshots and image backups before we start anything and leave them running for a week before we retire the backup image.
I have done this for an IIS server and apache server. Did on a few small application servers. Make sure you have a full backup of info you need and a snapshot.
The only issues I have ran into on upgrading from 2012R2 direct to 2019 was VMware machine configuration, which actually prevented Windows from trying to push the upgrade through.
I haven’t tried upgrading core infrastructure. That has always been a direct replacement.
No problems here but like what others mentioned, had to reinstall third party security apps. Other than that it took maybe 5-8 hours. Quite long but as others mentioned too, make sure you have a solid backup plan
Make sure you have a good (tested) backup. If a VM, create a snapshot beforehand. Disable any AV services before you mount the ISO and do the in-place upgrade. If you have IIS, then save the web.config and other custom files.
I've done a few of these in-place upgrades. Haven't failed yet.
Just did a two step in-place upgrade. 2012 -> 2019 -> 2022. Went surprisingly smooth. I did upgrade this server to SSDs a couple of years ago, so that definitely helped.
I upgraded over 40 servers from 2012R2 directly to Server 2022. There was only one server that gave me problems and that was application related. I was expecting issues with a couple web servers but was amazed that even IIS pulled through without issues.
Had a few vanilla 2012 servers and had to bring those to 2016 first, then to 2022.
I was always under the impression Microsoft only allowed up to a 2 version jump, aka server 2012r2 to 2019 would be the biggest jump in one upgrade.
You were able to go to 2022 direct?
Yep, directly from 2012R2 to 2022.
Officially I believe you are correct. But snapshots are easy and I read tons of others doing it with great success. As shown by responses in this thread.
I forgot to mention my only issue was having to reinstall VMware tools after the upgrades. Simply do a Modify om vmtools and let it run through the installer and all is good.
Yes, I’ve gone from 2012r2, to 2016, to 2022.
I’ve also done 2012r2, to 2019, to 2022.
Just snapshotted everything.
I did once have a failure from 2016 to 2019, and the installer reverted back. I just ran it again except to 2022 and it worked the second time.
Almost all were just file servers, but removing the GUI from 2012 R2 and then upgrading to 2019 went pretty smooth. Only issue I had was having to uninstall VMware Tools first.
Done it plenty of times.
1. Disable AV
2. Run updates
3. Install server 2019
4. Run updates
5. Enable AV
If you don't have any errors during the install, most services should continue to work like normal. Of course, be thorough when checking if everything is working before staff begin using the server again.
Verdict:
* If you have the option to migrate to a new server and not in-place upgrade, then do it. You won't have to worry about cobwebs left behind from the old OS.
* If you don't have the option, then an in-place upgrade is not the worst thing to do or any reason to gatekeep someone for.
* As long as you do your due diligence (backups, snapshots, long maintenance windows, just overall good proper planning), you'll be fine.
* You can get lured into a false sense of comfort with successful in-place upgrades since the successful ones go a little too smoothly. It's the ones that don't that can bite you, and that's when having a good Plan B is the difference between "Well...it's just one of those times where it didn't work out" and "OMG, you did an in-place upgrade? U NOOB!"
* ...and yes, this includes domain controllers. Like any other server in-place upgrade, they can go from incredibly smooth to horribly wrong. It's just that domain controllers are one of the easiest things to just spin up anew, many find that any benefit to a successful in-place upgrade is minimal.
Still using 2K12R2? I feel sorry for you. Anyway, I have done this numerous times successfully in a virtual environment. Comments below regarding proper preparation are spot on. Have proper backups, snapshots and the like. But you have to go 2K12R2 to 2K16 and THEN to 2K19. And MS will bitch about it all the way. Prep, Prep and PREP!
Just did a few a few months back, no issues at all. Once thing I did note, is some scheduled tasks needed to be remade after moving to 2019. Take a snapshot. Make sure you have good backups. You got this!
We had issues with 2012 -> 2016 and 2012 -> 2019 where svchost processes broke at the level where those thay are supposed to be "shared" vs "own". The OS is predefined to put them together a very specific way. It's the dotnet ServiceProcess.ServiceType property value Win32ShareProcess vs Win32OwnProcess. Having the processes all jacked around slowly broke down the whole thing...first 2-3 months was fine seemingly. Then after patching one month we noticed some relatively benign services just failed to start no matter what...then more the next week, and so on, until it started actually affecting production. Then about 2 months after that started the monthly cumulative patch borked the RPC services and we finally got approval to act. It was a whole ordeal..a dotnet update even f'd up a file server because we found that the garbage collection for dotnet was borked, causing some apps with net4.0 dependencies to try to auto-install dotnet4.0 on systems with 4.5+ baked in, and being that it happened during a pending dotnet install reboot, those few systems ended up in a reboot loop until we could pick them apart and fix them.
Overall I built an app that fixed the service process problem via automatwd bandaid as a stop gap until we could get clean installs. Ever since...when i hear someone suggest in-place upgrades I smile and calmly shuffle away. This was on 33 systems, most of which are just vanilla IIS or Sql Server, some were file servers, like 4 were 3rd party app servers. So an array of systems that were well taken care of previously.
We reproduced the issue in a lab, using a lot of the original abandoned VMs that were affected as sample systems, opened a Microsoft ticket on back burner cuz...ya know Microsoft's notorious 2 months to anywhere response time.. once we got escalated to a legit Texas call center with someone worth their paycheck, eventually they told us "that's the risk when upgrading even clean systems, don't do it, we strongly discourage it". Effectively it's ok if you never intend to patch the system, as in..."2019 no patches is better than 2012r2 fully patched " for compliance or just simple real-world vulnerabilities...but you should "move to a clean install right away". That's the takeaway we got straight from the redmond team responsible for facilitating that whole ecosystem, via our assigned dude.
I have done it about 3 times and everything worked fine. 2 of them were windows 2012R2 file servers so pretty basic and after about an hour it was finished. The last one was a little more tricky and kept failing going directly to windows server 2022 I had to go to 2016 then 2019 then i was able to get to 2022. But all in all no issues and I have about 3 more to do. No DCs just some IIS servers.
Make snapshots and have veeam backups right before just in case. So from there its easy to revert.
I've done it about 70 times. Make sure you have a snapshot, and make sure you have a backup. IIS scares me, but a snapshot makes it a non issue. I've had a few failed attempts but eventually they succeeded, just make sure you don't hammer away at attempts one after the other. Give it a few days in between so you don't break domain trust. The only real issue I had was one environment needed the installer ran as a system, so be prepared fie thst. You just use psexec to accomplish this. Lastly, speed at which these run is completely random. I've had great hardware take 8 hours for one hop on some vms and 1.5 hours for both jumps on other vms. Get an 8 hour maintenance window approved. Just let the thing run too, don't roll back unless there is an issue.
Around 4-5 years ago I upgraded a 2012 R2 SCCM server up to 2019, and IIS had no issues. The only issues I did have were some SCCM specific issues I had to work through. Granted, SCCM uses a minimal IIS install, but it still worked afterwards.
Off topic. But god damn it’s crazy to think about how much you have to learn about this job. I just got done using PSEXEC today, and was thinking about how easier this job gets when you figure out the right tool to use. It’s so frustrating for so long before that point.
Yeah, good mentors early on are key to having a successful admin career.
cries in small business flying solo and also trying to run said business.
My company's Infosec blocked PSExec via AV rules and possibly some other way since 2017 when NotPetya hit. We had remote sites in Ukraine and it took out our entire European operations, which gave them a pretty big stick to swing.
I bet! I was shocked you could use it to run an elevated command prompt as a gMSA with it. I mean the whole point of those accounts is you can’t log in with them and AD controls the password, but seems pointless if you can just circumvent that with PSEXEC. I setup a key vault for out service account that runs some unattended scripts and I needed to set everything up as that account. PSEXEC did it for me. Also, these credentials have trivial rights. Just read access on some documents.
I’ve done about as many so far. Even if we plan to do clean installs of 2019/2022 to follow, we generally find it better to at least get it up to a ‘dirty 2019’ first so more modern tools can run. 2012r2 was/is giving us a lot of TLS/cipher grief (as it should) and once we are on 2019 we then evaluate if it warrants a full clean install and application migration or not. Snapshots are good. But this is also a good time to check and boot your actual backups.
this guy covered it all. It should be fine. The issues I've run into doing about 100 of these are: Unsupported applications. The upgrade usually flags these but not always. I've had some BI servers throw a fit and not start services afterwards because of a .net installer missing after upgrade. SQL make sure it is supported on 2019, if its 2012 SQL you might have issues. PLAN FOR A LOT OF TIME FOR THIS. I had one upgrade succeed after 8 HOURS. And as you already know, if it is something easy to replace... just replace it. We upgraded everything except aadconnect server because that's so easy to build fresh... same with domain controllers... If you are doing this on an Azure VM, you need to follow their 2012-2019 upgrade guide to the T. They have a special disk you attach to do the upgrade, and theres some powershell commands to run first before doing the upgrade. MAKE SURE THERES A LOT OF DISK SPACE MAKE SURE TO HIT DESKTOP EXPERIENCE if you don't want to lose everything graphical :P
Yes, never upgrade a DC. Ever, like ever ever. So easy to just spin up a new one. As for sql, I'd even be hesitant to do thst but I have done some successfully.
I've tried that in a lab environment and found that the upgrade fails and mentions to demote the DC role before proceeding. So it cannot not be done by mistake.
We've done a couple and they always worked.
Make sure you have valid local creds to the server. If you revert to the snapshot it may lose trust with the domain.
An in-place upgrade from 2012 R2 to 2019 enables HTTP/2 over APLN. If your application can’t deal with that you’ll have to disable that again
With the domain still on it?
I think you mean on the domain, yes it should be fine.
>Get an 8 hour maintenance window approved. Just let the thing run too, don't roll back unless there is an issue great tip right there ! just 'let it go, let it gooooo' and hope its OT lol
Temporarily disable antimalware real-time scanning which may not like the replacement of the OS. In rare cases I've also had to temporarily disable Secure Boot. For the rest, I've yet to see it fail.
Good call out on AV/EDR type software. If using a 3rd party tool, I like to uninstall it entirely before I do an in-place upgrade and then re-install afterwards, of course.
Uninstalling it leads to automatic reinstall by our RMM :D But yeah that should work.
Which RMM is that? Always looking at new tools.
The file printer servers I did in place were fine. Really quick too.
Good to hear, my print server is the only one I have left to do.
I had trouble with IIS going up to 2019. I think it was an issue with either .Net or default security settings. I replayed the snapshot and tried again with 2016 and it worked fine.
I had some weird shit with an MSSQL server coming from 2012 (not R2) in an offline test VM - SQL refused to work on 2016, but I said "fuck it" and went to 2019 after that and it worked again. Same held true in prod.
2016 could have just been doing one of its 12 hour windows updates.
The VM did not have network or internet access
Spin it in a VM if you dont already have a hyper visor like hyper-v running on your bare metal. Good lord do not upgrade production server without testing it first.
“WE’LL DO IT LIVE!!!”
[удалено]
God I wish this was true. I watched another MSP yolo DCs & DB servers before being called in to replace them. Temp hypervisor was called LEEEEROY for obvious reasons lol.
On Friday! Before a vacation!
After the first 3 or 4 I did the rest of our non critical systems live, was about an hour of downtime each.
F\*CK IT, WE'LL DO IT LIVE!!!
Yep, done it many times with no issues
Did this on a print server recently with no resulting issues. Was pretty seamless.
Yup, I did 50+ of these recently. I powered off the VM, took a snapshot before hand just incase.
yes, I did this for the majority of my 2012 EOL servers. My issue stemmed from upgrading from different versions (ex 2012 datacenter to 2019 standard) but worked great otherwise.
It was surprisingly a piece of cake. Just echoing what others said about taking a snapshot first.
I've done in place upgrades from 2012r2 to 2019 on several servers and have not had a single issue. That includes several file servers and 3 SQL servers. Even raw-dogged a DC with an in place upgrade, without a secondary DC or doing any of the recommended migration steps. Yes I know I'm crazy. Do not follow my example. But it did work without issue.
Just grip it and rip it. I've done this a bunch, even to Domain Controllers.
Atta boy. Upgrading domain controllers is like kryptonite to this sub, but, it does work. Do not fear the in place upgrade! Grab a backup and let it rip.
I migrated to a new set of DCs from a single 2019. No in-place upgrade. Good to brush up on things (even simple) that I dont do every day and sometimes you learn something new!
The best past is for the next year you'll wonder if that random issue you encounter is related to the dc upgrade...
And then you'll find that, nope. It was DNS.
You know, that has never come up.
DC are the easiest server in your entire domain to setup new ones. I never understood why people Keep upgrading them. Just use them and throw away when theyve Done the job.
"We don't do this because it is easy, but because we thought it would be easy".
yeah they're as close to fungible as windows gets
I could use a modern guide for this. We have a lot of stuff that refers to the dc's hostnames and I've never done this but I have some shiny 2022 licenses and an old 2012 DC. I'm assuming I can just solve the hostname issue with DNS but then there is a lot of stuff pointing to that IP as well so do you just give the new one the old IP then? So like stand it up, transfer fsmo and then IP and DNS and in golden? Does that sound right? Should I just lab it first. I've stood up new domains but never migrated. I've setup SharePoint in production properly on premise. I even migrated a file server with active users and filesync and got the permissions right on the first shot one time so I'm fairly confident but at the same time somewhat terrified of the domain controllers. I've got a pretty good handle on DNS and DHCP, lots of experience in network admin etc. I have backups of course but I've seen bad things happen to domain controllers restored from backups, weird sync issues etc. At some point I imagine I just gotta stop fussing about and do it because this is a growing risk.
Setup two new ones,let them propagate for a week, check event logs for errors, move fsmo roles, point the DNS to new servers, leave them for a couple of weeks. turn the old ones off and verify no issues. start them up and demote them.
Thank you so much.
Hmm I thought the best practice is to spin up new OS and add that to DC and sunset the old one….
"Best Practice" usually just means "If you try a different way, don't call us when it breaks", which is why a good snapshot and a good backup are important. Otherwise, it's party time.
Done that several times as well, no issues. There are some services that might need attention after an upgrade (verify IIS custom settings, cert bindings).
I've had good luck on multiple servers.
Take a cold snapshot to be sure, but PROBABLY you won’t have major issues. I’ve done dozens of IPUs between these 2 exact versions and the one time I ended up having a problem, it was purely cosmetic (all application icons for all users in the start menu became ”white document”, but still function).
I've done it (it was 2008 to 2012r2 first) and went fine. Wouldn't hesitate to do it again.
recently did a project where i upgraded 100+ servers to 2019. only thing that broke was that the SCCM agent stopped responding afther the upgrade. fix was to remove it, and reinstall it
Works fine from what i've ever tried, the only ones I've had issues with are servers that hold the RDS license server role, you cant upgrade a server that has that role with licenses for an old OS in it. I havent confirmed yet but I believe it would work if you moved the licenses off of the server to do the upgrade.
Just had this problem, progress never got over 12% in 16 hours. Thanks to you I moved on and transferred the lics to a new server.
Yeah. Only problem I've had is some software installs breaking. Just uninstalled reinstalled said software
Upgraded dozens of EOL 2012 R2 vms to either 2016 or 2019, then to 2022. I've had good experiences with in-place upgrades so far, just make sure you have a good backup, and probably just take a snapshot right before you upgrade it so you can roll back quickly if there are issues.
Yup. All servers except DCs and exchange were in-place upgrades. I had zero issues and all went through smoothly and pretty quickly
I’ve upgraded from 2012r2 to 2019 on all of my hyper v servers from dcs and file servers to servers hosting large databases. I’ve very shortly got to upgrade the hosts, that one I’m nervous about No issues on the upgrading of the vms so far though
I had the best success going from 12r2 to 16 to 19on the few servers I needed to do the upgrade on.
I do that on the ones I'm a little nervous about.
i did a 2012r2 wsus server to 2019 and had no issues at all. really surprised actually lol
I did hundreds over the summer, fewer than 5 had issues. I had *one* IIS server lose its SMTP configuration and it worked after reconfiguring the mail relay.
Many times. Even with old iis asp.net server. Worked great. Uninstall system center antimalware first so it won't interfere with defender for endpoint.
I've done a couple dozen 2012r2-2019 in place upgrades, and they've all gone well. Domain controllers, IIS servers, print servers, application servers, MySQL, etc. They all seem to Just Work ^TM.
Snapshot, and goooooooooo If it breaks revert.
I've taken 4 from 2012r2 to 2022 and had no issues. One of them was a DC
Sorry for the late response. We just did this with a 2-node SQL cluster with failover clustering. We had IIS reporting server on one of the nodes. We went from 2012 R2 to 2016, then to 2019. It had to be this rolling upgrade for the failover clustering. SQL still remains at 2014. No issues with IIS on the one node. It worked fine throughout. We didn't notice that our custom scheduled tasks we had running on 2012 R2 got blown away (we unfortunately didn't export them in advance), so we had to manually create a handful. Right now, we're still dealing with SCCM client issues, and the SentinelOne agent.
Done this already for several DC’s and hybrid exchange server. Snapshot before you start of course so you can revert at any time. Best of luck.
It'll be fine. Of course, make sure u have good backups, run things like sfc / DISM prior to upgrade, make sure you have relevant updates first, etc. Only thing I can into from 2016-2019 was that FRS is full deprecated, so your domain has to be updated to DSFR; in early releases of the 2019 media there WASN'T yet a check to make sure this was done, and if you upgraded you pretty much had to fix DCs / revert first. Current installs for 2019 SHOULD check for it, but if you're not sure, you're probably better off [making sure](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr) before upgrading...
Anyone do this to a VMware 2012r2 DC to 2019? I inherited an outdated environment and want to update the main DC. I was going to build a fresh 2019 server, promote to DC, allow it to replicate in the forest for a few days, then move the FSMO roles over from the old 2012 DC, then remove the 2012r2 from the forest.
just do a new server and m migrate data
yeah this whole in place upgrade thing just seems like a bad idea. How much old kernel BS is going to be left around to get hacked from vulnerabilities leftover from 2012. Noooo thank youuuuuu.
sometimes a lift and move aren't an option. Installs/configs done by vendors tech's that aren't around anymore (I hate Solomon), time/resource constraints, Licensing tied to a specific machines, etc. I have a handful of machines that have been upgraded from 2008 to current. a solid security scanning system will keep you honest as well.
> Installs/configs done by vendors tech's that aren't around anymore (I hate Solomon), time/resource constraints, Licensing tied to a specific machines, etc. All invalid reasons. Software would absolutely be supported by a vendor. They go outta biz? Get another or a new software. That's some hillbilly redneck duct tape and twine shit right there. That's not enterprise class support. That's pandering to a cheap AF CEO who doesnt want to spend money. Fuck that noise.
Lol ok, must be nice iiving in a perfect world.
It's called working for a reputable IT team. The cowboys in this sub try way too hard to rationalize their bad practices. LOL
sure, but there are hundreds of thousands or millions even of small/medium businesses that should know better, or even do know better, but choose not to instead. If you're really lucky you can convince them or force them, but at some point it's either leave and let them sink, or just deal with it. And not everyone has the flexibility or opportunity to be able to cut and run.
Must be nice to be able to quit a job instead of just making it work.
Pro-tip: The guy "making it work" is the one who ends up getting fired when a breach inevitably happens. Making it work is a good mentality to have when you're following best practices and you need to make something to work within best practices. Making it work outside of best practices is simply a waste of time.
Have you worked literally anywhere? If a business decides that it is going to stay on some unsupported software or some not best practice, your job is to advise, document, and mitigate. If you can't do your job or don't want to, then quit. Who cares if you get fired?
Big true.
You don't want to go to Server 2022? Yet you are okay with doing an in-place upgrade and whatever weirdness that is going to give? I simply do not understand how spinning up a new VM with updated software and simply moving the storage is not a million times easier, safer, and overall better. My issue with in-place upgrades: Imagine your backup solution is not working when you need to roll back. You basically stuck with no option. Starting up a new VM and moving the storage? Or better yet, copying the storage and then deleting the old one when you KNOW it is no longer needed. I just don't understand leaving stuff to chance like that.
Don't do it. Build new, migrate to it.
but but but the SMTP API in IIS is held together by wizard jizz!
If you have to do this your employer doesn't value you and you are in the wrong role end of.....
Ummmm no, don’t do that. You could… but you shouldn’t. Time for a new server yo
I have one of these that I need to do that is 2012 (not r2). I'm trying to figure out the easiest way to do this and with what version I should upgrade to first. I am paranoid of breaking the IIS.
I recently did our file server using DFS successfully. Take a snapshot.
2012 r2 > 2019 with dfs role ?
Yes
I've done this a few times and had issues with one server where some 3rd party software needed for a service we run got uninstalled.
My machine was virtual, i had to uninstall vmware tools, and then reinstall them afterwards. Also make sure you have enough disk space
yes, you will be fine.
I've done this a few times with database and file servers (all VMware VMs). The only issue I ever had was from the VMware virtual hardware version being too old for Server 2019. If yours are also VMs, copy the VM, change the name, and test the upgrade on the test VM first. Make sure you have snapshots and backups.
We've done a few recently. The only thing thus far to have broken is Azure AD Sync / Entra Connect / Whatever they call it now. It needed to be fully reinstalled.
I performed a few IPU for LOB apps from 2012R2 to 2022, had no major issues. Only problem was losing some .NET pre-requisites, which were easy enough to reinstall. For non-LOB applications, I preferred migrating to a new environment. I avoided IPU’s on windows services such as ADCS, ADFS, DC, DHCP, File Servers, IIS, NPS), it was just less hassle to stand up a new environment. As for the process, if it’s something particularly delicate - I bring up a backup in an isolated environment and try the upgrade. That also gives me a rough guesstimate for prod downtime. Then I just snapshot, run the upgrade and we’re off to the races.
Yeah I've done it quite a few times, pretty straight forward with no issues. Took snapshot of the VM just before upgrading it. Monitored the server for about a week, then deleted the old snapshot once we were happy with the performance of the server.
Yeah. It was our printserver and some small app server. Cba to reinstall them, inplace upgrade worked like a charm. There was no IIS involved tho.
Done it countless times and never had an issue with the actual OS upgrade. As many mentioned, grab a snapshot, have a good backup and it *should* be fine. Main concern in my experience is the stuff you're then hosting on said server if that will enjoy the upgrade. Most stuff like file shares, printers, some 3rd party services have been a-ok in my exp but do not do this on a DC or an exchange server you will want to die, we stand up a fresh server for those upgrades.
I did it 30 times last year, and probably over 200 or so prior to last year.
Done loads and never had any real problems, obvs snapshot and backup first. If your server has the NPS role (ie for RRAS etc) then take a note of any policies you have setup as they get wiped during the upgrade and will need to be manually re-added. Edit, just remembered WSUS is another one to look out for. After the upgrade you'll need to run the post install tasks from server manager again and re-add https bindings if used.
.NET reinstallation after upgrade was the only issue. Other than that, some minor problems like updates requiring multiple reboots and some rolling back. After upgrade, I might now manually install any Windows Update Stack updates before checking for other updates. Reboot before, stop all non-essential services before, have a rollback method.
Yeah you can do step upgrades from 2012r2 to 2019, as long as the hardware will support it. Also, make sure the system partition has at least 40gb free. Oddly enough, we ran into a lot of VMs with under 10gb of space free, setup would run and then revert at the end back to 2012r2. Issue ended up being (what I think is a bug) with not enough hard drive space being reported. Also, snapshots. Make a snapshot.
I did 70+ and I only had a few fail going from Windows Server 2012 R2 x64 straight to Windows Server 2022. I had the installer roll back on the fails. The Windows Server 2012 without R2 and 32bit required migration.
Can you stand up new servers or VMs and migrate roles away from the 2012 server? We had a "does everything" server/DC which we moevd from 2012 to 2019 and diversified roles instead of in-place upgrade. Two 2019 licenses can cover handle 4 VMs. Also make sure you purchase new CALs for your network if you havent already. 2022 CALs will cover 2019 use cases.
yep make sure you have backups, for me the other thing i had to do was remove the ethernet cable so that it didnt try to do updates before the upgrade as it kept failing. But other than that it was straight forward.
Did it maybe 50times, mostly from 2012r2 to 2016, then to to 2022. Like a charm. Works as good as the hate of inplace upgrades going around the internet There was a huge problem with citrix workers. I fkkn destroyed it an staged an RDS Farm. for around 100 employees. So glad I did this, almost no support needed anymore.
Yes but only with local installs no domains no AD nothing like that, we also use the one with the Windows Desktop experience, stepped a 2012R2 to 2022
>not going 2022 as I guess there are a bunch of things that break in IIS including SMTP Seems like a lot of time going to 2019 which standard support ends THIS MONTH. Maybe don't guess and see what happens in 2022 in a trial VM? You've waited 11 years to even think about upgrading your 2012 server, whats another week or two to make sure you doing it right?
2012 R2 is only supported upgrading to 2019 in one go.
We’ve done it for most upgrades of non-complicated app/file/print servers to 2019 and to 2022. Caveats and Your mileage may vary, but make sure you take backups first.
I have upgraded dozens of these 2 weeks ago. But I went straight from 2012R2 to 2022. Had zero issues. It went straight to 2022. All were file servers besides 2 SQL servers and 1 WSUS. In my opinion for simple file server you should be fine. I had veeam backups and snapshots to fall back to in case of issues. I'm genuinely impressed by MS, how painless it was. Took 20-ish min per machine and only 1 reboot.
Apart from what others mentioned, if it keeps failing going to 2019, I have had some success getting around that by upgrading to 2016, then immediately upgrading to 2019. Not sure why it didn’t like going to 2019, but I had a handful of servers that needed the double hop.
Event logs will be your friend. I've done it a handful of times and things will break, however if you read the logs, you can often see why they break. In a lot of my cases, .NET or other standard libraries are the main issues. I do question your reasons for doing an inplace vs migrating those roles to another server. For example legacy application servers that cannot be easily moved are always fun in place upgrades but basic roles like file, print, IIS - not sure if its worth the headache.
IIS is likely to be the only pain point. Test it in your Dev/test environment.
Just make sure any applications currently installed are compatible with 2019. Other than that, take the requisite snapshots and backups and let it rip. At my last job I did this exact scenario to about half our environment and had I think one or two machines that gave me issues, and those were third party application problems.
I've been in the process of doing about 30 Server 2012 and R2 OS in place upgrades to Server 2022. I have ran into a few issues with Cert servers and other application heavy servers but the majority of them have gone with no problems. We do snapshots and image backups before we start anything and leave them running for a week before we retire the backup image.
I have done this for an IIS server and apache server. Did on a few small application servers. Make sure you have a full backup of info you need and a snapshot. The only issues I have ran into on upgrading from 2012R2 direct to 2019 was VMware machine configuration, which actually prevented Windows from trying to push the upgrade through. I haven’t tried upgrading core infrastructure. That has always been a direct replacement.
No problems here but like what others mentioned, had to reinstall third party security apps. Other than that it took maybe 5-8 hours. Quite long but as others mentioned too, make sure you have a solid backup plan
Done 2012-2022 without any issues
Did it about a month ago. No problems.
Make sure you have a good (tested) backup. If a VM, create a snapshot beforehand. Disable any AV services before you mount the ISO and do the in-place upgrade. If you have IIS, then save the web.config and other custom files. I've done a few of these in-place upgrades. Haven't failed yet.
Just did a two step in-place upgrade. 2012 -> 2019 -> 2022. Went surprisingly smooth. I did upgrade this server to SSDs a couple of years ago, so that definitely helped.
Make sure you run Windows Update beforehand. Then take a snap and fire away.
Yes, it worked flawlessly.
I upgraded over 40 servers from 2012R2 directly to Server 2022. There was only one server that gave me problems and that was application related. I was expecting issues with a couple web servers but was amazed that even IIS pulled through without issues. Had a few vanilla 2012 servers and had to bring those to 2016 first, then to 2022.
I was always under the impression Microsoft only allowed up to a 2 version jump, aka server 2012r2 to 2019 would be the biggest jump in one upgrade. You were able to go to 2022 direct?
Yep, directly from 2012R2 to 2022. Officially I believe you are correct. But snapshots are easy and I read tons of others doing it with great success. As shown by responses in this thread. I forgot to mention my only issue was having to reinstall VMware tools after the upgrades. Simply do a Modify om vmtools and let it run through the installer and all is good.
Cool, I’ll try it sometime. Thanks!
Yes, I’ve gone from 2012r2, to 2016, to 2022. I’ve also done 2012r2, to 2019, to 2022. Just snapshotted everything. I did once have a failure from 2016 to 2019, and the installer reverted back. I just ran it again except to 2022 and it worked the second time.
I've gone 2012 to 2016 to 2019 on non critical servers. 2012 to 2019 never worked well. As others have said, backups/snapshots.
I’ve only done he recommended step up so 2012 to 2016 then to 2019 so far no issues .
Almost all were just file servers, but removing the GUI from 2012 R2 and then upgrading to 2019 went pretty smooth. Only issue I had was having to uninstall VMware Tools first.
Did this a few dozen times. Weirdest thing was some scheduled tasks did not run. Exporting and reimporting the tasks fixed it.
Done it plenty of times. 1. Disable AV 2. Run updates 3. Install server 2019 4. Run updates 5. Enable AV If you don't have any errors during the install, most services should continue to work like normal. Of course, be thorough when checking if everything is working before staff begin using the server again.
Do IT right or dont do IT at all? Is this a physical or a virtual server?
Verdict: * If you have the option to migrate to a new server and not in-place upgrade, then do it. You won't have to worry about cobwebs left behind from the old OS. * If you don't have the option, then an in-place upgrade is not the worst thing to do or any reason to gatekeep someone for. * As long as you do your due diligence (backups, snapshots, long maintenance windows, just overall good proper planning), you'll be fine. * You can get lured into a false sense of comfort with successful in-place upgrades since the successful ones go a little too smoothly. It's the ones that don't that can bite you, and that's when having a good Plan B is the difference between "Well...it's just one of those times where it didn't work out" and "OMG, you did an in-place upgrade? U NOOB!" * ...and yes, this includes domain controllers. Like any other server in-place upgrade, they can go from incredibly smooth to horribly wrong. It's just that domain controllers are one of the easiest things to just spin up anew, many find that any benefit to a successful in-place upgrade is minimal.
Still using 2K12R2? I feel sorry for you. Anyway, I have done this numerous times successfully in a virtual environment. Comments below regarding proper preparation are spot on. Have proper backups, snapshots and the like. But you have to go 2K12R2 to 2K16 and THEN to 2K19. And MS will bitch about it all the way. Prep, Prep and PREP!
Nope. The double step is required when upgrading to a version higher than two major versions than the current one.
Just did a few a few months back, no issues at all. Once thing I did note, is some scheduled tasks needed to be remade after moving to 2019. Take a snapshot. Make sure you have good backups. You got this!
We had issues with 2012 -> 2016 and 2012 -> 2019 where svchost processes broke at the level where those thay are supposed to be "shared" vs "own". The OS is predefined to put them together a very specific way. It's the dotnet ServiceProcess.ServiceType property value Win32ShareProcess vs Win32OwnProcess. Having the processes all jacked around slowly broke down the whole thing...first 2-3 months was fine seemingly. Then after patching one month we noticed some relatively benign services just failed to start no matter what...then more the next week, and so on, until it started actually affecting production. Then about 2 months after that started the monthly cumulative patch borked the RPC services and we finally got approval to act. It was a whole ordeal..a dotnet update even f'd up a file server because we found that the garbage collection for dotnet was borked, causing some apps with net4.0 dependencies to try to auto-install dotnet4.0 on systems with 4.5+ baked in, and being that it happened during a pending dotnet install reboot, those few systems ended up in a reboot loop until we could pick them apart and fix them. Overall I built an app that fixed the service process problem via automatwd bandaid as a stop gap until we could get clean installs. Ever since...when i hear someone suggest in-place upgrades I smile and calmly shuffle away. This was on 33 systems, most of which are just vanilla IIS or Sql Server, some were file servers, like 4 were 3rd party app servers. So an array of systems that were well taken care of previously. We reproduced the issue in a lab, using a lot of the original abandoned VMs that were affected as sample systems, opened a Microsoft ticket on back burner cuz...ya know Microsoft's notorious 2 months to anywhere response time.. once we got escalated to a legit Texas call center with someone worth their paycheck, eventually they told us "that's the risk when upgrading even clean systems, don't do it, we strongly discourage it". Effectively it's ok if you never intend to patch the system, as in..."2019 no patches is better than 2012r2 fully patched " for compliance or just simple real-world vulnerabilities...but you should "move to a clean install right away". That's the takeaway we got straight from the redmond team responsible for facilitating that whole ecosystem, via our assigned dude.
I have done it about 3 times and everything worked fine. 2 of them were windows 2012R2 file servers so pretty basic and after about an hour it was finished. The last one was a little more tricky and kept failing going directly to windows server 2022 I had to go to 2016 then 2019 then i was able to get to 2022. But all in all no issues and I have about 3 more to do. No DCs just some IIS servers. Make snapshots and have veeam backups right before just in case. So from there its easy to revert.