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.
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.
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.
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.
Going back a few years (and then some), creating your own test environments used to be difficult requiring both time and hardware resources. Then came the different virtualization solutions, which made it bit more easier but still requiring decent amount of hardware resources and a little bit of time. With the arrival of Azure and other cloud-based solutions, things finally got considerably easier. Now we finally had the ability to set up a test environments quickly and easily.
I ran into and old issue recently I hadn’t seen in a while. A database server was experiencing some intermittent performance issues that didn’t make much sense. It didn’t take me long to figure out what was going on though, after firing up the Resource Monitor.