A popular and convenient way of deploying software is to use Microsoft’s Group Policy to assign packages (.msi files). I posted the various products I had found earlier with the post Making Setup.exe into Setup.msi. Mozilla does not offer a .MSI file for easy deployment and management. It seems to me that this would be a great direction for Mozilla to push for as it would make the Enterprise market share much more plausible and reachable audience.

Update: This capturing method of installing Firefox 3 is still valid, but there is a better alternative here: Windows Installer Wrapper Wizard and a Better Firefox 3 Enterprise Deployment

Instead, system administrators are left relying upon third party solutions to post .msi files. One of the most popular ones is using FrontMotion’s Firefox MSI. (I’m intentionally not providing a link. I highly recommend you follow this post and create your own .MSI file instead.) I used the MSI file FrontMotion provided to deploy Firefox 3.0 throughout my organization. I later found out that this was a poor idea when Firefox 3.0.1 was released by Mozilla and my machines were no longer updating automatically. In fact, the Firefox I had deployed was not only configured to disable automatic updating. The setting was locked so I couldn’t change it, even as a local administrator. This means I would have to deploy Firefox every time there was an update released from Mozilla instead of just deploying it the one time in order to stay up to date with security patches. This also makes me depending on FrontMotion for future releases of the MSI and their schedule. On a side note, the delay between Mozilla releasing Firefox 3.0.exe and FrontMotion releasing Firefox 3.0.msi was several weeks.

Along with the aforementioned downsides, we would also be subject to any additional files, settings, and extensions included in the MSI installation. Case in point, FrontMotion’s Firefox 3.0 .msi includes a suspicious, random, and unrequested file: C:\test.txt. After deploying FF3, I noticed these test.txt files showing up on all of the machines. They had different created and modified dates because the software was deployed when the machines restarted and they all restart at different times and frequencies. It was just an empty text file this time, but it still proves that this has to be a trusted relationship. If we make our own MSI, we do not have to worry about this and perhaps with advanced configuration we can set our own settings and extensions to default for our users. This will come later.

Enough complaining and justifying making our own MSI for Firefox. I don’t mean to rag on FrontMotion too much, that’s not the point of this, but I want individuals to choose wisely and not waste their time with the current offerings of that site. I assume if you’re still reading, you’re already interested in creating one. So, let’s begin!

We’ll need:

The 2 computers are going to consist of a ‘Setup’ machine and a ‘Host’ machine. I’ll just use these names to keep them straight. The ‘Host’ machine can be any machine on the network that the ‘Setup’ machine can reach and access its shares. The ‘Setup’ machine (this is important) is going to be a fresh install of Windows. You are going to install Windows, the network driver, and possibly the video card drivers. That is it. I recommend capturing an image of the ‘Setup’ machine at this point so you can quickly restore it to this point for conveniently capturing MSI files in the future. You want the bare minimum on this ‘Setup’ machine because you don’t want anything going on in the background that would end up in your capture, your .msi, and then on all the machines this software is installed on.

The ‘Host’ machine can be the machine you use every day. Its only job in this process is to host the WinINSTALL software. After downloading the WinINSTALL application install it on the ‘Host’ machine. You can choose all of the defaults. You only really need to pay attention to this screen:

Screen 4 of WinINSTALL's setup.

Screen 4 of WinINSTALL

This tells you the share that you’ll be accessing from the ‘Setup’ machine later. Whatever the hostname of the ‘Host’ machine is, you’ll access the software from \\Host hostname\WinINSTALL (ex. My computer’s name is ITStaff09. The share is located at \\ITStaff09\WinINSTALL\) or replace WinINSTALL with whatever you change the above screen to say (recommend leaving it with the default).

With WinINSTALL installed on the ‘Host’ computer, let’s get the ‘Setup’ machine prepared. Log in as the local administrator and download the Firefox 3 setup.exe of whatever language and localization you want on your machines. Access the share on the ‘Host’ machine and create a shortcut on the ‘Setup’ machine’s desktop to discover.exe. You now have your ‘Setup’ machine all configured with freshly installed Windows, network card driver installed, Firefox 3 setup downloaded to the desktop (DO NOT RUN IT YET!), and an icon to discover.exe on the desktop.

Close any open applications and windows on the ‘Setup’ machine. Wait for everything to close and launch the shortcut to discover.exe from the desktop. Follow the on-screen instructions. For the first time through, we’ll stick with the defaults, with more familiarity and depending on the application you’re installing you might tweak these settings. For now, go through the defaults. This is taking a snapshot of the machine so it knows which files and registry keys change during the installation and setup.
At the end, you’ll be prompted for the installer.
Browse to the Firefox 3 setup.exe on the Desktop and click launch.
Complete Firefox 3’s setup choosing all the settings you want to be in your deployment.

Once everything is setup how you want it to be close all windows and run the shortcut to discover.exe again. Follow the on-screen instructions to take the post-snapshot. This may take a while for the machine to process what differences were made, but just let it run and in the end you’ll have a .msi ready for deployment. By default, the new package was stored in the WinINSTALL share, \Bin\Packages but you can specify this.

I would definitely recommend testing out your MSI before deployment multiple ways. You’ll want to test:
+Running the MSI on its own
+Deploying the MSI on a test machine through Group Policy
+Deploying to a machine that has an older version of Firefox installed
+Deploying to a machine that has the same version of Firefox already installed

If you want to see what is going on inside of your MSI, you can use ORCA MSI Editor to view what directories and registry keys are changed in this MSI.

You should now have a working .msi file to deploy through group policy for Firefox 3. I want to point out that this process will work for any setup file to create an .msi, much more than Firefox.

You might check out FirefoxADM for controlling Firefox settings through the Group Policy (documentation) to make your system administration complete.



Related posts:

  1. AppDeploy.com – A Community for Software Deployment
  2. Making Setup.exe into Setup.msi
  3. Windows Installer Wrapper Wizard and a Better Firefox 3 Enterprise Deployment