What do you dislike about installers?

We’re in the middle of designing the SQL Response 2 installer at the moment. We’re trying our hardest to make the installation process as painless and as user-friendly as we possibly can. So, we’d like to know:

What irritates you most about installers?

  • Have you installed a product recently where the installation process really annoyed you?
  • Or have you ever had a pleasurable experience with an installer?
  • What do you think are the most common mistakes software developers make when designing their install process?

As a SQL Server monitoring application, SQL Response requires access to your physical servers and SQL Server instances to collect data to show you. This inevitably requires some initial configuration to allow this communication to happen. What are the issues in your environment that may make this difficult?

An early storyboard of the installation process

An early storyboard of the installation process

This entry was posted in Designs. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. PDinCA
    Posted September 3, 2009 at 7:51 pm | Permalink

    Installers that cannot update the quick-start shortcut I copied are very annoying. Sadly this is true of all Red-Gate installers…
    An option to “add to quick start menu” would help – everywhere…

    Installers that say the remote server install is Ok but all that happened was the script ran without bombing is time wasting. We need to see what actually happened…

    If a product is already installed, you know everything about it from the registry, so omit “dumb” questions for updates to a version, just install it!

    If you are installing a “new” major release and there are configurations from a prior release, make it automatic from the outset to copy and upgrade them for the new version. SQLPrompt was an example of a bad installer for the early access versions of v4, for example.

    The fewer clicks I need for an install, the better the experience, and there are many that behave that way.

    The multi-tool install/upgrade capability of SQL Toolbelt is actually VERY helpful – everything in one place, well explained what one can do – a good job.

    A common mistake is to assume a high level of either actual knowledge or knowledge of acronyms such that the novice is left scratching their head when asked to make install decisions. If there are decisions to be made, the pros and cons need to be enumerated in as straightforward a way as possible. Remember, just because those of us in very small shops are called upon to perform DBA or SysAdmin tasks doesn’t mean we have intimate knowledge of the breadth and depth of those areas.

    Thanks for asking – openness in this way is a heartening policy to see.

  2. SteveW
    Posted September 3, 2009 at 9:28 pm | Permalink

    My most consistent complaint about installers is the level of application configuration decisions that must be made within the installation process, vs. doing the minimum to get the bits on the disk and then doing the config separately. Several reasons for this, but two stand out: I may have a very limited window in which I can have a server offline to install or change an application, restart if necessary, so time is of the essence. Or, handing a limited installation guide/script to a non-expert — but someone who is authorized by role to do the install — is key. In either case, if I can come back later to do the more complex configuration, that is preferred. Thank you guys for considering this part of the application/solution deployment process — it’s appreciated!

  3. Jonathan Allen
    Posted September 4, 2009 at 10:44 am | Permalink

    A small niggle is the fact that I have to re-apply my serial number for products after an upgrade. Could this not be collected from the previously registered product?

    I would also support PDinCA’s comment about acronyms, it is wholly likely that your tools will be helping a person in a small shop where a seasoned DBA is non-existant.

    Our proxy server seems to cause the check for updates process to fail across your whoile product range, is there a chance that we could have an option to get and email from Red Gate – tied to our software license – that notifies us of upgrades to products we have purchased? If this were weekly/fortnightly then we could schedule upgrades accordingly.

    Is there worth in having a Red Gate Console application that could manage high level settings for installed products and also launch the products if needed? This could sit in the sys tray/quick start and reduce the annoyance of products not updating the quick start? If it was sys tray then when clicked/hovered it could offer launch and configure options … ? The Console could even have traffic light indicators from the likes of SQL Response (alerts and recommendations), SQL Backup (failures/warnings) to highlight points that need urgent attention.

    Thanks also for the option to get thoughts in at this early stage of development.


  4. Mark Allison
    Posted September 4, 2009 at 3:09 pm | Permalink

    I’ll tell you what really annoys me about installers – a prime example is the Red-Gate SQL Backup tool (I’m talking version 5.4), perhaps v6 is better I haven’t tried it yet. To install SQL Backup server components from the GUI is impossible when in a clustered environment. I would like the installer to be intelligent and know what environment I have. It gets worse – when using the SQL Backup SQBServerSetup.exe file to install the server components, this couldn’t install an instance of SQL Backup across all nodes in my cluster correctly. I had to resort to installing the thing 20 times (because I have a five node, 4 SQL instance cluster). As part of the installation I was also required to hack the registry and go into the services.msc applet manually. These kind of things are very time consuming, and prone to error from a user perspective.

    Activation is another annoyance. Either get rid of it all together or ensure it can work properly with minimum user input. I don’t want to send activations by email because your tool can’t work behind a corporate proxy.

  5. Tom.Randle
    Posted September 7, 2009 at 4:16 pm | Permalink

    Thank you for all your comments and suggestions. It’s really great to get this kind of feedback. Specific responses below:

    We’ve added your comments on quick start shortcuts and the quick start menu to our bug tracking system.

    SQL Response 2 won’t install anything remotely. We’re going to take a simple approach and require you to copy the installation executable to the specific machine you’d like to install to, and run it from there.

    Updating software can be problematic, but we’ll try our hardest to make it as smooth as possible:

    • To try and reduce the number of clicks required, especially for the evaluation period, we’re going to offer a ‘quick install’ option. It won’t be advanced enough for all users, but it will allow you to install and run SQL Response quickly, using default settings. We will try and explain very explicitly in the install wizard what these settings are, and how to configure them later, following installation, if you subsequently need to move or change anything.

    • We’re trying to be as ruthless as possible about the number of mandatory options in the installers, and our intention is to make the design process as straightforward and intelligible as we can, so that even a non-specialist or part-time DBA can complete it successfully. A monitoring tool requires several components, typically installed on different machines, and knowledge of various domains & use accounts and so on, so there is no magic bullet to make the installation as simple as some of our other tools; however, our experience of usability-testing Version 1 has taught us that we need to create a more user-friendly experience, that guides you effectively and efficiently through the steps.

    There will be an installation guide aimed at the non-expert user, taking you through the architecture and installation steps in as simple and understandable a way as our technical author can explain it. Most probably, this will be available both online and as a PDF.

    In SQL Response 2 we’ll strive to ensure serial numbers don’t need re-entering following every update.

    We’ve logged a bug in our bug tracking system about your comments on email updates and the console application. It’s an interesting idea, and one we’ll pass on to our development managers – clearly, this would be a project in itself, so it needs some consideration about the cost/value ratio.

    Sorry about the problems you’ve encountered with SQL Backup. Have you raised this with the Backup team directly? We’ll pass on your issue to them, if not.

    It is our intention that SQL Response 2 will work as seamlessly as possible with clusters. As is currently the case in v1, Response 2 won’t actually install anything on the servers we’re monitoring.

    We are looking at the issue of multiple activations, as we are aware that many users will want to license a number of servers at once, without having to individually enter keys. This is in the requirements for version 2.

    Thanks again everyone for some really interesting feedback. Installation and licensing is a very complex area, so this kind of dialogue is invaluable in our quest to make it as painless as possible.

  6. Priya Sinha
    Posted September 8, 2009 at 11:49 am | Permalink

    Hi Mark,

    I had few questions regarding your usage of cluster.

    Would you use SQL Response to monitor a clustered SQL Server instance or would you install the SQL Response UI or Alert Repository on a cluster?


Post a Comment

Required fields are marked *

Add an Image


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>