It’s amazing how far we’ve come in the near 20 years I’ve been working with some form or another of SQL Server or another RDBMS. But I’ve seen one constant: bad configurations – especially Setup or the underlying OS – can lead to big problems. Think about it for a moment. Your journey on your platform of choice does not begin when it goes live in production. It begins from day one of the decision, and follows through to when the hardware comes in. You get the idea. Skip a step along the way, make a shortcut here or there, and you may wind up with some expensive downtime in the future.

Having said that, the focus in this blog post is really going to be on the software installation process. Sometimes the problems associated with such deployments are purely human error, poor planning, or both. Both of those scenarios are, for the most part, preventable. There’s no excuse to have a poorly planned implementation these days or a way to test things out since virtualization has become cheap and easy. My ire is going to focus on something that users and implementers alike can’t control: crappy installation/setup code. It’s not rocket science to have a decent Setup UI as well as scripted implementation for setup … or is it?

The installer is one of the most important pieces of the software experience. A good one leaves a positive impression, a bad one leaves a horrible taste in your mouth. Some can be overly complex, others too simple. There’s a happy medium.However, the end result should be a fully installed, stable application. Sometimes this is not the case. Being an availability guy, you can see where this causes some issues for me. The reason this happens is poor code, or worse, poorly tested code. There’s NO excuse for an installer not working right. But I believe that in most companies (not pointing any fingers), the focus is on features and functions – not such a seemingly simple, yet important, piece of the puzzle. I bet Setup is often an afterthought. I have no proof of that, but it’s a strong hunch. Much like what I do, Setup isn’t sexy. It doesn’t sell product. Features do. Planning and availability don’t have instant gratification like taking a query from 20 minutes to 2 seconds, but boy, not having that stuff or doing it right will bite you later when you are in a fix.

With customer environments being increasingly complex, I’ve seen some stupid things over the years. For example, assuming everything will go on a C drive or have “cluster support” that really isn’t any kind of support – installing on each node as if your product is standalone is NOT really what I’m looking for.  I shouldn’t have different installation experiences via command line, say, via Server Core or the “regular” version of Windows. Don’t run stupid checks and tests that don’t matter, yet consume large amounts of time. Yet I see these types of things all the time.

Patching processes are just as important. I should hopefully be able to patch your software with minimal to no downtime. Do NOT reboot my box without me allowing it or choosing when it happens since you may not be the only thing running. Patching is an extension of your Setup processes, and MORE important when it comes to availability since systems are already in production. Some of us are trying to maintain SLAs that will be blown by your automatic rebooting.

So to all you vendors providing software: wise up. Be more flexible. Understand that one size does not always fit all. TEST YOUR STUFF. Don’t increase my downtime – especially via unprompted (and unexpected reboots). And for heaven’s sake, be transparent. Don’t do things behind the scenes that will only be discovered later by reading logs or finding files in places that are not expected.