I was recently tasked with deploying Firefox to a large chunk of system in the organization as a secondary browser. My first thought was this would be painful as hell, however after looking into it, deploying Firefox isn’t that bad. First I’m going to skim over the few things that in my opinion you absolutely must do for a “enterprise” type of deployment.
- Use the ESR version of Firefox.
- Repackage the Firefox install as an MSI. I don’t know of any free tools that you can do this with, but some examples would be Wise Packaging Studio (I don’t think this is being sold anymore…), AdminStudio, or MSI Studio.
- Install Firefox to a unique directory. For example, if the version is 10.0.7, install Firefox to a directory like C:Program FilesMozilla Firefox 10.0.7.
- Add the version number and ESR to any shortcuts.
- Create your own JS file under INSTALLDIRdefaultspref.
- Use a override.ini file.
- Create an encoded Mozilla.cfg file.
You should have your encoded cfg file, your ini file, and your JS file ready to go before you go to repackage the application.
So first, start off by going out to http://www.mozilla.org/en-US/firefox/organizations/ and grab the latest ESR of Firefox.
Next, open up Notepad and paste the following into it.
Save that as “override.ini”, and stash it somewhere.
Also in Notepad (new session), paste the following into it.
Save this file as custom.js and also stash it somewhere. This JS file contains Firefox settings that can be changed by an end user. (Think preferences within group policy.) The first line references the configuration file we’ll create next.
Lastly, in Notepad (again, a new session), paste the following into it.
Save this file and call it Mozilla.txt. Now, navigate out to the following site -> http://www.alain.knaff.lu/howto/MozillaCustomization/cgi/byteshf.cgi, upload your Mozilla.txt and then download an encoded Mozilla.cfg file. Stash this config file with your other two files. It’s worth noting however that you don’t have to encode the config file. I do it just so end users can’t easily edit the configuration file. If you choose not to encode the config file, then instead of originally saving the notepad document as a .txt file, save it as a .cfg file and then add the following line to your JS file.
Now, in case you’re just following this blindly, I’ll go over what we just did briefly. The override.ini file is in place to prevent the Import Wizard from running the first time an end user launches Firefox. (Like all things in the files we just created, if you don’t want a setting or “feature”, change it or remove it.) The custom JS file I pasted in above contains a line telling Firefox to read a particular configuration file, and then it also sets a preference for what I would like the home page to be. By setting this in the JS file an end user can permanently change the home page to whatever they’d like. Finally, the configuration file is there to lock settings in place. It’s very possible you could put the homepage in the configuration file as a Pref instead of a lockPref, however I haven’t tried. I pasted in most of what I have in my configuration file. There are a few settings I’ll call out. The rest are all set because they make sense to me for having set in an enterprise environment.
- startup.homepage_welcome_url : I set this to nothing so that when a user opens Firefox for the first time they only see 1 tab open with their home page. If this is set to a corporate intranet site which is the same as the homepage, the user will see 2 identical tabs. If you don’t configure this option with anything then the user will see a Firefox welcome site. I prefer the user get a clean looking browser without junk, so I’ve removed the welcome tab on first launch.
- extensions.shownselectionUI = false : I set this to false so that the end user doesn’t get a window regarding add-ons appearing the first time they launch Firefox. This is a similar window as to what Internet Explorer has for ‘speeding up your browser’ by disabling add-ons. In my case, any add-ons present on the system are there for a reason, so the users here don’t need to see this screen.
- browser.shell.checkDefaultBrowser = false : This prevents the “Do you want Firefox to be the default browser” box from showing up. In my case Internet Explorer is still the default browser. Setting this in no way prevents the user from manually changing firefox to being the default though.
- toolkit.telemetry.rejected = true : This is setting 1 of 3 settings that prevents the ‘do you want to send info back to Mozilla’ bar from appearing during first launch.
- toolkit.telemetry.prompted = 2 : This is setting 2 of 3
- toolkit.telemetry.enabled = false : This is setting 3 of 3
All the extension. and app. settings have to do with preventing add-ons/extensions and preventing automatic updates and such. Where you see 127.0.0.1 I’m just telling the browser to look back at the local system for a update server and such. So far the settings I have set seem to be effective at keeping add-ons and updates away. For those who don’t understand why I wouldn’t want automatic updates, generally in large environments you want to control the version of the software being used.
So now that you understand what the various files you created are for, now it’s time to package the application. I would suggest using a snapshot mode to capture the installation, but you can do whatever you’d like. Keep in mind that it’s best to install to the unique installation directory using the Firefox setup, and to change shortcuts and add your files before you capture the results with your repackaging software.
In case I didn’t already say this,… which I don’t think I did, override.ini and mozilla.cfg both go in the installation directory right alongside Firefox.exe. Your custom JS file goes under .defaultspref.
One issue you might see during your deployment is the add-on window still appearing during the first launch of Firefox even though there’s a configuration item set telling it not to appear. I’ve found that in my cases, this happens when there’s already a Firefox profile in existence. If you open up the prefs.js file under %AppData%MozillaFirefoxProfilesflakdfja.default and remove the lines that contain “user_pref(“extensions.”, you won’t see this issue. My best guess is that the new version of Firefox has an issue with extensions that were registered under an older version. In my case, I created a VBScript to delete the lines from the JS file, then embedded this script in a custom action that ran during install and repairs of the MSI. This is where you find ActiveSetup rather useful.
If anyone reads this and finds that I’m doing something odd, or wants to point out another way of accomplishing the same task, let me know. This is my first run with deploying Firefox, and all of the above was figured out in just a couple of hours.