31732 - Make Deployment of Roaming Profiles Easier in LAN/WAN Environments

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, enhancement, P3)

Description

[Kevin Hecht]

It would be useful to consider other ways to make roaming more easily possible 
in a LAN/WAN environment. Currently 4.x on Win32 is rather unfriendly to this, 
as you can't merely throw the user profiles on a network drive and pick up and 
go to another computer and easily get them, since nsreg.dat must contain the 
profile data, and it can't be moved from the system's local Windows directory. 
There are workarounds for this, but they're rather clumsy and can be a deterrent 
on large deployments. I fear that Mozilla is going down the same path, given 
what appears to be stored in mozregistry.dat. The goal would be to create a 
better way to allow network roaming, perhaps possibly storing mozregistry.dat, 
or at least its profile location data, within the user profile directories.

This request is similar, but not identical, to bug 9556, though the fix 
may be the same. This bug is branched off from bug 17048, where some prior 
discussion occurred.

Comment 1

[Ben Bucksch (:BenB)]

Let's use this as tracking bug, as there may come up more issues with this kind
of usage. Adding dependency to bug #9556.

Comment 2

[Ben Bucksch (:BenB)]

reassign to owner of new component

Comment 3

[selmer (gone)]

If this bug is not to be a dup of 9556, then it must be about something unique
that 9556 doesn't cover.  My guess is that this is really about allowing the
profile to live on a remote machine.  I doubt that'll happen soon since we still
need to fix 9556 before attacking the remote machine problem...

Comment 4

[Mark Roe]

Shouldn't this bug should be assigned for all platforms, or at least PC and 
Macintosh platforms?  I'm hoping to use this great feature for a whole school 
district.

Comment 5

[racham]

Reassigning to myself.

Comment 6

[racham]

Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.

Comment 7

[Conrad Carlen (not reading bugmail)]

Setting milestone to Future. Having the profile dir in a remote location is a
lot of work. Some discussion has gone into it but I doubt it will happen very soon.

Comment 8

[Ben Bucksch (:BenB)]

Conrad, why is that a lot of work? Theoretically, it should already be possible,
not?

This bug is important considering that we don't have Roaming.

Comment 9

[Robert Towster]

I really love roaming but it would be nice to be able to start up anyone's
mozilla, and do something like "File - Login" and it would prompt me for the
roaming server name, my ID and password. Using that it would retrieve my roaming
profile. It would also be nice to provide "File - Logout".. followed by a
confirmation box that gives the option to save the profile or not.

Comment 10

[timeless]

[e-mail] 2001-03-30 00:08
that's an interesting idea, but this bug is for _backend_ support.  I think 
that the switch profile feature [dialog] (which the embed apps already support) 
could easily include a guest account and a remote account.

Comment 11

[Ben Bucksch (:BenB)]

Acutally, as I understood it, this bug is not about roaming, implemented by the
app, at all. We have other bugs for that (search for "roaming"). This bug is
about OS-level roaming, e.g. having the Mozlla profile live on a network-"drive".

Comment 12

[Conrad Carlen (not reading bugmail)]

> This bug is about OS-level roaming, e.g. having the Mozlla profile live on a
> network-"drive"

  That's true - given the summary of this bug. Also, doing this on a LAN is
enormously easier - in fact it works as-is on the Mac because file alises
auto-mount network drives :-)
  In terms of the UI, what do we want? Do we still want the idea of "Guest"
profile whereby you would select that profile and a dialog would come up with a
network browser? And then when you quit, that profile would be cleansed.
  Another thing that makes this easy is that, for kiosk support, I put in
nsIProfile::ShutdownCurrentProfile() which is passed SHUTDOWN_CEANSE will clear
out that profile's data.

Comment 13

[Pete Boyd]

what is %WINDIR%\mozver.dat (the version registry?)?

MOZVER.DAT is re-created with each new installation in this local directory. if
I delete it, a new copy isn't created, yet Mozilla appears to work ok. if it
needs propogating around workstations in an OS-level roaming environment then
that is an issue which relates to this bug

(I think the subject of this bug should instead be:
[RFE] Make Deployment in OS-level LAN/WAN Roaming Profile Environments Easier)

Comment 14

[Conrad Carlen (not reading bugmail)]

> MOZVER.DAT is re-created with each new installation in this local directory.

