1 Contributors: Bruce Cook <BC3-AU@bigfoot.com>
2 Copyright (C) 1998 Bruce Cook
4 John Terpestra <samba-bugs@samba.anu.edu.au>
5 Copyright (C) 1998 John H. Terpestra
7 Wolfgang Ratzka <ratzka@hrz.uni-marburg.de>
8 Copyright (C) 1998 Wolfgang Ratzka
10 Created: April 11, 1998
11 Updated: April 11, 1998
13 Subject: User Profiles
14 ===========================================================================
16 From BC3-AU@bigfoot.com Sat Apr 11 13:36:05 1998
17 Date: Sat, 11 Apr 1998 17:13:49 +1000
18 From: Bruce Cook <BC3-AU@bigfoot.com>
19 To: Multiple recipients of list <samba-ntdom@samba.anu.edu.au>
20 Subject: RE: A question about NT Domains
22 Luke Kenneth Casson Leighton writes:
23 > On Fri, 10 Apr 1998, Jean-Francois Micouleau wrote:
25 > > On Fri, 10 Apr 1998, Luke Kenneth Casson Leighton wrote:
27 > > > ah, then i need to explain better. two or more users have identical
28 > > > profiles. say only one user installs a program which adds additional keys
29 > > > into the registry. those keys, as i understand it, will *not* be removed
30 > > > from HKEY_LOCAL_USER when subsequent users log in.
34 > my experience is with Win95, but i expect the same for NT, and have been
35 > told that it is so by someone who runs NT admin training courses.
37 > > and why do you want to have one profile shared between multiples users ?
39 > you don't. how did you get that impression? i said multiple users with
40 > identical profiles, not multiple users sharing one profile.
42 In my experience with both Win95 and NT, is that the HKEY_LOCAL_USER information
43 is stored in USER.dat or NTuser.DAT for NT. ALL of this branch is in this file
44 and there is no overlap between any two users (Unless you have '95 set up
45 to use a single common profile).
47 [** lkcl: see jht's message for conditions under which an overlap can occur **]
49 The HKEY_LOCAL_MACHINE branch is machine based, and shared by all users of that
53 [And now for a whole stack of caveats]
55 1. User start menu paths are not stored in the registry (obviously) they're
56 a directory structure that located by settings in HKEY_LOCAL_USER.
58 If you want start menues / desktop / favorites to be individual to a user
59 you must set up your user registry so these can be located individually.
60 The easiest tool to manage this is the policy editor.
62 2. When you log onto 'Doze 95, it has to find the user registry.
65 If you have specified a common profile, a "default user" USER.DAT is used.
67 If you have specified individualised profiles, then USER.DAT will be found
68 by the following formula:
70 1. if NET USE x: /HOME was used at startup, try for x:\USER.DAT (where
71 x: is any drive letter from A to Z.
72 if no USER.DAT is found go to step 3
74 2. if no home is specified in a mapping,
75 ...\windows\profiles\username\USER.DAT is used. If no USER.DAT exists
78 3. If neither of the previous two found a USER.DAT, then it will use
79 a prototype USER.DAT which it will later save to the above specified
80 path when the user logs out.
82 The interesting thing here is that the prototype USER.DAT used here
83 is actually a copy of the last USER.DAT used on this machine. (This
84 may be the effect that the original poster is seeing)
86 4. As discussed above the start menu and desktop are specified in the
87 registry contained within USER.DAT. When a new USER.DAT is created
88 from a prototype, new directories are created for the start menu and
89 desktop ACCORDING TO HOW THE COPIED PROTOTYPE DEFINES THEM.
91 So if the prototype USER.DAT says that start menu is in H:\Start Menu
92 but programs folder is C:\windows\start menu\programs, then the
93 H:\start menu will be created, and the existing machine programs
96 This means that is is important when creating roving profiles to get
97 your prototype USER.DAT and general user directory structure set up
98 exactly as you want it, and then make a copy of it that you know will
99 be safe from modification. When creating a new user you then copy
100 this prototype into the new user area, so that the new user doesn't
101 just inherit what the previous user had.
104 3. When you log onto 'Doze NT, it has to find the user registry.
107 NT is easier to see what's going on, but follows much the same rules as
108 '95. The big difference being that 'NT gets its profile location from
109 the login server when it's logged in. (On an NT system have a look at user
110 manager/user/profile - you will see that you can specify the user profile
111 path) Under NT3.51 this profile path was a path to NTuser.DAT, on 4.0 this
112 seems to be a path to a directory structure (haven't played with many NT4
115 I'm not sure how this works in samba, as I haven't yet tried the NT_DOM stuff
116 yet (Luke: I assume you have a keyword for this?)
118 [lkcl: nt workstations should look in exactly the same places for things on
119 samba or other SMB servers as they do on an NT server, as long as that
120 SMB server looks like NT. if anyone finds that something fails, alert
121 us on samba-bugs@samba.anu.edu.au and we'll look into it].
123 When an NT system find a user without a NTuser.DAT, it copies from a
124 prototype that it stores especially for this purpose, so while unlike '95
125 the user doesn't get whatever happened last on the machine, the user will
126 get a fairly minimalist configuration.
129 4. There are a *LOT* of reasons that the 'doze machine might not find USER.DAT
130 and therefore default to a prototype.
132 1. Can't execute logon script & therefore no /HOME mapping (Most common)
133 .Make sure the script exists
134 .that you have your logon script set right
135 .Netlogon share must exist
136 .Protection/ownership of the script and share
138 2. no /HOME mapping in the logon script
140 3. no home path specified in /etc/smb.conf (Or no home mapping set
141 up for that user in NT's user manager)
143 4. Protection/ownership of the user directory
145 5. protection/ownership of USER.DAT
147 6. basic networking problems
148 .Is the networking available (Test it by manually mapping
149 to both the user share and netlogon share)
150 .Was the networking working during logon ?
152 7. Has it defaulted to a prototype, and then had you map the home
153 directory afterwards ? - This will result in the bad prototype
154 being written into the users home, and them being stuck with it,
155 (Just replace USER.DAT again)
160 When '95 is performing the logon script, the HKEY_LOCAL_USERS has
161 NOT been mapped from the USER.DAT. What has been mapped at this stage
162 is the prototype registry (last one used).
164 I assume the reason for this is that '95 is waiting for the logon
165 script to complete so that it can identify where the user's home
168 If at this point you attempt to do anything that uses the USER registry,
169 (installing something for example or reading something from the user
170 registry) you will actually be operating on the machine stored prototype
171 profile not the user profile. This means that nothing will realy
172 happen to the user setup (No menu items, no settings etc).
174 To get around this you can name a process in the "run once" entries in
175 the HKEY_LOCAL_MACHINE branch, and these "run once" processes will be
176 executed once the USER.DAT is loaded, and all the user directories are
183 is the key to getting your user profiles loaded from a server.
184 NET USE H: \\server\homes
185 Won't get it right without a lot of stuffing about.
187 Windoze '95 goes through a lot to bring you your user profile and
188 if anything goes wrong during this process, it will drop back to
189 using whatever profile was last used on the machine.
192 From samba@aquasoft.com.au Sat Apr 11 13:48:54 1998
193 Date: Sat, 11 Apr 1998 09:34:08 +1000
194 From: Samba Bugs <samba@aquasoft.com.au>
195 To: Multiple recipients of list <samba-ntdom@samba.anu.edu.au>
196 Subject: Re: A question about NT Domains
198 Just for the sake of completeness I thought I'd add a bit to this.
199 Let's be clear about which files affect registry changes (or contents).
201 Under NT, open a command prompt interface:
202 cd %SystemRoot%\System32\config
205 The standard registry files are:
206 Default - all component default settings
207 System - all HKLM\System entries
208 Software - all HKLM\Software entries
209 Security - Domain/Machine releated User Rights & Privs.
210 SAM - the Security Access Manager database (ie:Passwords etc.)
212 These are used by EVERYTHING!!
214 When a user logs in the following files get checked:
215 1) \\"Authenticating Server"\NETLOGON\NTConfig.Pol
216 2) %SystemRoot%\Profiles\Policies\NTConfig.Pol
217 this one is a copy of the last NTConfig.Pol downloaded
218 from (1) above - if available.
219 3) %SystemRoot%\Policies\%UserName%\NTUser.DAT
221 The later, is first obtained from a profile server if the User_Init_Info
222 passed from the Domain Logon Server specifies use of a roaming profile.
223 If item (3) does NOT exist and/or NO default profile is available one gets
224 created from the system default settings PLUS the last loaded file at item
227 The HKCU is always unique to the currently logged in user, BUT if the
228 currently logged in user is using a shared profile that has NOT been made
229 exclusive then on logout the HKCU will be written over the top of the
230 source files. That is why Mandatory profiles are essential when sharing a
233 On Sat, 11 Apr 1998, Wolfgang Ratzka wrote:
235 > Luke Kenneth Casson Leighton wrote:
237 > > my experience is with Win95, but i expect the same for NT, and have been
238 > > told that it is so by someone who runs NT admin training courses.
240 > On NT it is quite definitely not so. HKCU will always be loaded completely from
241 > the user's NTuser.dat file and unloaded again after logout.
242 > In fact HKCU is not a proper registry hive but a symbolic reference to the subkey of
243 > HKEY_USERS that corresponds to the current user. If more than one user
244 > is active on an NT machine (on plain vanilla NT this *is* possible if you have
245 > services running as a non-system user; on WinFrame or Hydra multiple users
246 > can be logged in) you will see several subkeys of HKU that correspond to
247 > the active users and don't interfere with each other.
249 > Of course some settings that a user can change do not go into the HKCU hive
250 > but into HKLM, most notably the screen resolution and the number of colours
251 > (you can use policies to prevent user's from changing these).
252 > Some applications put information that should go into HKCU into HKLM instead.
253 > (Hall of Shame: Netscape Communicator, Microsoft Office 97 [User dictionaries!]...).
254 > Others just use plain good old INI files in their program directory or even
255 > in \WINNT\SYSTEM32. Those changes will not be user specific but machine
256 > specific and those programs will cause trouble, when one tries to run them
257 > on WinFrame or Hydra... :-).
261 > Q: Will the next user inherit a previous user's additions
262 > to the HKCU registry hive?
263 > A: Quite definitely not.
268 > Q: Can a user foul up the configuration for the next user?
269 > A: Quite definitely yes!
271 See above. Yes, but not if correctly configured.
274 > Q: Is this discussion out of place on the samba-ntdom list?
277 Errr... Really? I think it is. Do we, or do we not, want to help people to
278 gain stable and dependable use of samba?
281 > Wolfgang Ratzka (dialing in from home)
284 John H Terpstra (Also from home!!!!)