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.

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

reassign to owner of new component

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...

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.

Reassigning to myself.

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.

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.

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.

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.

towster@technologist.com 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.

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".

> 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.

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)

> 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?

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.

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");

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

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).

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?

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.

see also bug 97180

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).

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.

> 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.

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).

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.

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

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