Automatic software updates: An overview

For Windows users, software updates are a regular part of life. Vendors like Microsoft, Adobe and Oracle are constantly tweaking their software, which then inundate us with “helpful” nudges. This prompt from printer manufacturer Brother International is a prime example:

Most of the time, you have to install software updates manually. That is, you must take deliberate action to approve and apply the upgrade. For example, in the screenshot above, the new printer driver will not be installed if we never click the “Update” button.

But while manual updates remain the norm, an increasing number of vendors refuse to be held hostage by reluctant users. They choose to deploy software updates automatically, on their own schedule, without securing explicit consent. Products like Dropbox, OneDrive, and Box Drive are members of that new “vendor knows best” group. All apply updates whenever they like.

Yet despite the faint whiff of authoritarianism, automatically installing software has many benefits. To begin with, busy users don’t need to be remember to check for updates or be interrupted to install new packages.

And most important of all, automatic updates have the power to stamp out critical vulnerabilities — quickly and efficiently.

However, those positives are only appreciated when the updated application works as expected, with no surprises. From our own experience, there is nothing more infuriating than software that breaks itself without our consent! 😡

The problem with automatic updates in a 24/7 environment

For mission-critical applications that must operate continuously, updates introduce significant risk. Each change to the application (or the supporting operating system) has the potential to cripple the software — and send blood pressures skyrocketing.

The best practice is to update systems in a controlled manner. Experts agree that it’s safest to make changes during a scheduled maintenance window, when customers are aware that there may be a disruption of service.

After applying updates, staff test and certify the upgraded system. If the team discovers a formidable problem, they roll the system back to the pre-update state to resume service.

Needless to say, automatic updates are the antithesis to a controlled upgrade process.

Indeed, automatic software updates will leave you wondering:

• For how long will the software be unavailable during the update?

• What happens if the upgrade fails?

• How quickly will you be able to restore service if the new software doesn’t work?

Those are very difficult questions to answer when the upgrade process is out of your control.

Running 24/7 with AlwaysUp is at odds with automatic updates

If you’re using AlwaysUp to run an application 24/7, you will likely run into trouble if that application insists on randomly updating itself.

To explain why, let’s examine how most automatic software updates work (without AlwaysUp involved).

Once per day:

1. The application:

   1. Checks online and realizes that an update is required

   2. Downloads the latest package from the servers

   3. Launches a “helper” application to perform the upgrade

   4. Exits (because integral components cannot be updated while the application is running)

2. The helper:

   1. Upgrades the application, adding and replacing executable files as necessary

   2. Restarts the application

   3. Cleans up and exits

Unless interrupted, the new version of the application continues to run until the next update is detected and the process above repeats.

Unfortunately the update process can go off the rails when AlwaysUp is ensuring that your application is running 24/7.

Specifically, the trouble starts when the application exits (step 1d). In response, AlwaysUp springs into action and quickly re-launches the application.

And when the helper tries to apply the upgrades (step 2a), it cannot update the executable files because they are in use by the (once again) running application. Ultimately, the helper fails, potentially leaving the application’s components in an inconsistent state. That could spell disaster for a business-critical application!

In fact, one of our customers recently experienced this peculiar predicament when running Dropbox as a Windows Service with AlwaysUp. After a failed auto-update, Dropbox simply refused to copy files to and from the cloud. Fortunately, a technician resumed normal operation by rebooting the server — but only after the customer’s pipeline had been idle for several, costly hours. It was not a good day. 🙁

The best solution: Turn off automatic updates

Naturally, the best solution for business-critical applications is to avoid automatic software upgrades entirely.

And if you’re lucky, your application provides a simple mechanism to disable auto-updates.

For instance, you can easily turn off automatic update checks for the Java Virtual Machine from the Java Control Panel:

For other applications, you may have to cripple (or remove) one or more scheduled tasks that periodically check for updates.

In particular, disabling the OneDrive Standalone Update Task will prevent OneDrive from trying to download and install the latest changes each day:

If you can’t disable automatic updates, configure AlwaysUp to tolerate them

To avoid drama with mandatory auto-updates, please make the following two changes to your AlwaysUp configuration:

1. Introduce a delay before AlwaysUp restarts your application

By default, AlwaysUp restarts your application immediately after it stops. But as we have pointed out, that rapid re-launch can cause headaches for the update process.

To get around that problem, instruct AlwaysUp to restart your application after waiting for a few minutes. Doing so should allow the update process to finish.

To make that change:

1. Edit your application in AlwaysUp.

2. Switch to the Restart tab.

3. Check the Not immediately and After boxes and specify a suitable delay.
   Five minutes should be enough for most automatic upgrades to complete:

Note however — this delay applies to all situations, not just for auto-upgrades. That is, if your application exits or crashes for any reason, AlwaysUp will pause before restarting it. Hopefully that behavior is acceptable in your environment.

2. Empower AlwaysUp to retake control after an automatic upgrade

After AlwaysUp waits for the update to complete, it will launch a new copy of the application. But that launch can fail if the application is already running.

To remove that potential hazard, we must instruct AlwaysUp to terminate all other copies of the application prior to starting its own copy.

To do so:

1. Edit your application in AlwaysUp.

2. Switch to the Startup tab.

3. Check the Stop all copies of the application running on this computer and Also whenever the application is restarted boxes:

This adjustment will allow AlwaysUp to “take control” of your application after the upgrade concludes.

Best of luck with your 24/7 environment! 😀

You may also like...

AlwaysUp 10.5: Restricted Rights, Smoother Shutdowns, and more

Q & A: What Setting will Help AlwaysUp Start my App at Boot?

ChatGPT Knows Windows Services