I’ve sent my slide decks to the organizers, but I know they don’t always get posted. So I’m putting a few links up here for my talks.
If you check the page for my Preparation for Disaster talk, you’ll find I have links for the two recent events to the decks. I often version the decks after talks, and so I’ve decided to keep all versions live.
I’ve also uploaded the decks from PASS if you’re interested.
PASS Summit 2011
SQL in the City – LA 2011
SQL Server Connections
Today we have an editorial that was originally published on Aug 31, 2006 as Steve is traveling at DevConnections.
I’ve followed the development, release, and subsequent news on SQL Server 2005 for over two years now. It’s been an interesting journey and I’ve had the chance to see some evolutions in the product over time as well as observe the reaction to different subsystems.
At the Colorado Code Camp, where I got roped into speaking, I was asked what I thought was the part of SQL Server 2005 that had the most impact. I’m not a heavy user of the product, but since I gather, edit, and follow the news I answered that Integration Services was one of the most written about, blogged about, newsworthy systems. It seemed more people were really excited about SSIS than anything else, despite the fact that I think the Service Broker and other technologies are “cooler” to me.
So when I saw some people knocking SSIS, as well as this blog post by Jamie Thomson, I decided this would make a good poll.
I’m not a BI guy, and not deep into the ETL world like many of you out there. However it does seem to me that while it may not offer all the features of tools costing thousands of dollars, it does a great deal of the things I need in a professional ETL tool.
Most of us don’t deal with terabyte databases. We don’t roll up data from 30 separate applications into one humongous data warehouse and then spin off a dozen cubes for different departments.
I’ve done some of that on a smaller scale and I thought DTS was up to the task most of the time. Sure the error handling wasn’t great and there were times we had to restart things and do some manual cleanup or script editing, but it worked very well for most of my needs. From what I’ve seen of SSIS, it’s more robust and does an even better job of being a professional tool I can use.
As to whether it’s professional enough or enterprise ready, I’d like to know what you think.
This editorial was originally published on Jan 10, 2007. Steve is at DevConnections, so it is being republished.
So class, for today’s protection mechanism you’ll need: a mouse, a loop of wire, a lock, a key, and a link. Sounds like MaGyver, huh? This article on hot spot security gives you some software hints and covers most of the items I listed above. The exception is the loop of wire.
If you’re working for some time at a place, especially a place that’s traffic’d well, you might want to lock your computer to the desk or table. It will discourage iJacking or the chance that someone will walk by, grab your laptop and run. This is more likely in a cafe or Starbucks than an airport, but you never know.
The advice is good and it makes sense that most of the discovery and openness of Windows is rapidly becoming a liability. Even out here in the country, where I live and my nearest neighbor is nearly 1/4 mile away, I have keys on our wireless routers. I know it’s not the best security, and I did get some complaints about making everyone have a key until a neighbor’s router showed up on our computers. Makes you realize just how far away someone could be and reach your system.
As handy as all the capabilities are in wireless networking, as with anything else, they need to be secured and they should be turned off by default. Use them when you need them, but the rest of the time, try to be a bit more secure and limit access to your system.
Today we have an editorial that was originally published on Oct 9, 2006.
Yesterday I wrote about compliance tips and one of the things I mentioned was using encryption and passwords for your backups. It’s a good idea that you should use even with disk backups. You never know when someone might get socially-engineered and hand over one of your .bak files to the wrong folks.
But using encryption isn’t enough; you need strong key management that changes the passwords on a regular basis to prevent data losses from the passwords getting released over time. I’ve worked in a dozen companies and there are many cases where a password has been used for some shared function, some application, some particular feature, whatever. If this password has remained the same for over a year, it’s been almost common knowledge throughout the company what the password is. I’ve seen business people, executives, even secretaries that knew the password to the point where it was useless.
Shared passwords will be a fact of life in many cases. Administrative teams grow, help desk people may need access, consultants help out and learn them, and others overhear them. It’s going to happen, so you need to mitigate this risk.
I used to manage a nightclub and we had similar risks with the alcohol. Since turnover was a fact of life, we had a simple policy. When a manager left, for any reason, all alarm codes were changed. On the third occurrence of a manager leaving, we had all locks re-keyed. It was a simple policy to reduce risk.
The same thing needs to happen with your backups. Use one or even a few passwords to protect the various database backups. But then change those passwords every month or two and escrow or archive the old ones. You may not be able to prevent losses of the backup files, but by ensuring they are protected and the passwords changed regularly, you may just protect the data.
And your job.
