by BigDumbDinosaur, BCS Technology Limited

The Mozilla open source web browser has started to achieve critical mass in the Windows world.  If you are a Windows user there are a variety of reasons why you should consider abandoning Internet Explorer (IE) in favor Mozilla, such as the latter's substantially better security, more up-to-date user interface and ability to squelch annoying pop-up windows.  In simple terms, Mozilla offers a level of technical excellence that is sorely lacking in IE.  I switched my business's workstations to Mozilla about a year ago and can personally testify to the browser's quality, performance and ease of use.

Mozilla has many features in common with its Netscape ancestors, one of which is the concept of browser profiles.  Profiles, which first appeared in the Netscape 4.x family, allow multiple users of a standalone PC to customize the browser's look and feel to suit individual tastes, as well as maintain separate bookmarks, cookies, mail, and so forth.  Mozilla profiles are essentially similar to the "favorites" feature of IE, but are not an integral part of the Windows environment as is the case with IE.  However, on a PC configured to operate in a Windows domain supporting roaming profiles, the default is for Mozilla profiles and  E-mail(!) to be buried into the user's Windows roaming profile subdirectory, which can cause more than a little grief.

Our first large scale installation of Mozilla was at an insurance agency with a multitude of PC workstations supported by one of our Uni-FI^_TM servers running Samba on top of SCO OSR5.  A full Windows domain has been implemented, complete with roaming profiles, log-in scripts, server-controlled printing, several types of secure storage, and five flavors of freshly-brewed coffee (just kidding!).  Previously, web browsing was via Netscape 4.8, which worked well in this setting.  Unfortunately, compatibility issues with some insurance company websites (mostly those prepared with FrontPage, another Microsoft abomination) necessitated the replacement of Netscape with something else.  Due to security concerns, migrating to IE was not desired by this client, which opened the door for Mozilla.

Complicating matters at this client, each employee normally works at his or her own desk, but on occasion may work at someone else's desk.  Everyone is accustomed to a personalized web browser look and feel, courtesy of Netscape's profiles feature and the judicious use of server resources.  In this environment, if Kathy logs on at Paul's or Nancy's workstation, she will see exactly the same browser configuration that she would see on her own machine without having to tell the browser which profile to use.  In other words, not only does this system support Windows roaming profiles, it also implements browser roaming profiles.

Unfortunately, Mozilla was not as cooperative as Netscape 4.8 in establishing browser roaming profiles, which made it necessary to experiment a bit to determine how to proceed.  Therefore, I thought I'd share some of the fruits of that experimentation with you so as to reduce teeth gnashing, profane utterances, mouse abuse and other manifestations of the frustration that often accompanies Windows configuration tasks.  With minor exceptions, everything that follows applies equally to a Windows domain supported by Samba or other UNIX/Linux based SMB server (e.g., FacetWin), or a "real" Windows server, with the obvious exception of any UNIX based stuff that necessarily would not apply to Windows.  Also, although we have not attempted to implement any of this with Netscape 7, there is no obvious no reason why it should not work.

As is often the case when confronted with a new challenge, it is useful to examine the past for guidance.

As mentioned above, before I switched this client to Mozilla they were on Netscape 4.8.  Netscape 4 uses a simple directory hierarchy: by default, binaries, DLL's, help files, etc., are stored in C:\Program Files\Netscape\Communicator, and profile data (including E-mail) is kept in C:\Program Files\Netscape\Users\<user>, where <user> is a profile name established by the Netscape profile manager.  Since the C:\Program Files\Netscape\Users\ part of the profile path is not hard coded into Netscape, it is possible to relocate browser profiles by merely renaming and/or moving the profile subdirectory and telling Netscape where to find it.

