SQL Saturday #70 is officially in the books. There's some administrative stuff: I will do a blog post about lessons learned, the committee needs to meet and discuss the event and start planning for the next one (likely .NET related in the fall), and I've got to compile the speaker evaluations and get them out this week. But that's small compared to putting on the event itself. And that means I can shift my focus solely onto the next professional engagement: SQL Connections, a part of Dev Connections, which is scheduled for March 27-30 in Orlando, Florida.
I'll be giving two talks, one on my bread and butter, security, and another on Windows internals for SQL Server professionals. I'm admittedly more nervous about the second one because I'm used to giving presentations on security. However, I'll be doing a couple of internal talks this week on Windows internals within my organization, so that should help a lot. Why should you come to either session? Let me talk briefly about what each one is about.
The first one is a departure from typical security talks in that I'm not interested so much in steppy procedures or well trodded topics like how to choose a good password. You can view your company's latest security awareness video for that. We're going to instead talk about the typical attack methodology and how an attacker might use it to go after your SQL Server. We're going to look at things that aren't typically looked at, like physical access and how to pen test that, considering the network when tightening down your SQL Server, and what else is running on your SQL Server which may be a back door for a malicious but authorized user. We'll also cover what to do inside SQL Server to simplify your security design while still tying everything down. This means getting into the mindset of that malicious person and viewing SQL Server as a fortress to breach and looking for weaknesses rather than trying to breach the wall itself.
The second one looks at memory, CPU, scheduling, and the like to understand why SQL Server does some of the things it does and how the Windows system can influence SQL Server. I'm not a Mark Russinovich or David Solomon, but I'll do my level best to peel back some of the layers of the operating system so you can see its effect on Microsoft's premier database platform. You don't have to be an operating system expert to be a great DBA, but the more you know, the more you can use to run your SQL Servers better.
If you are interested in attending SQL Connections, be sure to use the “DevCon1” discount code to save yourself $200 off the registration. I'd love to meet you and hang out with you if we've never met before or catch up if we have. Check out the lineup of great speakers. It's humbling to be on the same page as them.
