Customizing Mozilla Firefox for Enterprise Deployments

Quite a few of my customers use Firefox as their web browser.  In a VDI environment, it becomes important to customize Firefox's behavior in order to comply with corporate standards.  There's an enterprise version of Firefox, but if you're not inclined to go that route, VDI solutions make it very easy to push enterprise configurations to all of the endpoints that are using Firefox.

Firefox is great because it uses config files for just about everything.  Through those files, you can make all of the commonly required configurations.  You can disable automatic updates for Firefox.  You can set a default home page (and enforce it so that the user can't change it).  You can disable the first run "Import Settings" wizard and "welcome to firefox" page.  You can disable the default browser check.  Basically, you have full control over how Firefox works and what its settings are.

There are 3 files that you'll need to create: C:\Program Files (x86)\Mozilla Firefox\defaults\pref\local-settings.js, C:\Program Files (x86)\Mozilla Firefox\mozilla.cfg, and C:\Program Files (x86)\Mozilla Firefox\browser\override.ini.  By manipulating those 3 files, you can enforce a huge range of behaviors.

First, is the C:\Program Files (x86)\Mozilla Firefox\defaults\pref\local-settings.js file.  This one is basically the enabler and is really simple.  It just needs the below 2 lines, and all that it does is tell Firefox to use a config file (importantly, Firefox will not start if it cannot find that config file).

pref("general.config.obscure_value", 0);
pref("general.config.filename", "mozilla.cfg");
 
Next is the C:\Program Files (x86)\Mozilla Firefox\mozilla.cfg file.  A good description of this file can be found at mozillazine.org.  The first line must be a comment, but after that you're free to go.  You have a few options for the lines - I found "lockPref" and "pref" to be the most useful.  LockPref sets a preference and enforces it - it's greyed out in Firefox and the user can't change it.  Pref, on the other hand, sets a preference but allows the user to change it.  The syntax on one of these lines is really simple: lockPref(<name of preference>, <value>);

How do you know what preferences exist and what values they accept?  That's nice and easy as well.  Just open up a Firefox browser and make your desired configuration changes.  Then, browse to "about:config" and (after promising to be careful) sort by the Status column to find all of the settings that are user set.  A bunch of those will be automatically set during the first run of Firefox (and so don't need to be enforced), but that's a relatively easy way to find some setting that you've made (or just to browse the options).  Below is the contents of a basic mozilla.cfg that I use; it disables updates, disables the first run stuff, disables the default browser check, and sets the homepage.

//
//Disable Updates
lockPref("app.update.enabled", false);
lockPref("app.update.auto", false);
//Disable "welcome to mozilla" page
lockPref("browser.startup.homepage_override.mstone", 24.0);
//Disable Default Browser Check
lockPref("browser.shell.checkDefaultBrowser", false);
//Set default page
lockPref("browser.startup.homepage", http://www.google.com);


Finally, we have the C:\Program Files (x86)\Mozilla Firefox\browser\override.ini file.  This guy is the final piece of the puzzle for disabling the "Import Settings" wizard that fires up the first time that Firefox runs for a given user.  In a nonpersistent VDI environment, every time is the first time, so it gets annoying!  To disable that feature, just create that overrides.ini file in the "browser" folder under your Firefox install, and place the following two lines into it:

[XRE]
EnableProfileMigrator=false


And that's it!  Now, Firefox is preconfigured for your users in such a way as to work for your VDI environment.  You could publish this Firefox through a Unidesk layer, a ThinApp package, or whatever application delivery method you prefer!

One final note - when I'm iterating through settings, I find that it's important to be able to "revert to clean" to see the new user experience.  To do this, just execute "firefox.exe -p" from a Run prompt and delete your profile.  On the next run of Firefox, it'll be a clean slate and you should be able to go through the whole process that a new user (or nonpersistent user) would experience.

Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending order?  Yeah, there&
Read more

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host to another.
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip
Read more