This file is created by the low-level registry code. I'm not sure what it's used
for (if anything). Dan?

Comment 15

[Tom]

IMHO on Windows NT/2000 Mozilla doesn't need it's own system for "roaming" like
NS 4.x attempted. Mozilla does the right thing by putting the profile into the
Windows profile folder of the user... but...

I'd like it if I could change the folder Mozilla uses for cache files... Using
roaming profiles under Windows NT/2000 you learn really quick that browser cache
is huge and kills your log on/off times. Windows lets you exclude folders from
the profile upload (like "Temporary Internet Files") so IE's cache doesn't get
stored on the server. 

Mozilla's random folder naming makes it impossible to save the profile and ditch
the cache. If it would let me set the cache folder to "Temporary Internet Files"
or really anything of my choosing, I could block the folder and save a ton of
disk space. 

Comment 16

[Pete Boyd]

roaming profiles is about a lot more than that. its being worked on and will be
really good. check the relevant bugs

as for defining the cache location:

Advanced -> Cache -> Disk Cache Folder -> Choose Folder...

user_pref("browser.cache.disk.enable", true);	
user_pref("browser.cache.disk.parent_directory", "F:\\administrator\\mozilla");

Comment 17

[Greg MacKinnon]

Changing Mozilla to use the Windows user profile directory was the right way 
to go.  Since my users have roaming profile activated on their systems, they 
WOULD need no additional work to backup their Mozilla settings to the LAN.

However, the current setup leaves many things to be desired.  For example, the 
default location of the Browser cache is in \Application Data\Mozilla... it 
should be in \Local Settings where it can be deactivated.  Yes, I know that 
you can change this location, but only AFTER install, when the damage has 
already been done.  Any settings which I make voluntary for the users only get 
implemented in about 33% of all installs.  My fault, I know, though I am sure 
this is not uncommon for other sys admins.

Also, POP mail and IMAP folder caching cause major profile bloat.  It should 
be easier for an administrator to block these subdirectories of the profile 
from Roaming Profile replication.  Unfortunately the directory structure does 
not lend itself to this.  Since mail resides in \Application 
Data\Mozilla\profiles\<profile name>\<rand id>\mail (or IMAP mail), I cannot 
create a Group Policy which creatively blocks JUST the mail folder... I have 
to block ALL Mozilla settings.  

Roaming profile holds a lot of promise, but I can't use it in its current 
incarnation.  It is really quite disappointing.

-Greg MacKinnon
University of Vermont

Comment 18

[luca]

I use samba as a server and I specifically disable roaming profiles (since when
I activated it synchronization was slow as hell and I have no time to really
look into it, sorry, my main job is not sysadminning).
But doing the same as netscape 4 would work well enough for me: upon
installation I install also a small registry file that instructs netscape4 to
look for the profile in the network drive (same profile name for all user, each
has his own drive U:\). If someone opens netscape with no network connection (so
no drive U:\) netscape4 would happily ask  the luser if he wants to create a new
profile (bad, netscape, bad), and, obviously, they'll always click on "OK" until
the dialog is gone, and then they'll complain to me that nothing is working ;-)
At this time I either copy to their windows directory a "virgin" nsreg.dat, or
create a new profile located in the network drive, and netscape4 dutily ask me
if I want to use what appears to be an existing profiles (good, netscape, good).
With this system I have the added benefit that, when creating a new user, I just
drop a standard prefs.js in their home subdirectory that will be referenced by
the profile and the first time they login everything works.
Of course I dind't find a way to do the same with mozilla (maybe the randomly
named subdirectory is making this impossible).

Comment 19

[Bryan Hobson]

I'd love to deploy Mozilla and/or phoenix to our university lan, but it isn't
possible because of the way the profile manager generates random directory names.

Why do we need profiles on mutli user systems like linux and NT/2000/XP Pro?

Why not just store the profiles in either "$HOME/.mozilla/" or
"%USERPROFILE%/Application Data/Mozilla/" depending upon your system?

Comment 20

[Ben Bucksch (:BenB)]

Bryan Hobson, this is completely offtopic and the salting directory has been
argued lots of times on the newsgroups, e.g. n.p.mozilla.prefs. Please search there.

Comment 21

[Grace Bush]

see also bug 97180

Comment 22

[lloyd]

I have a script named "mozprof" that I use to create a user's mozilla profile in
their home directory on the SAMBA server.

