As we all know there are many features in SQL Server that have been deprecated over the time by Microsoft for one reason or another. In fact, there is a long list of features that are deprecated in the latest SQL Server 2017 release.
It is far less often that any of these features make a comeback, however that can apparently happen, as I just witnessed last week.
One of the more important duties of a DBA is to make sure that their databases and the data is secure. In this post we’ll be looking at two utilities to increase the security of your server, the Windows Firewall and an antivirus software. Like with about everything else related to servers, you can’t just switch these on (well, you could, but…) and forget about them to get the best possible experience. They need to be properly configured for servers running Microsoft SQL Server. If you’re a DBA you might not be doing the configuration yourself, but you still need to tell your Windows administrators what they need to do.
Continue reading “Windows Firewall and antivirus software configurations for SQL Server.”
Just a friendly reminder to everyone that just like all good things come to and end so does the extended support for these two Microsoft products. First will be the Windows 2003 R2 with the end of lifecycle date set to July 14 2015 and soon after that SQL Server 2005 with it’s end of lifecycle date set to April 12 2016.
You can still run these products after these dates of course but it’s definitely not recommended and the reason is simple. End of the extended support means that neither of these products will be receiving any patches or security updates, ever. So if you’re not already working on upgrading them, now would be a good time to start.
Continue reading “End of Lifecycle for Windows 2003 R2 and SQL Server 2005”
Just a quick tip this time, but one that can save you lot of time and manual work.
One of the information sources that all administrators, both Windows and SQL Server alike, should follow is the Microsoft Knowledge Base. However as there are new articles coming in daily, going to Knowledge Base and manually searching for them isn’t really a viable option. Even less so if you’re responsible for administering multiple versions of Microsoft software.
After setting up the SQL Server ready for encrypted connections, it’s time to do the same for the clients. This is basically the same process that we already did at the server end, but let’s go through it once more. Instead of inbound firewall rule, we’ll create an outbound rule (surprise!) and connection security rule.
To set up IPSEC for a box running SQL Server starts with a simple step, by turning on your Windows Firewall with Advanced Security, if it’s not on already (which it definitely should be!).
After that you need to create two rules for your firewall. First the inbound rule, which allows the clients to connect to your server. And secondly a security rule, in which you define how the connections are authenticated and secured. You could do this directly from the firewall settings, but I prefer using Group Policies myself.
A first post of 2014 and it sure took me awhile to write it up. I was hoping to return to this subject much sooner, however my work schedule has been just plain crazy. Just this week I’ve spent two nights migrating databases to new database clusters. The situation should fix itself in a couple of weeks though, with few bigger projects coming to completion.
But to return to the actual subject of securing SQL Server network traffic.. I previously wrote about using SSL for this purpose, a method that was quick and simple to implement. This was done in my Azure demo environment, which allowed me to take few shortcuts in the implementation. When dealing with production environments, you’ll naturally need to test, test and test it once more before actual implementation.