In order to achieve a consistent browser interface for each user throughout the entire domain, it was clear that the system would have to be arranged so Netscape would go to the server to get the user's profile.  Although Netscape 4 has support for LDAP (lightweight directory access protocol) and thus can store profiles on an LDAP server, I did not have access to an LDAP package for OSR5 at the time this system was placed into service.  This meant I was on my own in finding a solution to the browser roaming profile requirement.

My method was to store each user's Netscape profile subdirectory in their home or private Windows server share, which in Samba is defined by the PATH= statement in the [HOMES] section of smb.conf.  To avoid a major mess in the event the server and/or user shares were renamed, I arranged for each user's home share to always map to a particular drive letter at log-in time.  For Windows 98 clients, NET USE P: /HOME in each user's login script did the trick.  For Windows 2000 clients, a LOGON DRIVE=P statement in smb.conf accomplished the same task.  With this arrangement, if something had to be renamed/relocated, I merely had to edit the user's login scripts (a simple task in UNIX or Linux via shell commands), edit smb.conf and send Samba a sighup to recognize the edits made to smb.conf.  At the next log-in the changes would take effect.

With a fixed storage location established, I set up a subdirectory named .netscape in each user's home directory, this being the repository for the browser profile.  To get Netscape to always go to this path, I configured a single profile at each workstation, named default, and told Netscape that default's profile was stored at P:\.netscape.  That way, no matter which workstation the user logged on, Netscape, having only one defined profile (default), would always go to P:\.netscape to find the profile, and since P: was always mapped to the user's home directory, Netscape would, in effect, go to \\<server>\<user>\.netscape and automatically set up that user's personal browser configuration (where <server> is the server's NetBIOS name and <user> is the user's home share).  Incidentally, if the Samba HideDotFiles option is set in smb.conf, filenames that begin with a dot are mapped into Windows as hidden files.  Hence .netscape is not visible when the home share is browsed, which tends to discourage users from accidentally trashing their Netscape profiles.

Incidentally, there is a bit of a booby-trap built into this arrangement.  If a Windows 98 user bypasses the domain log-in procedure by pressing [ESC] or clicking on the Cancel button and then attempts to run Netscape, the mapping between the P: drive and the user's home share will be invalid, Netscape will not be able to find a profile, and the Netscape profile manager will start up and ask the user to create one.  If the user proceeds, the link between Netscape and the server-based profile will be broken.  As the broken link can be readily repaired by anyone with a modicum of Windows skill and some knowledge of how the browser profiles are maintained, this flaw was considered to be a minor nuisance, so I never bothered work out a solution for it.

Anyhow, following the installation of Mozilla, I had planned to carry forward my Netscape 4 roaming profile methodology.  Sadly, I discovered that Mozilla's means of storing user profiles mirrored those of Netscape 7, which technique was not compatible with the Netscape 4 approach.  Therefore, the simple expedient of moving the browser profiles to the server wouldn't work and a new way had to be devised.

Like Netscape 4, Mozilla stores profile data separately from the code base.  That's the good news.  The not-so-good news is that unlike Netscape 4, Mozilla may use anyone of several paths to store profiles, depending on which version of Windows is in use and whether roaming profiles are in effect.  Also, Mozilla by default adds a randomly named subdirectory to the profile path, which exacerbates the problem of relocating the profiles.

By way of example, Netscape 4 might have stored Kathy's profile in:

C:\Program Files\Netscape\Users\kathy\

With Windows 2000, Mozilla would probably store the profile in:

C:\Documents and Settings\kathy\Application Data\Mozilla\Profiles\kathy\<random string>.slt\

or in Windows 98:

C:\Program Files\mozilla.org\Mozilla\Profiles\kathy\<random string>.slt\

If Windows roaming profiles are in use, the profile as stored on the domain server might be:

\\<server>\profiles\kathy\Application Data\Mozilla\Profiles\kathy\<random string>.slt\

