Corporate Updating

Had a little discussion last night that got me wondering, so I thought I’d post the question.

How does your company update products that offer in built-in updating functionality, like Firefox? Do you leave the functionality enabled and let the applications developer push updates to your desktop, or do you disable auto-update (I think app.update.enabled can be used to disable it in Mozilla products) and update via group policy or whatever method your company uses.

If anyone is able to comment (I know some IT Dept’s are very secretive) that would be great. Especially helpful if you can comment at least on the size of your organization and what method is used with apps that have the ability to auto-update. Especially if you deploy Firefox or Thunderbird in your organization. Leave a comment or feel free to email me if it’s not something you can post publicly.

From the way I see it, both have advantages and disadvantages:

Auto-Update

Advantages

  • No intervention by IT to keep product up to date.
  • No special servers, or configs to maintain.
  • Prompt updates.

Disadvantages

  • No ability to test update before it’s live.
  • Rely on developer to keep server secure.
  • Bandwidth consumption on WAN (download from source for each workstation, rather than just on the LAN).

Manual Update

Advantages

  • Ability to test updates for things like extension compatibility, and with intranet applications.
  • Feeling of control over workstations.
  • Less bandwidth consumption on WAN.

Disadvantages

  • Requires IT keep close eye on releases.
  • Delay can be a danger during 0 day exploits.
  • Infrastructure may be needed.

15 thoughts on “Corporate Updating

  1. Another disadvantage of auto-update:

    -It wouldn’t work on locked down non-administrator accounts

  2. The fact that you can’t auto update without admin privs is very bad because users shouldn’t be running with that user level anyway.

    If the auto updatge had some means of prompting for the password in order to update this would be good. I suspect this will be possible on Mac OS X where many apps already ask for a password for admin like stuff. Not sure how easy it would be on Windows or Linux – but at least on Linux you can use the version packaged by your distribution.

  3. An auto-update, which requires the user to login as administrator or start Firefox with administrator privileges, isn’t very useful. Nobody I know uses a user-account with admin privileges for doing his normal day’s work. At least on windows, an update-service (daemon) running with system-privileges would be a better solution.

    It would be awesome if some of the major open-source projects targeting the windows desktop (OpenOffice, Mozilla, …) would cooperate and implement an alternative for the Windows Server Update Services.

  4. My company : 100 000 employees
    Firefox auto update : disabled. IT dept make and test “packages” for every app and deply them on workstations.

  5. I work in the IT dept of a 250 employee telecom engineering company. We use WSUS and it is an o.k. solution. We also use a deploy application that is installed on every computer throughout the company. I would like to see a way of disabling auto-update from mozilla servers on all client copies of Firefox(exists already), and possible redirect the browser update to a intranet update server(like WSUS). Sure, I could sit and make a deploy package for every update, but it would be MUCH easier to have an option such as WSUS(but better, of course).

    We also use 3rd party client software that runs software/hardware audits as a background service throughout the day when the computers are idle. Are there any open-source applications that do this?

    If there was WSUS equivalent for Mozilla-family applications, I know for a fact that it would become more appealing for corporate adoption. To date, it’d been hard enough to convince upper management that Firefox is a safe and deployable application for our employees.

  6. Simple: We’re not using Firefox because my boss feels it can’t be readily upgraded across our network. None of our users have admin privileges, so the automatic updater won’t do squat. I’d really like to know why the MSI was ditched for 1.5 (I remember that being on the list, and I feel like a fool for saying “1.5 will be deployable via MSI) – from what I know of them, MSIs allow for a relatively easy upgrade of a ‘package.’

    If there was a really usable, Mozilla-supported means of deploying updates across our network, there’d be an awfully decent chance of ~800 computers running Firefox. Instead, most of them are in ‘click & pray’ mode. Quite a shame.

    I’m quite a fan of Firefox (been using it since the Phoenix on Linux), but I’m kind of disappointed at the moment. Folks are worried about going after every last home user with “Firefox Flicks” (ignoring the trolls, I like “Double-click Relief” — and “Whee” is fun, but impratical), but when you consider the gain of 800 users/installs (more if they like it so much at work, they load it at home) over a handful of new people you’ll introduce to Firefox, something just doesn’t add up. Spreading the word, including the NYT ad, aimed at decision makers, isn’t worth as much if they give the product a serious look and realize “we can’t support this.”

  7. There is a middle option. If you’re thinking of disabling auto-update, you could instead point the update URL to an internal server. When you’re happy that the update doesn’t break internal things serve the update.xml file. The update file could be a verbatim copy of the official mozilla one, or could be edited to instruct clients to download from an internal server if that causes less load.

  8. @Daniel: that’s also an option, but I wonder how well that will work for larger more diverse organizations (multiple locales, OS’s etc.).

  9. I used to worok on deployement tools, hence I saw various compagnies way of updating. Once the compagny is big enough it controls what’s on the desktops (except for a few developers). Hence they need to test every package they deploy (they all have tools to minimize bandwith on the internal WAN/LAN, and to check that updates are going well) : they test for regression, they test for side effects on other applications.
    They also need to decide wheter or not the update is worthy for the compagny. Hence it takes tiome for the desktops to be updated. Having fewer releases with more time in between releases might be a good point.

  10. At my sixth form college here in London, they employ a third option:

    Disable auto-updates, and then don’t do manual updates either 🙁

  11. @Dan: Yes, that happens. And the bad part is… if security bugs in an old version manifest and cause problems… it’s Firefox that’s blamed… not the admin who doesn’t update.

    Hopefully this can change.

  12. my $0.02

    userbase: 10k or something
    autoupdate: switched off
    update method: via Microsoft Systems Management Server

  13. With regard to pointing Firefox’s auto-update to an internal server: how, exactly, is this done? I’ve been plowing thorugh mozillazine and the Mozilla KB but have yet to find any information on how to do this. A sample update.xml file would be helpful; haven’t been ably to locate any so far; ditto any quidelines on how the URL should be formatted (or is it just http://server.domain.com/update.xml).

  14. I am in charge of updates and software installation at a company of around 70 people/ We use WPKG, an open source app, to push software and updates to Windows workstations.
    I just discovered great extension called CCK Wizard which will create another extension to customize Firefox. You can turn off updates, change the URL it looks for, add certs, extensions, force homepages, add bookmarks, all kinds of things. It’s awesome.

Leave a Reply

Your email address will not be published. Required fields are marked *