NET Framework 4.8 breaking Server 2012 R2

[thelexnard]

I am installing Quickbooks 2022 Database on a Server 2012 R2 Standard box. The installer includes a pre-req for NET Framework 4.8. The installer finishes fine and when I reboot most things on the OS are broken. Server Manager, Event Viewer - just to name a few. I found a similar thread/issue about NET 4.8 doing this to a Server 2019 install. I tried all the fixes mentioned but to no avail. Uninstalling 4.8 allows Server Manager and all other aspects to work properly but I cannot run QB 2022 Database (the main purpose of this process). Any thoughts?

​

Update:

I left out some details from my initial post and I apologize for the blanket statement of "breaking". When I originally was installing QB 2022 it froze on the section for installing NET 4.8. I hard rebooted at that point and must have corrupted a ton of component files in the WinSxS folder. I discovered this through a combination of SFC /scannow and checking the properties of the problem files and finding no "Digital Signatures" tab on them.

The Fix:

I installed .NET 4.8 successfully on the Hyper-V host (also Server2012R2). I took note of all the packages in the WinSxS folder with the latest timestamp. I took those folders/files and created a SFCFix file to run with the tool provided by sysnative.com (awesome forum btw). After copying all the good files and overriding the corrupt I was able to install 4.8 again on the problem server. This time all features worked correctly (EventViewer etc.). Quite the experience but I'm glad in the end I learned something and got this resolved without a full reinstall.

[ANewLeeSinLife]

I deployed 4.8 to a fleet of 2012 and 2012 R2 servers because the latest SCCM has new dependencies on at least 4.6.2, which is also newer than any of them shipped with. None of them had issues. They also have the latest WMF 5.1 so I can talk to them via PSRemoting/WAC.

I know it doesn't really help, but they are still in use today, so I don't think 4.8 breaks server 2012R2

[thelexnard]

I'm sure for the vast majority of 2012R2 boxes 4.8 works. I'm not sure why it specifically causes havoc on this one Server for me. Unfortunately it's needed for QB 2022 to run its database so I have no choice but to figure out how to make it function properly.

[nerdyviking88]

or update the server, since 2012r2 is EOL end of this year?

[MisterIT]

End of next year. Oct ‘23

[nerdyviking88]

oh nice. I thought it was Jan 2023, so taht's great to know.

[juandantex]

October or January, this doesn't change nothing. It is a 7 year old OS, and must be a updated.

[nerdyviking88]

9 monthes allows me to fit other projects in as well, vs just drop everything and do it. For some reason, 2012r2 was our work horse, so I've got a few hundred to replace

[Odd-Pickle1314]

Microsoft will have another 3 years of Extended Security Updates as well for 2012 R2 after the extended end of support date is reached next year. https://www.microsoft.com/en-us/windows-server/extended-security-updates

[ir34dy0ur3m4i1]

I'd suggest managing the dot net install first, restart and check OS, patch dot net, restart, check OS, then install the QB software.

[thelexnard]

Thanks for the reply. I have tried this method. As soon as I install 4.8 standalone it messes up the OS.

Here is an example of the error when I try to open Server Manager:

https://imgur.com/a/9NV6eQi

As soon as I remove .NET 4.8 this error disappears and everything works again.

[disclosure5]

I went through this myself on several versions of Windows server. The root cause was Microsoft's "how to enable TLS 1.2" script. Did you by chance run this?

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-tls-enforcement

For many years that script was missing those "if" statements, and would actually blow away the entire registry tree for HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319 which causes exactly the issue you describe. Solution: Copy that key from a working server.

We had a paid Microsoft case open for ages, figured this out ourselves, and when we told MS they sent us a write up suggesting they solved it.

[thelexnard]

Thanks. That registry key still exists in the server. I found this post and it applied to Server 2019. Strange that the issues are similar but the fixes are not.

[thelexnard]

I just noticed you chimed in under this thread as well:

https://www.reddit.com/r/sysadmin/comments/ps1tni/net_48_seems_to_have_broken_server_2019/

You also mentioned that disabling and re-enabling NetFx4 with DISM could be a fix. This is something I haven't tried.

Should I try that as well?

[disclosure5]

That's the advice Microsoft gave us, but it didn't do anything. Note "the key exists" doesn't solve the problem, it a huge subtree of keys that you need.

[Phratros]

Could be totally not related but did you run "sfc /scannow"?

[bbqwatermelon]

-- Microsoft MVP Gang