Better Corporate Deployment

A while back I asked a question about how companies deploy/update Firefox in the corporate environment. I got a fair amount of feedback on the issue. I wanted to post this a while back, but got sidetracked. Anyway here’s what I’ve put together after reading comments and emails about the topic.

Based on what I’ve read, and looking at where apps like Firefox and Thunderbird stand, I see a few possibilities to improve:

Provide MSI’s as a download

From what I’ve read, and some email’s, MSI’s seem to be the vehicle of choice for most looking to deploy an application because it’s fairly easy to use, and pretty common.

Better Documentation for Corporate Deployment

It seems part of the problem is corporate IT departments don’t see clear documentation on “how to”. A fix for this would be some good documentation on “recommended practices”. Some topics to discuss:

  • How to disable auto update
  • Prohibit installing extensions
  • How to deploy updates with popular deployment tools and enterprise tools and technologies like Group Policy
  • Discuss how the CCK could be helpful

Upgrade Recommendations

A big problem seems to be keeping things up to date. There are several complicated issues here. To discuss them briefly:

Policy Restrictions
In some cases, computers are locked down enough that auto update in Firefox won’t work since it can’t update files. This means an admin must interfere, and must know that they need to take some sort of action.

Internal Testing
Companies have strong testing policies in place because of internal apps that are business critical. As a result before something like a browser can be updated, it must be tested against these applications. How do we minimize the time from the release of the new version, to when a company actually deploys this. Obviously the less time involved, the better.

Update Notification
With auto-update disabled, how do companies know a new release has been issued? How can they easily keep up to speed, with low noise?

The first step has already been taken. Mozilla products have a very good versioning scheme and maintenance update release pattern. It’s also good that stable branches live for a while. This is essential for corporate deployments. It allows for some time between moving between versions (such as 1.0.x to 1.5.x). The release cycles work rather well.

There seems to be a need for an IT mailing list, that would notify IT professionals when a release reaches the RC (Release Candidate) stage, allowing them time to test the new version against their systems. Such notification should also contain changes made since the last release, but written in terms of “what to look for when testing” or “what impact these changes could have” (for example a change in how plugins are loaded/handled, requiring testing where Java applets are embedded in web pages). By sending these notifications first during the RC stage, it would allow for some time to do testing, and quicker deployment once the release is official. This is important in the case of security bugs being fixed, when exploits could quickly follow an announcement. The low noise of the mailing list would ensure IT professionals get notifications they need.


I’m curious how these proposals would work for IT departments, from what I’ve read and feedback I’ve received I believe this would allow for much easier adoption, without adding too much of a burden.

Mozilla Software Tech (General)

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:



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


  • 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


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


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