summaryrefslogtreecommitdiff
path: root/docs/textdocs
diff options
context:
space:
mode:
authorLuke Leighton <lkcl@samba.org>1998-04-11 14:00:37 +0000
committerLuke Leighton <lkcl@samba.org>1998-04-11 14:00:37 +0000
commit9e5870d92fb417ae671822395439e8f875b0ec5e (patch)
treebfab7f50f948f03387a5655f1530f86103ccdd57 /docs/textdocs
parentc0c2353b77021389480ddd2cab887ea8f31769ed (diff)
downloadsamba-9e5870d92fb417ae671822395439e8f875b0ec5e.tar.gz
samba-9e5870d92fb417ae671822395439e8f875b0ec5e.tar.bz2
samba-9e5870d92fb417ae671822395439e8f875b0ec5e.zip
created from a really useful discussion about Win95 / NT profiles.
Contributors: Bruce Cook <BC3-AU@bigfoot.com> Copyright (C) 1998 Bruce Cook John Terpestra <samba-bugs@samba.anu.edu.au> Copyright (C) 1998 John H. Terpestra Wolfgang Ratzka <ratzka@hrz.uni-marburg.de> Copyright (C) 1998 Wolfgang Ratzka (This used to be commit 2d7d013e0ca8fc2e97eb8299e3d847c57c40ed1c)
Diffstat (limited to 'docs/textdocs')
-rw-r--r--docs/textdocs/PROFILES.txt285
1 files changed, 285 insertions, 0 deletions
diff --git a/docs/textdocs/PROFILES.txt b/docs/textdocs/PROFILES.txt
new file mode 100644
index 0000000000..88fdece516
--- /dev/null
+++ b/docs/textdocs/PROFILES.txt
@@ -0,0 +1,285 @@
+Contributors: Bruce Cook <BC3-AU@bigfoot.com>
+ Copyright (C) 1998 Bruce Cook
+
+ John Terpestra <samba-bugs@samba.anu.edu.au>
+ Copyright (C) 1998 John H. Terpestra
+
+ Wolfgang Ratzka <ratzka@hrz.uni-marburg.de>
+ Copyright (C) 1998 Wolfgang Ratzka
+
+Created: April 11, 1998
+Updated: April 11, 1998
+
+Subject: User Profiles
+===========================================================================
+
+From BC3-AU@bigfoot.com Sat Apr 11 13:36:05 1998
+Date: Sat, 11 Apr 1998 17:13:49 +1000
+From: Bruce Cook <BC3-AU@bigfoot.com>
+To: Multiple recipients of list <samba-ntdom@samba.anu.edu.au>
+Subject: RE: A question about NT Domains
+
+Luke Kenneth Casson Leighton writes:
+ > On Fri, 10 Apr 1998, Jean-Francois Micouleau wrote:
+ >
+ > > On Fri, 10 Apr 1998, Luke Kenneth Casson Leighton wrote:
+ > >
+ > > > ah, then i need to explain better. two or more users have identical
+ > > > profiles. say only one user installs a program which adds additional keys
+ > > > into the registry. those keys, as i understand it, will *not* be removed
+ > > > from HKEY_LOCAL_USER when subsequent users log in.
+ > >
+ > > under W95 or NT ?
+ >
+ > my experience is with Win95, but i expect the same for NT, and have been
+ > told that it is so by someone who runs NT admin training courses.
+ >
+ > > and why do you want to have one profile shared between multiples users ?
+ >
+ > you don't. how did you get that impression? i said multiple users with
+ > identical profiles, not multiple users sharing one profile.
+
+In my experience with both Win95 and NT, is that the HKEY_LOCAL_USER information
+is stored in USER.dat or NTuser.DAT for NT. ALL of this branch is in this file
+and there is no overlap between any two users (Unless you have '95 set up
+to use a single common profile).
+
+[** lkcl: see jht's message for conditions under which an overlap can occur **]
+
+The HKEY_LOCAL_MACHINE branch is machine based, and shared by all users of that
+machine.
+
+
+[And now for a whole stack of caveats]
+
+1. User start menu paths are not stored in the registry (obviously) they're
+ a directory structure that located by settings in HKEY_LOCAL_USER.
+
+ If you want start menues / desktop / favorites to be individual to a user
+ you must set up your user registry so these can be located individually.
+ The easiest tool to manage this is the policy editor.
+
+2. When you log onto 'Doze 95, it has to find the user registry.
+
+
+ If you have specified a common profile, a "default user" USER.DAT is used.
+
+ If you have specified individualised profiles, then USER.DAT will be found
+ by the following formula:
+
+ 1. if NET USE x: /HOME was used at startup, try for x:\USER.DAT (where
+ x: is any drive letter from A to Z.
+ if no USER.DAT is found go to step 3
+
+ 2. if no home is specified in a mapping,
+ ...\windows\profiles\username\USER.DAT is used. If no USER.DAT exists
+ go to step 3.
+
+ 3. If neither of the previous two found a USER.DAT, then it will use
+ a prototype USER.DAT which it will later save to the above specified
+ path when the user logs out.
+
+ The interesting thing here is that the prototype USER.DAT used here
+ is actually a copy of the last USER.DAT used on this machine. (This
+ may be the effect that the original poster is seeing)
+
+ 4. As discussed above the start menu and desktop are specified in the
+ registry contained within USER.DAT. When a new USER.DAT is created
+ from a prototype, new directories are created for the start menu and
+ desktop ACCORDING TO HOW THE COPIED PROTOTYPE DEFINES THEM.
+
+ So if the prototype USER.DAT says that start menu is in H:\Start Menu
+ but programs folder is C:\windows\start menu\programs, then the
+ H:\start menu will be created, and the existing machine programs
+ folder used.
+
+ This means that is is important when creating roving profiles to get
+ your prototype USER.DAT and general user directory structure set up
+ exactly as you want it, and then make a copy of it that you know will
+ be safe from modification. When creating a new user you then copy
+ this prototype into the new user area, so that the new user doesn't
+ just inherit what the previous user had.
+
+
+3. When you log onto 'Doze NT, it has to find the user registry.
+
+
+ NT is easier to see what's going on, but follows much the same rules as
+ '95. The big difference being that 'NT gets its profile location from
+ the login server when it's logged in. (On an NT system have a look at user
+ manager/user/profile - you will see that you can specify the user profile
+ path) Under NT3.51 this profile path was a path to NTuser.DAT, on 4.0 this
+ seems to be a path to a directory structure (haven't played with many NT4
+ servers)
+
+ I'm not sure how this works in samba, as I haven't yet tried the NT_DOM stuff
+ yet (Luke: I assume you have a keyword for this?)
+
+[lkcl: nt workstations should look in exactly the same places for things on
+ samba or other SMB servers as they do on an NT server, as long as that
+ SMB server looks like NT. if anyone finds that something fails, alert
+ us on samba-bugs@samba.anu.edu.au and we'll look into it].
+
+ When an NT system find a user without a NTuser.DAT, it copies from a
+ prototype that it stores especially for this purpose, so while unlike '95
+ the user doesn't get whatever happened last on the machine, the user will
+ get a fairly minimalist configuration.
+
+
+4. There are a *LOT* of reasons that the 'doze machine might not find USER.DAT
+ and therefore default to a prototype.
+
+ 1. Can't execute logon script & therefore no /HOME mapping (Most common)
+ .Make sure the script exists
+ .that you have your logon script set right
+ .Netlogon share must exist
+ .Protection/ownership of the script and share
+
+ 2. no /HOME mapping in the logon script
+
+ 3. no home path specified in /etc/smb.conf (Or no home mapping set
+ up for that user in NT's user manager)
+
+ 4. Protection/ownership of the user directory
+
+ 5. protection/ownership of USER.DAT
+
+ 6. basic networking problems
+ .Is the networking available (Test it by manually mapping
+ to both the user share and netlogon share)
+ .Was the networking working during logon ?
+
+ 7. Has it defaulted to a prototype, and then had you map the home
+ directory afterwards ? - This will result in the bad prototype
+ being written into the users home, and them being stuck with it,
+ (Just replace USER.DAT again)
+
+
+5. Interesting NOTE
+
+ When '95 is performing the logon script, the HKEY_LOCAL_USERS has
+ NOT been mapped from the USER.DAT. What has been mapped at this stage
+ is the prototype registry (last one used).
+
+ I assume the reason for this is that '95 is waiting for the logon
+ script to complete so that it can identify where the user's home
+ directory is.
+
+ If at this point you attempt to do anything that uses the USER registry,
+ (installing something for example or reading something from the user
+ registry) you will actually be operating on the machine stored prototype
+ profile not the user profile. This means that nothing will realy
+ happen to the user setup (No menu items, no settings etc).
+
+ To get around this you can name a process in the "run once" entries in
+ the HKEY_LOCAL_MACHINE branch, and these "run once" processes will be
+ executed once the USER.DAT is loaded, and all the user directories are
+ accessible.
+
+
+To sum up:
+
+ NET USE H: /HOME
+ is the key to getting your user profiles loaded from a server.
+ NET USE H: \\server\homes
+ Won't get it right without a lot of stuffing about.
+
+ Windoze '95 goes through a lot to bring you your user profile and
+ if anything goes wrong during this process, it will drop back to
+ using whatever profile was last used on the machine.
+
+
+From samba@aquasoft.com.au Sat Apr 11 13:48:54 1998
+Date: Sat, 11 Apr 1998 09:34:08 +1000
+From: Samba Bugs <samba@aquasoft.com.au>
+To: Multiple recipients of list <samba-ntdom@samba.anu.edu.au>
+Subject: Re: A question about NT Domains
+
+Just for the sake of completeness I thought I'd add a bit to this.
+Let's be clear about which files affect registry changes (or contents).
+
+Under NT, open a command prompt interface:
+cd %SystemRoot%\System32\config
+dir
+
+The standard registry files are:
+ Default - all component default settings
+ System - all HKLM\System entries
+ Software - all HKLM\Software entries
+ Security - Domain/Machine releated User Rights & Privs.
+ SAM - the Security Access Manager database (ie:Passwords etc.)
+
+These are used by EVERYTHING!!
+
+When a user logs in the following files get checked:
+ 1) \\"Authenticating Server"\NETLOGON\NTConfig.Pol
+ 2) %SystemRoot%\Profiles\Policies\NTConfig.Pol
+ this one is a copy of the last NTConfig.Pol downloaded
+ from (1) above - if available.
+ 3) %SystemRoot%\Policies\%UserName%\NTUser.DAT
+
+The later, is first obtained from a profile server if the User_Init_Info
+passed from the Domain Logon Server specifies use of a roaming profile.
+If item (3) does NOT exist and/or NO default profile is available one gets
+created from the system default settings PLUS the last loaded file at item
+(2) above.
+
+The HKCU is always unique to the currently logged in user, BUT if the
+currently logged in user is using a shared profile that has NOT been made
+exclusive then on logout the HKCU will be written over the top of the
+source files. That is why Mandatory profiles are essential when sharing a
+roaming profile.
+
+On Sat, 11 Apr 1998, Wolfgang Ratzka wrote:
+
+> Luke Kenneth Casson Leighton wrote:
+>
+> > my experience is with Win95, but i expect the same for NT, and have been
+> > told that it is so by someone who runs NT admin training courses.
+>
+> On NT it is quite definitely not so. HKCU will always be loaded completely from
+> the user's NTuser.dat file and unloaded again after logout.
+> In fact HKCU is not a proper registry hive but a symbolic reference to the subkey of
+> HKEY_USERS that corresponds to the current user. If more than one user
+> is active on an NT machine (on plain vanilla NT this *is* possible if you have
+> services running as a non-system user; on WinFrame or Hydra multiple users
+> can be logged in) you will see several subkeys of HKU that correspond to
+> the active users and don't interfere with each other.
+>
+> Of course some settings that a user can change do not go into the HKCU hive
+> but into HKLM, most notably the screen resolution and the number of colours
+> (you can use policies to prevent user's from changing these).
+> Some applications put information that should go into HKCU into HKLM instead.
+> (Hall of Shame: Netscape Communicator, Microsoft Office 97 [User dictionaries!]...).
+> Others just use plain good old INI files in their program directory or even
+> in \WINNT\SYSTEM32. Those changes will not be user specific but machine
+> specific and those programs will cause trouble, when one tries to run them
+> on WinFrame or Hydra... :-).
+>
+> Summarizing:
+>
+> Q: Will the next user inherit a previous user's additions
+> to the HKCU registry hive?
+> A: Quite definitely not.
+
+Correct.
+
+>
+> Q: Can a user foul up the configuration for the next user?
+> A: Quite definitely yes!
+
+See above. Yes, but not if correctly configured.
+
+>
+> Q: Is this discussion out of place on the samba-ntdom list?
+> A: Errr....
+
+Errr... Really? I think it is. Do we, or do we not, want to help people to
+gain stable and dependable use of samba?
+
+> --
+> Wolfgang Ratzka (dialing in from home)
+
+Cheers,
+John H Terpstra (Also from home!!!!)
+