You may have seen one of the 1,000,001 Tweets, blog posts, and other warnings around SQL Server 2005 end of life, and prior to that, Windows Server 2003 end of life. But there is something else intrinsic to SQL Server that you also need to worry about making sure you are up to date which affects later versions of SQL Server you may be running: the .NET Framework.

If you’re using SQL Server 2012 or later, one of the required components is some version of .NET Framework 4.x. Windows Server 2008 R2 did not ship with .NET Framework 4.x, so you would need to install it on your own or have SQL Server do it. This is known as out of band. Windows Server 2012 shipped with .NET Framework 4.0 and Windows Server 2012 R2 shipped with 4.5. This is known as in band. The good news is that for installations of SQL Server 2012 or later, you would not have to install or enable .NET Framework 4.x; it’s just there.

Like any other component, the .NET Framework needs to be managed, maintained, and updated. Depending on how .NET Framework was installed/configured, either it will be managed as part of updating Windows (in band versions), or you will need to manually update if it was installed separately (out of band, such as .NET Framework 4.x on Windows Server 2008 R2 or if you installed .NET Framework 4.5 on Windows Server 2012).

Microsoft recently published an official .NET team blog post reiterating that .NET Framework versions 4, 4.5, and 4.5.1 will no longer receive security updates, support, or hotfixes as of January 12, 2016. This was first announced back in August of 2014, so it’s not like this is new news, but I can say from experience virtually no one is talking about it. MS’ new post talks more about the upgrade path. To sum it up, you need to install .NET Framework 4.5.2, 4.6, or 4.6.1 to be considered supported when it comes to your .NET Framework version. Security is a real issue for many, and those responsible may not know that your version of .NET Framework could be a possible attack vector. Is your security team aware of this impending problem? How will this affect your version matrices (you do have those, right?)?

The bigger question is this – have you even planned for this event in your environments for both servers and any clients or application servers that run or connect to SQL Server? Have you been keeping up with .NET Framework versions or did you just install SQL Server and forget about it? I would say that most people I encounter fall into the latter. Staying supported is a key component of being mission critical.

If you haven’t thought about updating/patching your .NET Framework version, now is the time to start planning the upgrade to your preferred, supported, and tested version of .NET Framework in your environments. If you do not test against your applications, you could possibly encounter problems. In other words, without testing you are rolling the dice. That is anti-mission critical and can lead to downtime.

Another question you have to get the answer to is this: who owns this upgrade? Is it the app owner? The DBAs? The sysadmins? The .NET Framework can be a bit of a grey area depending on the server and how it was installed.

Here’s a tip: if you’re considering 4.6, just go to 4.6.1 – you’ll not only have a longer shelf life of supportability, but they enhanced the behavior of MultiSubnetFailover (see this blog post for more information) which could benefit some Availability Groups implementations (I am trying to verify if it applies to FCIs; it should as well …). To help you get to green faster, here are some handy links:

  • This is the KB article to get information on how to download .NET Framework 4.5.2 as an offline installer (including desktop OSes and all Windows Server OSes).
  • This is the link article to get information on how to download .NET Framework 4.6 as an offline installer (including desktop OSes and all Windows Server OSes
  • The blog post linked above for 4.6.1 has links for its download.

If you need help planning or implementing your upgrade strategies, let us know.