where <server> is the NetBIOS (Windows) name of the server and profiles is the share name into which roaming profiles have been stored (a location that is further influenced by whether the client is Windows 95/98/ME or Windows NT/2000/XP/95/98/ME profiles are typically stored somewhere in the user's home directory).  In all of the above examples, the blue text represents the path component that can be expected to remain constant in a given Windows installation (i.e., the \\<server-name>\profiles\ reference is where Windows roaming profiles would be found).  The red text represents the path component that is generally determined by the browser, as well as the person who installed it.  The examples assume that the browser was installed to the default installation path.

In all cases, the Mozilla component of the default profile path will also include two files named pluginreg.dat and registry.dat.  Neither file is actually part of the user profile, but both are critical to the operation of Mozilla (registry.dat stores, among other things, the names of the Mozilla profiles that have been created, as well as their paths).

In a domain that has been set up to use Windows roaming profiles, everything in the Mozillaprofile path will be transported from the server to the PC at log-on time and will be copied back to the server when the user logs out.  Also, a copy of the profile will be locally cached on Windows 95/98/ME workstations, and on any Windows 2000/XP workstation where the registry has not been hacked to discard the local profile once the user logs out.  Assuming that all log-ins are policed by the primary domain controller (PDC) the cached roaming profiles on the workstations will uselessly consume disk space.

What is particularly nasty about the transporting of the Mozilla profile from the server to the PC and back is the potentially heavy load imposed on the network and the server.  Over time, some of the files in the Mozilla profile (especially files containing E-mail) could become very large, resulting in the consumption of signficant network bandwidth during the copying of the user's Windows roaming profile which also schleps a lot of non-Mozilla stuff.  Aside from the effect this may have on other users who are trying to get to server resources, the time required for a workstation to complete the log-in or log-out process will substantially increase as the size of the Mozilla profile files increases.

Further complicating matters is the last part of the path, that is, the <random string>.slt component.  This is a feature that was added several years ago to the Netscape code base (and then into Mozilla) in response to the theoretical possibility of an attack exposing the user profiles, from which a cracker could supposedly steal passwords, read mail, peruse bookmarks, etc.  As it turns out, the <random string>.slt component of the path can be derived from registry.dat, as that file is not encrypted.  Therefore, it's my opinion that the randomizing of the profile path adds scant security.

Continuing with the profile subdirectory discussion, the <random string>, an eight character alphanumeric sequence that is (surprise!) randomly generated each time a Mozilla profile is created on a workstation, will in all likelihood be globally unique in the domain.  Even if the same username is used to create a Mozilla profile on each workstation, the probability of any given random string being generated more than once will be about 1 in 3.24 x 10³².  Therefore, <random string>.slt will be different for each workstation and, in fact, will be valid only on the workstation where the user profile was first created.  Hence, Mozilla would fail to find the server-resident profile, except when run from the first machine on which the profile was created.  Adding insult to injury, if a different user runs Mozilla on the same workstation, they will be told that the profile can't be found and that a new one must be created.  When that is done, Mozilla will forever forget about the original profile, which means the original user will no longer be able to run Mozilla with his/her original profile.  A secondary effect of this will be that the user will not be able to read his/her mail, since those files are normally stored  in the profile subdirectory as well.

Fortunately, a back door exists that can be used to avoid these contretemps.  If a Mozilla profile is created from scratch and pointed to a directory that has already been populated with at least one key file expected by the browser, the "salting" of the profile directory name will not occur and the <random string>.slt path component will not be present to annoy us.  That is to say, instead of having:

...\Mozilla\Profiles\kathy\<random string>.slt\

the path will be reduced to a more practical:

...\Mozilla\Profiles\kathy\

which can be stored on a server (where it less likely to be cracked, assuming a proper security model has been adopted) and accessed from any workstation running Mozilla.  In fact, we would now be able to define a single profile on all workstations and get rid of the Mozilla\profiles\ part of the path, thus essentially achieving what was possible with Netscape 4: true browser roaming profiles.  How would we accomplish this?  Read on, my  friend!

The process of creating Mozilla roaming profiles is somewhat convoluted, but not at all difficult to follow.  However, before undertaking anything described in this section, please read it in its entirely so you will know what to expect.  The procedure will assume that you are performing a scratch Mozilla installation on each workstation, although it will be apparent that the methodology can be adapted to systems that already have a running copy of Mozilla.  Also, if you haven't already done so, download the latest version of Mozilla and store it on the server in a location that will be accessible to a Windows user with administrative rights.  Keeping your Mozilla installation up to date is an important part of maintaining a reasonably secure environment.

If it hasn't already been done, configure your server so each user has a home share that is mapped into an MS-DOS drive letter when s/he logs on.  On many Windows servers, the user's home drive will be H:, but the actual drive letter choice is arbitrary.  I prefer to use P: for "personal" or "private" storage (it's private in that the only users who can see it are the owner and the server administrator - root on a UNIX or Linux box).  Whatever your choice, drive mapping must be done on the server via a login script or static configuration, not on the client.  This arrangement will assure that the home drive will be invalid if user log-in to the domain fails for any reason (e.g., server off-line, network down, etc.).

As described in the previous section, Mozilla will recognize an existing profile subdirectory if a new profile is pointed to it.  Minimally, this subdirectory has to be populated with a single file, which would be prefs.js.  Alternatively, the subdirectory could be populated with all of the subdirectories and files that constitute an active Mozilla profile: you could create a boilerplate profile to get each user started and copy it into each user's Mozilla profile subdirectory.  In either case, Mozilla would always look to that subdirectory for a valid profile.  There is a bit of complication involving the pluginreg.dat and registry.dat. files read by Mozilla at startup, but nothing earthshaking.

Now that I have thoroughly inundated you with a bunch of tedious minutiae, I'm sure you're eager to get something useful accomplished.  First, I'll describe the server side activities, which require that you be logged in as root if you are on UNIX or Linux, or as a user with full administrator rights if you are working with a Windows server:

If you are working on a Windows server, the process is more involved: you have to change the directory and file properties in separate steps, which requires more work than the equivalent steps in UNIX.

With the server side finished, it's time to play with the workstations.  The procedure is the same at each PC: load Mozilla and create a profile for testing, and then log in as each regular user who is to use the workstation and run the Mozilla profile manager to create a default profile.  First the loading and testing operations:

Repeat the above process for each workstation on which Mozilla is to be installed.  If you have a lot of workstations to do, send out for an extra large pizza and several liters of soda.  That way you'll be able to entice some of your friends to help out.

Earlier, I mentioned two special Mozilla files: pluginreg.dat and registry.dat.  As explained before, these files are normally buried into the user's Windows profile directory tree, and are essential to the operation of Mozilla.  In particular, registry.dat maintains a list of all the Mozilla profiles that have been configured.  Following the first time installation of Mozilla, registry.dat will be valid only for the installing user.  So, when some other user logs on and tries to run Mozilla registry.dat will not exist: there is no Mozilla data in the other user's Windows roaming profile, which means no valid profile will appear to exist.  The solution to this problem is to recreate the mozilla profile and point it to the P: drive (assuming that is where the user's home share has been mapped).  Just so you are clear on this configuration aspect, I'll repeat the required steps:

Domiciling Mozilla profiles in each user's home directory on the server produces a consistent browser look and feel throughout the domain, something that your users will appreciate.  Also, with the browser profile no longer part of the Windows roaming profile, less network bandwidth will be consumed during log-in, as the browser profile will not be copied to the workstation at log-on time.  The procedures described above were tested both on my office system (Samba running on OSR5) and at two different client installations (both also running on Samba).  I believe I have covered all that you will need to know to set up Mozilla roaming profiles in your Windows domain.  If something isn't clear, please leave some Wiki feedback and I'll try to help out.

Unfortunately, people are not rebelling against Microsoft. They don’t know any better. (Steve Jobs)