Is it something in the water? Suddenly, the new paradigm for software updates is "release early, release often...
and repeat." That isn't so bad when you're dealing with products that have scheduled releases every six months or so, but what if you're the administrator for an IT environment where certain end-user programs have updates published every couple of weeks?
Few admins want to deal with the hassle of updating software that often, and no admin worth his salt -- or sanity -- is going to allow users to update their own software. Nor is any admin likely to allow user software to update itself unsupervised.
Two programs with rapid update schedules are the popular Web browsers Mozilla Firefox and Google Chrome (or Chromium). Both are worthy of a closer look for examples of how to deal with the rapid deployment of software updates in the enterprise.
Method 1: Disable app updates via policies
The most straightforward way to deal with the problem is to disable the automatic updating of the application via a policy mechanism -- provided the application in question has one. Firefox and Chrome both have ways to do this, although they are markedly different.
Google has created a specific version of Chrome called Chrome for Business, which features more than a hundred different policy options for deploying Chrome. The most relevant one of the bunch is auto-updates, which Chrome for Business has marked as Enabled by default. This can be suppressed by using the NoGoogleUpdatingswitch when pushing the Chrome MSI out to your organization.
Predictably, Google's stance is that auto-updating is a good thing, because you might not receive the latest security updates if you disable auto-updates.
On the other hand, the auto-update function can silently break functionality that you need, which is at least as pressing an issue for an enterprise as a software update. For example, a recent Chrome update made changes to the way Java worked, which caused at least one browser-based application I was using to no longer work correctly.
Chrome for Business also provides not one but two updating mechanisms for the administrator. The first is Google's own Omaha Updater, which is actually the same application that Chrome itself uses to perform updates. It's also available as a standalone utility.
The second, Chrome Component Updater, keeps Chrome's internal components up to date. Halting auto-updates will keep the Component Updater from polling for changes, but again Google doesn't recommend this.
Firefox, on the other hand, has long been uninterested in providing a tool set for deployments in organizations, and it has left a lot of that work to third parties. FirefoxADM, for instance, is an open source project that allows Firefox settings to be managed through Group Policy and Active Directory.
Another tool, the CCK Wizard, lets you create an extension that allows Firefox to be heavily customized and repackaged (by way of another third-party tool) for the sake of a deployment. Whatever the mechanism, the setting "app.update.enabled" can be disabled to prevent automatic updates.
Method 2: Use fixed editions via third-party deployment tools
The most common way to install a program on a system is to obtain the program from the publisher, then push out an MSI or other installer to the target machines. But another method involves using a third-party software distribution system, which has its own software-updating mechanism.
One such system is PortableApps, a suite of free and open source software that has been repackaged to run without being formally installed in a system. Each "portable app" runs in whatever directory it has been unpacked into, makes no changes to the rest of the system and can be removed by simply deleting the folder.
What's more, many of the programs supplied in the PortableApps library that nominally have self-updating functionality -- such as Chrome and Firefox -- have those features disabled as part of their repackaging. Consequently, an administrator can obtain a PortableApps-packaged version of the program in question, deploy that and replace the application at their leisure with updated versions.
What's more, earlier versions of the programs in the PortableApps library are available in case you need to perform a regression (for Firefox, for instance).
Three things are worth bearing in mind if you use PortableApps. First is that not every program you'd want to deploy is available in the app library. The library is large and growing constantly -- yes, it does take suggestions -- but don't assume a given program is available.
Second, PortableApps also has a launcher application to organize, run and update PortableApps. The launcher can't be easily managed with Group Policy Objects or other standard software deployment tools -- you can't, for instance, manually disable its own auto-updating functionality. To that end, it's best not to use it as part of a deployment effort.
Third, not all apps repackaged through PortableApps have their auto-updating functionality disabled. It's best to test first and see if that's the case.
The most "official" way to handle rapid software updates is through whatever form of policy mechanism is supported by the program itself. If the program has been written with even half an eye toward being used in a professional environment, some degree of management through policies ought to be possible. But if it isn't, then you may want to look into a repackaged version of the program that doesn't update itself and work with that. Either way, and most importantly, the burden of watching for new releases and updating your users falls to you.