--------------------------------------------- # with Win2k you'd probably use Group Policy (GPEDIT.MSC); with NT4 you'd use the System Policy Editor (POLEDIT.EXE); both of which probably All Users/NTUSER.POL (which contains security policy applied to everyone). but with Win2k there appears to be some areas lacking of what you can pre-configure using the Group Policy editor --------------------------------------------- OpenOffice --------------------------------------------- two stage install...1st copies just the program itself to a program directory, 2nd copies user files (either to workstation or 'virtual workstation' that is the users' Profile, then configures registry of the actual workstation "File Locking In the default setting, file locking is turned off in OpenOffice.org. To activate it, you have to set the appropriate environment variables SAL_ENABLE_FILE_LOCKING=1 and export SAL_ENABLE_FILE_LOCKING. These entries are already in disabled form in the soffice script file. Warning: The activated file locking feature can cause problems with Solaris 2.5.1 and 2.7 used in conjunction with Linux NFS 2.0. If your system environment has these parameters, we strongly recommend that you avoid using the file locking feature. Otherwise, OpenOffice.org will hang when you try to open a file from a NFS mounted directory from a Linux computer. " - figure out what kindof configuration is worthwhile - then how to save that to the OpenOffice-net-installer/share and OpenOffice-net-installer/user directories so each user gets the same pre-configured copy of the application Is the trick to run the 2nd user setup at OpenOffice-net-installer *from each workstation* so that (hopefully non user specific) registry settings are made? if thats the case the only reason to do it from each workstation is to configure the registry, and that could be done far more elegantly with automation. It seems the first installation copies files, copies something I don't understand and registers DLLs (there's no uninstaller for this other than manual delete?). The second configures the user environment and registry for that workstation (no user-specific registry settings, the profile is used in place of the registry). (Mozilla likely does the same splitting of installation but automates the whole process, automatically setting itself up for each user profile. but Mozilla's way doesn't configure workstations' registry as it automates the process of running for each user, which is useful, but the down-side is bcos that part of the setup isn't able to be run from each workstation you don't get the opportunity to configure workstation registries; of-course the server's appropriate registry keys can be exported and automatedly installed on workstations.) ------------------------------------------------ OpenOffice - install workstation files to ------------------------------------------------ /home/samba/profiles/%username%/openoffice \\file-server\user-home\openoffice k:\openoffice --------------------------------------------- Mozilla --------------------------------------------- Roaming is two things: that which helps OS-level roaming happen and Mozilla Roaming Profiles themselves, roaming beyond the confines of yr OS Actually, 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". on installation, Mozilla automatically creates a default profile for each user. this is an improvement on Netscape 4 where you had to create them using the Profile Manager all instances of WINDIR: http://lxr.mozilla.org/seamonkey/search?string=WINDIR can we set %WINDIR% to be a network drive? it looks like only NSS and the installer use %WINDIR% NSS is crypto presumably this means only they *write* to %WINDIR%, whereas other parts *read* %WINDIR%\nsswft.swf is one use -------------------------------------------------------------- files: ------ there appears to be no files in C: that need to be written to; nothing relating to a user that lives outside of their Windows profile and Mozilla profile. however files on C: do need to be read. and what of the registry? is that written to? %WINDIR%\mozver.dat the version registry. describes a lot of Mozilla components, their version numbers, and directory locations. gets updated with each new installation. so would it need propogating around initially and when new versions get installed? #define WIN_VERREG "\\mozver.dat" WILL BE RECREATED WHEN ITS NOT THERE ON EACH WORKSTATION? %WINDIR%\nsreg.dat (Netscape 4 profile information. points to the profile location, and as its not user specific (as its in WINNT rather than an individual user's profile) its totally at odds with OS-level roaming). this doesn't get updated with each new installation as its particular to the profile BUT in Netscape 4 this atleast described all available profiles, so you get given the option of which profile you'd like to use so if a new profile is created this file needs propogating around all workstations Mozilla only uses this for compatibility. perhaps only in profile migration: http://lxr.mozilla.org/seamonkey/search?string=nsreg.dat name of global cross-platform registry (http://lxr.mozilla.org/seamonkey/source/security/nss/cmd/lib/filestub.c#914) /* 4.x and 5.x file names */, known as PM_REGFILE_4 and OLD_REGISTRY_FILE_NAME **************it doesn't *appear* to be used to write to **perhaps replaced by %APPDATA%\Mozilla\registry.dat? ONLY LEFT IN MOZILLA BY MISTAKE? %WINDIR%\MOZILLA_UNINSTALL.EXE wouldn't need to be on a workstation anyway %APPDATA%\Mozilla\registry.dat describes where the profile directory is and MIME types remains here despite moving the profile directory (there's a bug on this) registry settings: ------------------ HKLM/SOFTWARE/Mozilla/ HKLM/SOFTWARE/Mozilla.org/ HKEY_USERS/-ID-/Mozilla/ HKEY_USERS/-ID-/Mozilla.org/ (HKEY_CURRENT_USER\software\) what did we do for Netscape's registry settings at ****? did we re-create them on each workstation? registry keys are version specific so would need updating with each Mozilla update HKCU entries on installation only contain directory locations same with HKLM, other than HKLM/SOFTWARE/Mozilla/Desktop contains software classes (file type associations and ?lower level helper applications?) and file associations Plugins ------- "you can set MOZ_PLUGIN_PATH env variable to point to any place you like to contain plugins. Just remember, it's can contain SINGLE directory name, not list of dirs" --------------------------------------------- Mozilla: --enable-optimize="-O2 -march=athlon-xp" --------------------------------------------- far as I can see, if setup Mozilla for someone to run on Win2000, pre-configured using all.js, using a different partition for temp space other than where %APPDATA% lives, I can't leave it with the user and they create new profiles that will work the same as the 1st, as the only way I can see to define the cache location (because Mozilla doesn't respect Window NT's default location for temp space), is to be there to manually copy over a pre-configured USER.JS containing a user-specific cache location to their Mozilla profile. if there were somewhere in the Mozilla program directory to define a configuration that would be used to build a USER.JS (a means that allowed me to use a %USERNAME% environment variable) then this would fix this lunacy --------------------------------------------- Q: I am an administrator. How can I install IrfanView on a server with same settings for all users? A: 1) Install IrfanView on the server 2) Set your IrfanView options in IrfanView (properties etc.). Now, set the INI file "i_view32.ini" to read only. The users can't change IrfanView options anymore. 3) To prevent the registry changes (associations), you can hide the Properties->Extensions dialog. Write in the INI file: ShowExtensionsDlg=0 in section [Extensions]. --------------------------------------------- --------------------------------------------- By default, the folders History, Local Settings, Temp, and Temporary Internet Files do no "roam" with the user. You can specify additional files that you'd like to exclude from the roaming profile. Run the Group Policy utility and modify the Exclude Directories in Roaming Profile policy. You can find it under User Configuration \Administrative Templates\System\Logon-Logoff. This policy modifies the text file C:\Documents and Settings\\NTUSER.INI ~~~~~~~~~~~~~~~~~~~~~~ install it to the server as Administrator. new user logs in at workstation and runs it for the first time, Mozilla creates a fresh Mozilla profile in the user's Windows Profile (based on a standard Mozilla profile stored in the Mozilla program directory). no need to run the seperate profile creator as you have to in OpenOffice, Mozilla does that for you automagically. You'd want to use the USER.JS or ALL.JS to pre-configure it ~~~~~~~~~~~~~~~~~~~~~~ // * perhaps you have instead to set the location Mozilla uses by default* // * for its profile, and thus below that its cache, to live in a * // * per-user location - if you can't force it automatically to choose a * // * per-user location for the cache alone then you might have to * // * compromise and move the whole profile. this isn't good enough tho. * // * How else can we slide in a name into ALL.JS then? // * do we put it instead in USER.JS, by hand, after they've run Mozilla* // * for the 1st time? using a command-line script that creates a * // * USER.JS with the JS lines and inserts the %USERNAME% in the cache * // * location? no, cos we wouldn't know the name of the salted profile * // * directory * // - (can't access env vars from JS and shell scripts can't guess the salted profile directory name ------------------- files: ------ there appears to be no files in C: that need to be written to; nothing relating to a user that lives outside of their Windows profile and Mozilla profile. however files on C: do need to be read. and what of the registry? is that written to? %WINDIR%\mozver.dat the version registry. describes a lot of Mozilla components, their version numbers, and directory locations. gets updated with each new installation. so would it need propogating around initially and when new versions get installed? #define WIN_VERREG "\\mozver.dat" WILL BE RECREATED WHEN ITS NOT THERE ON EACH WORKSTATION? %WINDIR%\nsreg.dat (Netscape 4 profile information. points to the profile location, and as its not user specific (as its in WINNT rather than an individual user's profile) its totally at odds with OS-level roaming). this doesn't get updated with each new installation as its particular to the profile BUT in Netscape 4 this atleast described all available profiles, so you get given the option of which profile you'd like to use so if a new profile is created this file needs propogating around all workstations Mozilla only uses this for compatibility. perhaps only in profile migration: http://lxr.mozilla.org/seamonkey/search?string=nsreg.dat name of global cross-platform registry (http://lxr.mozilla.org/seamonkey/source/security/nss/cmd/lib/filestub.c#914) /* 4.x and 5.x file names */, known as PM_REGFILE_4 and OLD_REGISTRY_FILE_NAME **************it doesn't *appear* to be used to write to **perhaps replaced by %APPDATA%\Mozilla\registry.dat? ONLY LEFT IN MOZILLA BY MISTAKE? %WINDIR%\MOZILLA_UNINSTALL.EXE wouldn't need to be on a workstation anyway %APPDATA%\Mozilla\registry.dat describes where the profile directory is and MIME types remains here despite moving the profile directory (there's a bug on this) registry settings: ------------------ HKLM/SOFTWARE/Mozilla/ HKLM/SOFTWARE/Mozilla.org/ HKEY_USERS/-ID-/Mozilla/ HKEY_USERS/-ID-/Mozilla.org/ (HKEY_CURRENT_USER\software\) what did we do for Netscape's registry settings at ECRA? did we re-create them on each workstation? registry keys are version specific so would need updating with each Mozilla update HKCU entries on installation only contain directory locations same with HKLM, other than HKLM/SOFTWARE/Mozilla/Desktop contains software classes (file type associations and ?lower level helper applications?) DOES MOZILLA CREATE SETTINGS IN THE REGISTRY FOR EACH USER? OR ATLEAST IN A REGISTRY COPY THAT GETS COPIED TO EACH NEW USER CREATED? (WOULD THIS BE .DEFAULT?) and file associations Plugins ------- "you can set MOZ_PLUGIN_PATH env variable to point to any place you like to contain plugins. Just remember, it's can contain SINGLE directory name, not list of dirs" RCS 1.0 ------- - will benefit from having cache local. we ignored temp/cache stuff entirely, and are copying the Netscape cache back and forth on login/logoff use Windows' loal settings folder? use browser.cache.directory in all.js? see bug 74085 - will benefit by mailto: links always working - what needs to be migrated from NS to Moz? - bookmarks - ? - what preferences do they want? offer mine (when updated) as an example - what preference files need to be pre configured - must pay attention to plugins and their registry settings --------------------------------------------- the Netscape icon's command-line should read: p:\netscape\netscape.exe -P"%username%" where the profile name is the same as the username =========================================================================== the areas to consider for doing this with any application are: [1] what Windows registry HKEY_LOCAL_MACHINE settings does it make, and will it automatically make them if they're not in the machine's registry when you run the program (as opposed to the installer) [2] if the software is multi-user aware, what Windows registry HKEY_CURRENT_USER settings does it make, and will it automatically make them if they're not in the user's registry when they run the program (as opposed to the installer) [3] if the software is multi-user aware, does it create user profiles automatically or do they need to be made manually using an associated program (OpenOffice does this) [4] and what files does it copy to atleast %WINDIR%; %WINDIR%\SYSTEM; %WINDIR%\SYSTEM32; %SYSTEMDRIVE%\Program Files\Common Files because Mozilla is cross-platform, it is very aware of running in a multi-user environment. it saves its settings in its own file (rather than a platform- specific implementation like the registry) and has one of those files per-user, thus Windows registry settings are minimal. Mozilla automatically re-creates HKEY_CURRENT_USER [1] and the profile [3] if they're not already there. I don't know about HKEY_LOCAL_MACHINE [1], but Asa appears to be suggesting it will automatically create settings here too. Mozilla copies 3 files to %WINDIR%: MozillaUninstall.exe which is just for uninstallation; MOZVER.DAT (which is automatically re-created if not present) and NSREG.DAT (which looks to be redundant (bug 142367)) ============================================ editing Mozilla's title bar: - using a compression utility open the mozilla\chrome\en-US.jar file so that you can see what files it contains; - find the NAVIGATOR.DTD file in the list (not NAVIGATOR-TITLE.DTD as the previous poster instructed); - double click on it or do whatever is required with your operating system to open it into a plain text editor (i.e. NotePad, you're better off not using WordPad as its more than just a plain text editor, and you're better using a fully fledged plain text editor such as NoteTab Light or something) - find the line with the {&buildId.label;} text (Edit -> Find); - change that {&buildId.label;} to whatever text, if any, that you want to appear in your title - save the file - close the plain text editor - the compression utility should recognise the file within the JAR package has changed and prompt you asking if you want it to re-compile the package - run Mozilla. if you did anything wrong it will tell you where the mistake is ================================= HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org HKEY_CURRENT_USER\Software\Mozilla HKEY_CURRENT_USER\Software\mozilla.org ==================================== A patch to enable autodialing on Windows NT-based systems. network.autodial-helper.enabled This patch adds autodial helper capabilities to Mozilla running on NT-based systems. First, it tries to use the Windows RAS Autodial Service if it is running. To get around the problem of that service not working if a network card is installed, this patch adds the network address in question to the RAS autodial database to force the service to dial when that address is unreachable. So if an normal network connection fails, autodial will kick in. Or if a new machine is shipped with both a network card and a modem, but the network card isn't connected to anything, autodial will kick in. If that service is not running, then it looks at the Control Panel | Internet Options settings. If the autodial setting is set to "always" or "when a network is not present", it uses the RAS API to dial the default connection on network errors. This patch should only affect Windows NT 4, 2000, and XP, and should not break Windows 9x. Also, it shouldn't break the builds on Mac and Linux or interfere with proper network operation on these systems. So far I have only been able to test on Windows 2000 and XP Pro. The code should autodial for all apps (browser, mail, aim, chatzilla, etc,) whenever a network address is ureachable. It's going to require significant scrutiny and testing as this is a high visibility area and the patch is almost 1200 lines. All the code in nsAutodialWin.* is mine. Darin has graciously provided the hooks into necko in the patch. ===================================================== Mozilla Venkman: ------- Additional Comment #3 From Robert Ginda 2002-07-17 18:58 ------- This check-in made the tinderbox numbers go up. Sorry, I should have disclaimed this before I checked in. The numbers go up *only* when the debugger UI is installed. The extra time is spent instrumenting JSScript*s as they are created, something we *have* to do if we want to be able to debug scripts that were loaded before the debugger UI is started. Based on feedback from previous Venkman releases, most users expect that to Just Work, and so the "init at startup" option was enabled by default. Users who want the debugger installed, but are willing to trade init-at-startup for speed can type "startup-init off" in the Venkman "Interactive Session" view. ===================================================== to turn on 'favicon' support, add this line to PREFS.JS: pref("browser.chrome.favicons", true); "From what I can tell, plugins aren't so much installed as they are resident in the /plugins directory. Some require a registry entry for confirmation of a EULA, but after accepting it things should work as if the plugin were on disk. I'll have to test it all out, though." ===================================================== ===================================================== PEGASUS MAIL ===================================================== settings worth using environment variables for: ----------------------------------------------- [general] ? (this is the 'default') [WinPMail Identity - ******] Personal-name Home-mailbox-location Folder-for-copies-to-self Startup-directory Printer-device-name Printer-driver-name Printer-port Host-where-POP3-mail-account-is-located POP3-mail-account Directory-to-place-incoming-POP3-mail SMTP-relay-host-for-outgoing-mail Search-mask-to-locate-outgoing-messages Alternative-From-field-for-message [Pegasus Mail for Windows - Run Info] Internal-username Working-home-mailbox-location New-mailbox-location other parts with user-specific info: ------------------------------------ [general] ? (this is the 'default') [Pegasus Mail for Windows - Identities] Name = *** Name = ****** [WinPMail Identity - ******] Personal name Home mailbox location Folder for copies to self Startup directory Printer device name Printer driver name Printer port Host where POP3 mail account is located POP3 mail account (username on host) V3 Password for POP3 mail account Directory to place incoming POP3 mail = G:\MAIL\p SMTP relay host for outgoing mail Search mask to locate outgoing messages = G:\MAIL\p\*.PMX Alternative From: field for message [Pegasus Mail for Windows - Run Info] Internal username Working home mailbox location = G:\MAIL\p New mailbox location = G:\MAIL\p =====================================================