When it comes to finding information or learning more about the SQL Server and it’s features, the professional community around the product is one of the best ones I’ve ever seen. I personally have a score of SQL Server blogs in my bookmarks, I visit SQL Server forums and follow a bunch of world-class experts in Twitter. Basically, there’s a wealth of information out there and unlike many other things in this world, it’s completely free.
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.
It has been couple weeks since my last post and as we’re going through the end of the year frenzy at the office, I find myself having little energy or time left after work to finish up my posts (I do have a couple of other posts waiting to be finished).
I previously wrote about different methods on how to secure the network traffic on your SQL Server. I mentioned there being two readily available tools that can accomplish this, the SSL and the IPSec. In this post, we’ll take a quick look at how the SSL is implemented on SQL Server.
A while back I had a request to encrypt communications between an instance of SQL Server and the clients connecting to it. I knew that SQL Server had the ability to use SSL to encrypt communications, so this all seemed simple enough to do. The easy way, however, didn’t work for me because of some of the older protocols used did not support SSL encryption. So I was encouraged to look at some other options.
Figuring out possible causes for performance issues is one of the core skills for any DBA. There’s a whole bunch of tools for it, but this time I’ll be writing about one of my favorites. The Performance Monitor (PerfMon), which is included in every version and edition of Windows Servers and workstations. PerfMon and I go back a long way and we have had a most satisfying relationship so far. Naturally there have been some rocky spots over the years, but we have never drifted apart.
At the final part of my three-part series on how to set up your own test environment into Azure, we’re joining our SQL Server into Active Directory and downloading a database to use for testing.
In previous post, Part 1: Creating Azure Network and Storage, we set up your Azure account ready for two virtual machines that’ll be the backbone of your own testing environment. One of these servers will run the Active Directory and the other one will host your SQL Server 2012 instance. The Active Directory server is really optional, you can do a test environment without it but I prefer test environments that mimic the production.