It creates a random salt directory and copies over a template profile, which
includes the necessary mozmail directories for the user's account on our IMAP
server, as well as a template prefs.js named prefs.template.  This template is a
standard company mozilla profile, but with the username and salt directory
replaced with placeholders _USER_NAME_ and _SALT_.  Then it just uses sed to
replace these values with the user's real username and salt directory.

The user still has to run "mozilla.exe -profilemanager" and set up a profile
pointed at their V:\mozilla folder (would be nice to automate this as well), but
after that everything is ready for them including home page, pop-up blocking,
secure IMAP account, etc.

I call this script from my "newuser" script, which creates the user's Linux
account and SAMBA account (as well as mozilla profile).

Comment 23

[luca]

I've finally bit the bullet and deployed mozilla (1.2.1).
These are the contortions I had to go through (thanks to windows stupidity and
bug 97180)

1. with an hex editor I modified a standard registry.dat (see bug 97180 comment
7) to use the profile directory u:\mozilla (u: is a network drive in the samba
server).

2. wrote a program that overwrites registry.dat (in the directory mozilla will
look at) with the standard one in the server.  This program also automatically
installs/upgrades mozilla to match the version stored in the server (it's easy
with mozilla: just copy the directory and some shortcuts).

2a. in case a registry.dat is already there, make a backup copy and modify
autoexec.bat to restore it on next boot (this solves the problem of laptop
users, coupled with another program to generate standard settings for them)

3. in the logon script execute a program to modify windows register so that the
program in 1. is put in HLMK\Software\Microsoft\Windows\CurrentVersion\Run (no,
I cannot run the program directly in the logon script since at that time many
directories depending on the user haven't been resolved yet, stupid windows)

On the server I made a simple script that creates the profile: it just prepares
a standard user.js for settings I don't want the users to change, prefs.js for
those they can change, cert7.db with the certificate for the internal ssl
server, and a default chrome/chrome.rdf so that mozilla comes up in spanish by
default.

I still keep my fingers crossed but it seems it has worked well.

Once a sensible solution is found for bug 97180 this will be much simpler.

Comment 24

[Ben Bucksch (:BenB)]

> a standard user.js for settings I don't want the users to change,

Please don't do that, it makes Mozilla looks broken. Use prefs lock file
instead, netscape.cfg, search on the web for it.

Comment 25

[luca]

Either mozilla "find in page" doesn't work or netscape.cfg isn't mentioned
anywhere in the release notes (they do mention user.js).
A google search only tells me that netscape.cfg is used with netscape 4. The
only information I found related to mozilla is a file to patch mozilla
executable to read netscape.cfg (scary).
A mozilla.org search gives only 6 results, 2 of which seems to be outdated
documentation (1999) based on netscape 4, and the other 4 are status report
telling that netscape.cfg isn't enabled in builds for various reasons.
Anyway, what makes mozilla look broken are other bugs which I never exeperienced
but my users are seeing (e.g. bug 169777, bug 179039, bug 186295, bad printing).

Comment 26

[luca]

Addendum to comment 23

Now, instead of running this program through
HKLM\Software\Microsoft\Windows\Current Version\Run
I made it into a wrapper for mozilla, i.e. renamed mozilla.exe to
mozillareal.exe and my program is named mozilla.exe.
This programs checks that the network drives are connected. If they aren't, asks
the user if he want to start with a local profile, otherwise it does the
registry.dat mangling as per comment 23 and then starts mozillareal.exe.
I think I'll keep this even if what I proposed in bug 97180 comment 13 gets
implemented.

Comment 27

[Art Wildman]

Looks like some progress is being made... (Any Duplicates?)

Mozilla Client Customization Kit (Custom Installer & Profile Manager)
http://www.mozilla.org/projects/cck/

Bugzilla Bug# 124418 - Mozilla CCK deployment barriers
http://bugzilla.mozilla.org/show_bug.cgi?id=124418

Bug# 24954 - [deployment]Need ability to specify with -installer the Users directory
http://bugzilla.mozilla.org/show_bug.cgi?id=24954

Bug# 55309 - Need an option to store migrated profiles in a user's choice of
location
http://bugzilla.mozilla.org/show_bug.cgi?id=55309

Comment 29

[Benjamin Smedberg]

Most of this bug is complete: bug 289254 may still remain, but I don't think this bug is tracking anything useful.