When we started designing SQL ConstantCare® (back before we had a name for it), I listed out the main components at the beginning of the design doc:

The collector (which later became ConstantCare.exe) was the only piece that would run client-side. I wanted to keep end user support work to a bare minimum – if I could put something in the cloud, I wanted it in the cloud to keep our support costs low. It’s really easy to hop into your own cloud to dig into a problem – it’s much more painful to coordinate support calls with end users all over the world.

Then for each part (collector, ingestion, lab tech), I wrote up a list of things we had to have in the first private alphas, the first public betas, and the first version of the paid-for product. We had to make a lot of tough decisions along the way to the Minimum Viable Product – after all, I could only afford to hire one developer, and I wanted to ship sooner rather than later.

Here were the requirements for the first private build of ConstantCare.exe:

Then for v2, as we started to learn more and scale it:

Note that last line – “Self-updating.” ConstantCare.exe was the only part that would require end user intervention in order to upgrade, and I wanted to avoid that hassle. We had a brand new application, and I figured we’d be shipping rapid changes to ConstantCare.exe in order to fix bugs or collect different kinds of data.

Throughout development, I told Richie that my goals weren’t set in stone. If he tried to implement a particular goal, and it turned out to be painful, we could talk through it and change our minds. Some things turned out to be easy, so he added ’em in earlier builds, whereas some things turned out to suck.

Auto-updating ConstantCare.exe turned out to suck pretty bad.

Richie kinda-sorta got it to work with Squirrel, but for it to work, it needed to run the update as an administrator. I really didn’t want to have to hassle with end users setting up a scheduled task to run under an administrator account – if something went wrong, it could go really wrong, and our goal was lower support workloads, not higher.

We ended up scratching that goal and changed the way we ship ConstantCare.exe updates. We stayed in private beta for a longer period of time, making sure things were working well for the end users. Out of the private beta applications, we purposely picked a wide variety of server versions & types to get as much coverage as we could. Then, when we finally went public, we held off updating ConstantCare.exe as long as we could, focusing on cloud side improvements instead. Looking back, I’m glad we made that decision because we just haven’t needed to update ConstantCare.exe much, and I don’t see that changing – the big ROI is the data analysis in the cloud.

Having said that – we’ve published an update to ConstantCare.exe. To update yours, open a command prompt as administrator and type:

ConstantCare.exe will then do its regular thing of polling your servers for data, and then at the end, it’ll download the latest ConstantCare.exe and update itself from v0.16.1 to v0.20.17. You can tell which version you’re on by looking at the folder names in %localappdata%\ConstantCare.

This version runs faster because it collects less data about backups and Agent jobs – and then it uses some of that given-back time to collect index metadata. You won’t see an immediate difference in your emails, but we’re starting to build index recommendations. Stay tuned!