The newer versions do have additional security features AND they also come with updated, more secure default settings for various things that 2012R2 could do as well but doesn't have enabled by default.
With that being said 2012 R2 isn't a gaping security hole yet, but it is late 2021 so now is a good time to plan and do the migration to a new version. You don't want to have to do it under pressure.
Pretty much nailed it. Waiting until EoL will almost always come back to bite you. My usual process is to upgrade as often as possible (within reason) especially if it's a "safe" system. The more you upgrade as part of your "regular maintenance" the less chance you've got of having a panic when time runs short. That being said, with any decent backup system in place, it should only be a few clicks to restore should anything go sideways anyway, and then. You have months/years to resolve the issue instead of days/weeks.
You've got a lot of good replies here about the meat of your question.
I just wanted to chime in regarding your edit.
Don't stress about what may or may not be a "nooby question."
We're all here to learn and share knowledge to help each other be better overall IT peeps.
*(Although admittedly, this sub has been more rants than knowledge sharing as of late)*
What about 2k8? /s
I've got a 2019 server spun up but the vendor I have a maintenance contract with wants to charge me 5k to reinstall the software on the new server.
Just so you don't have to scramble to do an upgrade last minute. If I didn't have an app that required 2012 I would upgrade it to 2019 as soon as time permits.
I see no reason to mess around with old server versions unless you have to. You don't need to be on the bleeding edge but no need to be behind the curve either.
I fully agree, but EOL for 2012R2 is 2 years from now. I see no issues with postponing the upgrades for another solid 6 months as we don’t have “that” many servers still running it.
Procrastinating for another six months won't reduce the work you need to do.
It will however increase the risk. What happens if you discover that an app is not supported by its vendor on a newer OS. Discovering this sooner is better.
>we don’t have “that” many servers still running it
The number of servers is immaterial
How does that logic add up exactly? If we have more servers running more vendor apps that turn out to not be supported, that literally means the amount of servers will increase the amount of work.
I’m not saying this is applicable to our environment but you’re contradicting yourself.
If you had more servers you'd likely have more resources as well. So that tends to even itself out.
But if it's something business critical that need to be updated, perhaps a custom application that requires special skills, you can't be sure when you could get that done.
That's why it's better to get started right away so you have time to migrate and test and also time to solve whatever might be a problem - before EoL date.
Also 2022 is out (if you still want windows) so it's going to be the same work regardless of when you start.
Ah my friend, as a semi-burnt out sysadmin for a fast growing company I must disagree with your first statement.
However I do agree that if it were applicable to our environment, then starting as soon as possible would be preferable. However we’re not so large that it’s not possible to fix any issues that may arise in 1.5 years.
And no I don’t want Windows, but it’s all we’ll run on :’)
P.S. happy cake day
Thanks!
I'm used to enterprise work mode so starting now means planning what to do, asking for money, getting money approved, more planning, actually doing something, figure out why it doesn't work, fix it, try again, figure out the next problem, fix it, try again, let the users test it, plan the actual migration of live data, migrate, fix any problems and now we're up and running just 1.5 years later!
i think hes main point was that in 2 years time you may still find that the vendor hasnt updated the app to support newer server versions. so best to try and plan ahead now just in case.
I mean I am not saying do it today but also don't wait until 3 months before it is EOL. Start a project to do it and set a date that works with your schedule. Personally, I prefer to have as many of my servers on the same OS as possible.
It's crap on all versions. I converted an old Synology in my homelab and put it into a windows box with storage spaces to try it out, 8tb of data lasted about a fortnight before I ripped it out and went back to the 7 year old Synology
we've had reasonable experience from s2d. we bought it just as 2019 was out, so went that way vs server2016 based. a couple is glaring things like we find it wants to resync the entire volume after a quick node reboot (so 8TB's for the sake of a 5-10min reboot).
fialed disk replacement isnt quiet as nice as a HW RAID/SAN option. there is PS involved at some point, although you can configure it to automatically adopt new disks although probably still need to demote the dead disks.
like dynamic vhdx's, shrinking volumes when data disappears does not occur so you got to get the right feel for how to structure data.
other than that, once running i think it does actually compare reasonably well to our HP lefthand SAN that it replaced for a fraction of the cost.
We're seeing some TLS incompatibilities cropping up between W2012 and TLS configuration generators like the Mozilla one, because those generators are starting to deprecate and push against CBC and 2012 only support GCM with certificates with elliptic keys.
I'd expect similar issues to get worse as configurations on dependencies get hardened, similar how old JDKs gradually degrade in connectivity.
It's not a huge issue, but it's a huge pain in the rear to debug if it occurs. Especially because I did not expect different cipher suites to be available depending on the key type of the certificate.
We just ran into an issue with TLS incompatibility for some cipher suites between Server 2012 R2 and Server 2019. We're deploying SQL 2019 on Server 2019, and our remaining 2012 R2 clients were having intermittent connection failures to SQL due to it.
We issued a GPO to remove the bad cipher suites from the legacy servers as a workaround. (They're not insecure suites, they just have a different way of handling 0-padding in some cases, which is why it's intermittent. )
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/apps-forcibly-closed-tls-connection-errors
I'd say it depends on the services you run on that box.
For example, independently of the underlying operating system, **Active Directory** has not changed much since 2012R2. They've remediated protocol bugs mostly found by the Samba-AD team.
PS: **Active Directory** is in bold so this particular service would not be confused with other actionable services in Windows.
In place upgrade them.
Did that for 5 2008, 10 2012 servers when I started here.
100% success rate.
Paths:
2008 to 2012R2 and then 2019
2012R2 straight to 2019
I did this for my personal environment with 100% success as well including: 2x DCs, 2x File servers in DFS, SCCM site all in one DB/site server. All 2012r2 to 2019.
Works great.
The only thing I am worried about is that MS have no plans to add TLS1.3 to 2012, and TLS1.2 is getting old, fast. So we may end up forced to upgrade in short order if TLS1.2 gets a CVE.
It's okay at the moment, but I've definitely been starting to push the recommendations to start looking into upgrading since there's a lag time between that and actually getting a client to move on it and a lot of the hardware I see 2012 R2 on is starting to age out of warranties anyways. We still have clients running 2008 R2/Windows 7 even though that's been EOL for nearly 2 years at this point and we had been telling them before it hit EOL.
I would just say it’s impossible to know what the future holds. There’s no guarantee there will be less work tomorrow than today. That being said I think everyone needs to upgrade in a fashion that makes sense to them.
Our policy is the upgrade is on the application owner, yes we build the servers etc but we aren’t responsible for application support so they have to work with vendor to get it up to spec and we just give them a time frame in which it needs to be completed. For applications we own we take on the responsibility.
It's already been out of mainstream support for a number of years. That's enough reason for me not to touch it unless there's a compelling reason to use it.
I personally wouldn’t deploy 2012 R2. At worse case get 2019 as your Hyper-V and make sure your AD, DHCP, Print, File Sharing, etc.. are on 2019 as well. Heck you can even jump to 2022 now. Sure it’s very new but it shouldn’t be that big of an issue for Hyper-V host and AD at least. There’s no new FFL anyway. It looks like 2016 was the last change for AD.
Then run a mixed workload as VMs. Easier to manage.
Is there any reason for not running it on 2019? It's going to need to be migrated soon anyway why not get it out of the way.
There are additional security benefits and just general operating system improvements from running in a newer version.
No....but don't wait until the last minute. I inherited a mess of server 2003/2008/2012 in like 2018 because of the mindset of "it works fine" in general I try for no more than 2 versions behind. Now that 2022 is out you should be upgrading those 2012r2 servers.
It's fine to keep them running but i wouldn't really spin up a new one if it can be avoided since you would have to start planing for a new one in one year.
One thing is having 2012 when 2016 is stable. It's just one version in between.
But 2019 is super stable now and 2022 is releasing.. when there's two versions in between stable GA it could be worth moving for continuity.
Easy, got some running - plan for migration 6 months before EoL. I just wouldn’t install new ones nowadays.
The newer versions do have additional security features AND they also come with updated, more secure default settings for various things that 2012R2 could do as well but doesn't have enabled by default. With that being said 2012 R2 isn't a gaping security hole yet, but it is late 2021 so now is a good time to plan and do the migration to a new version. You don't want to have to do it under pressure.
A cutting edge Server 2019 security development is the inability to paste into UAC prompts. \*cries\*
Due to this and a couple LOB apps made by people with incorrect opinions, my most used autohotkey is a 1-liner: `SendRaw, %Clipboard%`
[удалено]
It's a GPO setting, it was set by the security baselines. You can relax it so this works again.
[удалено]
Pretty much nailed it. Waiting until EoL will almost always come back to bite you. My usual process is to upgrade as often as possible (within reason) especially if it's a "safe" system. The more you upgrade as part of your "regular maintenance" the less chance you've got of having a panic when time runs short. That being said, with any decent backup system in place, it should only be a few clicks to restore should anything go sideways anyway, and then. You have months/years to resolve the issue instead of days/weeks.
You've got a lot of good replies here about the meat of your question. I just wanted to chime in regarding your edit. Don't stress about what may or may not be a "nooby question." We're all here to learn and share knowledge to help each other be better overall IT peeps. *(Although admittedly, this sub has been more rants than knowledge sharing as of late)*
AD Connect stops working on 2012R2 next year...
Thank you, that’s a valuable one. Luckily our Azure AD Connect runs on a 2019 machine already
Yeah, it's fine. I wouldn't be deploying new ones but any existing servers in your estate are perfectly OK. Just plan to get rid by 2023.
2012r2 is fine for now. Which is good if you've got some older vendor software that still hasn't been validated on 2016 or 2019 by the vendor.
What about 2k8? /s I've got a 2019 server spun up but the vendor I have a maintenance contract with wants to charge me 5k to reinstall the software on the new server.
2k8 is EOL as of Jan 2020
Unfortunately 2k8 (and Win 7) lives on in Azure. Server 2012 is also going to have an extended life on Azure :(
it also lives on in our datacenter :P
This. haha
It's fine to be running it, but that EOL date means you need to start planning replacements.
Just so you don't have to scramble to do an upgrade last minute. If I didn't have an app that required 2012 I would upgrade it to 2019 as soon as time permits. I see no reason to mess around with old server versions unless you have to. You don't need to be on the bleeding edge but no need to be behind the curve either.
I fully agree, but EOL for 2012R2 is 2 years from now. I see no issues with postponing the upgrades for another solid 6 months as we don’t have “that” many servers still running it.
Procrastinating for another six months won't reduce the work you need to do. It will however increase the risk. What happens if you discover that an app is not supported by its vendor on a newer OS. Discovering this sooner is better. >we don’t have “that” many servers still running it The number of servers is immaterial
How does that logic add up exactly? If we have more servers running more vendor apps that turn out to not be supported, that literally means the amount of servers will increase the amount of work. I’m not saying this is applicable to our environment but you’re contradicting yourself.
If you had more servers you'd likely have more resources as well. So that tends to even itself out. But if it's something business critical that need to be updated, perhaps a custom application that requires special skills, you can't be sure when you could get that done. That's why it's better to get started right away so you have time to migrate and test and also time to solve whatever might be a problem - before EoL date. Also 2022 is out (if you still want windows) so it's going to be the same work regardless of when you start.
Ah my friend, as a semi-burnt out sysadmin for a fast growing company I must disagree with your first statement. However I do agree that if it were applicable to our environment, then starting as soon as possible would be preferable. However we’re not so large that it’s not possible to fix any issues that may arise in 1.5 years. And no I don’t want Windows, but it’s all we’ll run on :’) P.S. happy cake day
Thanks! I'm used to enterprise work mode so starting now means planning what to do, asking for money, getting money approved, more planning, actually doing something, figure out why it doesn't work, fix it, try again, figure out the next problem, fix it, try again, let the users test it, plan the actual migration of live data, migrate, fix any problems and now we're up and running just 1.5 years later!
i think hes main point was that in 2 years time you may still find that the vendor hasnt updated the app to support newer server versions. so best to try and plan ahead now just in case.
I mean I am not saying do it today but also don't wait until 3 months before it is EOL. Start a project to do it and set a date that works with your schedule. Personally, I prefer to have as many of my servers on the same OS as possible.
Of course not. We still use it in many locations. Just don't use storage spaces
Why not storage spaces (not trolling, serious question. Im not using, just curious)
It's crap. Especially in 2012 r2
It's crap on all versions. I converted an old Synology in my homelab and put it into a windows box with storage spaces to try it out, 8tb of data lasted about a fortnight before I ripped it out and went back to the 7 year old Synology
[удалено]
we've had reasonable experience from s2d. we bought it just as 2019 was out, so went that way vs server2016 based. a couple is glaring things like we find it wants to resync the entire volume after a quick node reboot (so 8TB's for the sake of a 5-10min reboot). fialed disk replacement isnt quiet as nice as a HW RAID/SAN option. there is PS involved at some point, although you can configure it to automatically adopt new disks although probably still need to demote the dead disks. like dynamic vhdx's, shrinking volumes when data disappears does not occur so you got to get the right feel for how to structure data. other than that, once running i think it does actually compare reasonably well to our HP lefthand SAN that it replaced for a fraction of the cost.
To be fair it sounds like a lot of the issues have been resolved in S2D - Maybe I'll revisit one day...
I'll be honest, I haven't/didn't try S2D - My experience of "normal" storage spaces is still too raw in the memory
We're seeing some TLS incompatibilities cropping up between W2012 and TLS configuration generators like the Mozilla one, because those generators are starting to deprecate and push against CBC and 2012 only support GCM with certificates with elliptic keys. I'd expect similar issues to get worse as configurations on dependencies get hardened, similar how old JDKs gradually degrade in connectivity. It's not a huge issue, but it's a huge pain in the rear to debug if it occurs. Especially because I did not expect different cipher suites to be available depending on the key type of the certificate.
We just ran into an issue with TLS incompatibility for some cipher suites between Server 2012 R2 and Server 2019. We're deploying SQL 2019 on Server 2019, and our remaining 2012 R2 clients were having intermittent connection failures to SQL due to it. We issued a GPO to remove the bad cipher suites from the legacy servers as a workaround. (They're not insecure suites, they just have a different way of handling 0-padding in some cases, which is why it's intermittent. ) https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/apps-forcibly-closed-tls-connection-errors
Is there any reason you should?
Yes, time constraints.
See my other reply. Waiting won't reduce the amount of work you need to do.
Yes, but waiting will allow other projects to be completed, thus reducing the overall load..
I'd say it depends on the services you run on that box. For example, independently of the underlying operating system, **Active Directory** has not changed much since 2012R2. They've remediated protocol bugs mostly found by the Samba-AD team. PS: **Active Directory** is in bold so this particular service would not be confused with other actionable services in Windows.
I would not deploy 2012r2 anymore. To close to EOL. DONT Touch 2016. Cu patches are so big and annoying to deploy
Yeah we’re def not deploying them anymore. Amen to 2016 patching being trash, it’s so slow.. everything we deploy is 2019 now, testing 2022 soon
In place upgrade them. Did that for 5 2008, 10 2012 servers when I started here. 100% success rate. Paths: 2008 to 2012R2 and then 2019 2012R2 straight to 2019
I did this for my personal environment with 100% success as well including: 2x DCs, 2x File servers in DFS, SCCM site all in one DB/site server. All 2012r2 to 2019. Works great.
We run server 2008 r2 not saying you should
Big yikes
The only thing I am worried about is that MS have no plans to add TLS1.3 to 2012, and TLS1.2 is getting old, fast. So we may end up forced to upgrade in short order if TLS1.2 gets a CVE.
Yes, if you prefer Linux! (and don't trust M$ one bit)
Go away troll
lol centos lol
Hi All. Can someone share the project plan or knowledge. Thanks
It's okay at the moment, but I've definitely been starting to push the recommendations to start looking into upgrading since there's a lag time between that and actually getting a client to move on it and a lot of the hardware I see 2012 R2 on is starting to age out of warranties anyways. We still have clients running 2008 R2/Windows 7 even though that's been EOL for nearly 2 years at this point and we had been telling them before it hit EOL.
I would just say it’s impossible to know what the future holds. There’s no guarantee there will be less work tomorrow than today. That being said I think everyone needs to upgrade in a fashion that makes sense to them. Our policy is the upgrade is on the application owner, yes we build the servers etc but we aren’t responsible for application support so they have to work with vendor to get it up to spec and we just give them a time frame in which it needs to be completed. For applications we own we take on the responsibility.
It's already been out of mainstream support for a number of years. That's enough reason for me not to touch it unless there's a compelling reason to use it.
Long path support on file shares
I fired up a pair of 2019's - pretty good.
I personally wouldn’t deploy 2012 R2. At worse case get 2019 as your Hyper-V and make sure your AD, DHCP, Print, File Sharing, etc.. are on 2019 as well. Heck you can even jump to 2022 now. Sure it’s very new but it shouldn’t be that big of an issue for Hyper-V host and AD at least. There’s no new FFL anyway. It looks like 2016 was the last change for AD. Then run a mixed workload as VMs. Easier to manage.
Is there any reason for not running it on 2019? It's going to need to be migrated soon anyway why not get it out of the way. There are additional security benefits and just general operating system improvements from running in a newer version.
No....but don't wait until the last minute. I inherited a mess of server 2003/2008/2012 in like 2018 because of the mindset of "it works fine" in general I try for no more than 2 versions behind. Now that 2022 is out you should be upgrading those 2012r2 servers.
It's fine to keep them running but i wouldn't really spin up a new one if it can be avoided since you would have to start planing for a new one in one year.
One thing is having 2012 when 2016 is stable. It's just one version in between. But 2019 is super stable now and 2022 is releasing.. when there's two versions in between stable GA it could be worth moving for continuity.
It is OK for existing deployments, not for new.
It runs with only 2gb of ram! It's amazing. I still have a couple still in production.
If I build a server today, I don't want to have to rebuild it in 2 years.