Yesterday I presented two sessions at the Pittsburgh SQL Saturday.
The first was a session on using Service Broker to design more scalable applications, and everything went really well. Overall the evaluation comments were positive, though I had one person who suggested I pre-install the Service Broker External Activator. Honestly, I did that install in the session to talk through some of the “gotchas” I encountered when implementing that great service in a client environment. I understand the sentiment, but I think it helped prepare the attendees to use that feature more effectively.
My second session was my Emergency session, which is focused on making sure you’re prepared should disaster strike your data center. I talk about recovering from ransomware as the prime example, as I see that happening more frequently. The demos failed, because for some reason my virtual machine blue-screened as I was trying to install SQL Server. I talked the group through the scripts I provided to complete the recovery. (There wasn’t time to re-install the operating system in a new VM and start the installation again.)
Again, the comments I received were mostly positive, and reflected the value of the material I provided. There was one, though, that prompted this blog post.
“The talk should be updated for SQL 2016 and beyond. I wouldn’t think anyone would be installing 2012 or 2014 w/ 2019 on the horizon.”
When your company is hit with ransomware your first responsibility is to get your systems back up and running as quickly as possible. If your existing systems are still running old versions of the operating system, or SQL Server, any attempt to restore those databases to a newer version means you’re now testing an upgrade.
In my session, I make frequent reference to a pilot’s responsibilities when flying an airplane. In that light, testing an upgrade is like flying the plane outside of the documented limits of the aircraft. As my flight instructors put it, “you’re now a test pilot.”
What I’m saying here is that your responsibility is to get those systems back up and running as quickly as possible, without changing anything. If your server is still running SQL Server 2014 SP1 on Windows Server 2012 R2, then your responsibility is to get those exact versions installed. That’s your quickest route to success, and that’s why I chose those versions for my demonstrations.
(The demo fail was just that. I’ll resolve it before I give this presentation again at the PASS Summit in Seattle next month.)