Updating TOSHARG files

(This used to be commit 2ada75f02f4ba7de548a56a14f1bb0281029e063)

1 files changed, 109 insertions, 26 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-ProfileMgmt.xml b/docs/Samba3-HOWTO/TOSHARG-ProfileMgmt.xml
index 6cdf87b54f..d5cc6e93aa 100644
--- a/docs/Samba3-HOWTO/TOSHARG-ProfileMgmt.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-ProfileMgmt.xml
@@ -12,17 +12,20 @@
 <title>Features and Benefits</title>
 
 <para>
+<indexterm><primary>roaming profiles</primary></indexterm>
 Roaming profiles are feared by some, hated by a few, loved by many, and a godsend for
 some administrators.
 </para>
 
 <para>
+<indexterm><primary>manage roaming profiles</primary></indexterm>
 Roaming profiles allow an administrator to make available a consistent user desktop
 as the user moves from one machine to another. This chapter provides much information
 regarding how to configure and manage roaming profiles.
 </para>
 
 <para>
+<indexterm><primary>local profiles</primary></indexterm>
 While roaming profiles might sound like nirvana to some, they are a real and tangible
 problem to others. In particular, users of mobile computing tools, where often there may not
 be a sustained network connection, are often better served by purely local profiles.
@@ -47,6 +50,7 @@ Windows 9x/Me and Windows NT4/200x clients implement these features.
 </para>
 
 <para>
+<indexterm><primary>NetUserGetInfo</primary></indexterm>
 Windows 9x/Me clients send a NetUserGetInfo request to the server to get the user's
 profiles location. However, the response does not have room for a separate
 profiles location field, only the user's home share. This means that Windows 9x/Me
@@ -55,6 +59,8 @@ profiles are restricted to being stored in the user's home directory.
 
 
 <para>
+<indexterm><primary>NetSAMLogon</primary></indexterm>
+<indexterm><primary>RPC</primary></indexterm>
 Windows NT4/200x  clients send a NetSAMLogon RPC request, which contains many fields
 including a separate field for the location of the user's profiles.
 </para>
@@ -94,6 +100,8 @@ semantics of <quote>%L</quote> and <quote>%N</quote>, as well as <quote>%U</quot
 </para>
 
 <note><para>
+<indexterm><primary>logons</primary></indexterm>
+<indexterm><primary>disconnect a connection</primary></indexterm>
 MS Windows NT/200x clients at times do not disconnect a connection to a server between logons. It is recommended
 to not use the <smbconfsection name="homes"/> metaservice name as part of the profile share path.
 </para></note>
@@ -103,26 +111,29 @@ to not use the <smbconfsection name="homes"/> metaservice name as part of the pr
 <title>Windows 9x/Me User Profiles</title>
 
 <para>
+<indexterm><primary>net use /home</primary></indexterm>
+<indexterm><primary>logon home</primary></indexterm>
 To support Windows 9x/Me clients, you must use the <smbconfoption name="logon home"/>
 parameter. Samba has been fixed so <userinput>net use /home</userinput> now works as well and it, too, relies
-on the <command>logon home</command> parameter.
+on the <parameter>logon home</parameter> parameter.
 </para>
 
 <para>
-By using the logon home parameter, you are restricted to putting Windows 9x/Me profiles in the user's home
-directory.  But wait! There is a trick you can use. If you set the following in the
+<indexterm><primary>logon home</primary></indexterm>
+<indexterm><primary>\\%L\%U\.profiles</primary></indexterm>
+<indexterm><primary>.profiles</primary></indexterm>
+By using the <parameter>logon home</parameter> parameter, you are restricted to putting Windows 9x/Me profiles
+in the user's home directory.  But wait! There is a trick you can use. If you set the following in the
 <smbconfsection name="[global]"/> section of your &smb.conf; file:
-</para>
-<para><smbconfblock>
+<smbconfblock>
 <smbconfoption name="logon home">\\%L\%U\.profiles</smbconfoption>
-</smbconfblock></para>
-
-<para>
+</smbconfblock>
 then your Windows 9x/Me clients will dutifully put their clients in a subdirectory
 of your home directory called <filename>.profiles</filename> (making them hidden).
 </para>
 
 <para>
+<indexterm><primary>net use /home</primary></indexterm>
 Not only that, but <userinput>net use /home</userinput> will also work because of a feature in
 Windows 9x/Me. It removes any directory stuff off the end of the home directory area
 and only uses the server and share portion. That is, it looks like you
@@ -139,11 +150,12 @@ You can support profiles for Windows 9x and Windows NT clients by setting both t
 </para>
 
 <para><smbconfblock>
-<smbconfoption name="logon home">\\%L\%u\.profiles</smbconfoption>
-<smbconfoption name="logon path">\\%L\profiles\%u</smbconfoption>
+<smbconfoption name="logon home">\\%L\%U\.profiles</smbconfoption>
+<smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
 </smbconfblock></para>
 
 <para>
+<indexterm><primary>mixed profile</primary></indexterm>
 Windows 9x/Me and NT4 and later profiles should not be stored in the same location because
 Windows NT4 and later will experience problems with mixed profile environments.
 </para>
@@ -153,6 +165,7 @@ Windows NT4 and later will experience problems with mixed profile environments.
 <title>Disabling Roaming Profile Support</title>
 
 <para>
+<indexterm><primary>disable roaming profiles</primary></indexterm>
 The question often asked is, <quote>How may I enforce use of local profiles?</quote> or
 <quote>How do I disable roaming profiles?</quote>
 </para>
@@ -160,9 +173,10 @@ The question often asked is, <quote>How may I enforce use of local profiles?</qu
 <para>
 <indexterm><primary>roaming profiles</primary></indexterm>
 There are three ways of doing this:
-<indexterm><primary>windows registry settings</primary><secondary>roaming profiles</secondary></indexterm>
 </para>
 
+<indexterm><primary>windows registry settings</primary><secondary>roaming profiles</secondary></indexterm>
+
 <variablelist>
 	<varlistentry>
 		<term>In &smb.conf;</term>:
@@ -180,7 +194,9 @@ There are three ways of doing this:
 	<varlistentry>
 		<term>MS Windows Registry:</term>
 		<listitem><para>
-		Use the Microsoft Management Console (MMC) gpedit.msc to instruct your MS Windows XP
+<indexterm><primary>MMC</primary></indexterm>
+<indexterm><primary>local profile</primary></indexterm>
+		Use the Microsoft Management Console (MMC) <command>gpedit.msc</command> to instruct your MS Windows XP
 		machine to use only a local profile. This, of course, modifies registry settings. The full
 		path to the option is:
 <screen>
@@ -193,11 +209,12 @@ Local Computer Policy\
 Disable: Only Allow Local User Profiles 
 Disable: Prevent Roaming Profile Change from Propagating to the Server
 </screen>
-	</para> </listitem>
+	</para></listitem>
 	</varlistentry>
 
 	<varlistentry>
 		<term>Change of Profile Type:</term>
+<indexterm><primary>Profile Type</primary></indexterm>
 		<listitem><para>From the start menu right-click on the <guiicon>My Computer</guiicon> icon,
 		select <guimenuitem>Properties</guimenuitem>, click on the <guilabel>User Profiles</guilabel>
 		tab, select the profile you wish to change from
@@ -213,6 +230,7 @@ about which registry keys to change to enforce use of only local user profiles.
 </para>
 
 <note><para>
+<indexterm><primary>Windows Resource Kit</primary></indexterm>
 The specifics of how to convert a local profile to a roaming profile, or a roaming profile
 to a local one, vary according to the version of MS Windows you are running. Consult the Microsoft MS
 Windows Resource Kit for your version of Windows for specific information.
@@ -239,6 +257,8 @@ profile folders.
 </para>
 
 <para>
+<indexterm><primary>user.DAT</primary></indexterm>
+<indexterm><primary>user.MAN</primary></indexterm>
 The <filename>user.DAT</filename> file contains all the user's preferences. If you wish to enforce a set of preferences,
 rename their <filename>user.DAT</filename> file to <filename>user.MAN</filename>, and deny them write access to this file.
 </para>
@@ -261,6 +281,10 @@ rename their <filename>user.DAT</filename> file to <filename>user.MAN</filename>
 </orderedlist>
 
 <para>
+<indexterm><primary>Primary Logon</primary></indexterm>
+<indexterm><primary>Client for Novell Networks</primary></indexterm>
+<indexterm><primary>Novell</primary></indexterm>
+<indexterm><primary>Windows Logon</primary></indexterm>
 Under Windows 9x/Me, profiles are downloaded from the Primary Logon. If you have the Primary Logon
 as <quote>Client for Novell Networks</quote>, then the profiles and logon script will be downloaded from
 your Novell server. If you have the Primary Logon as <quote>Windows Logon</quote>, then the profiles will
@@ -268,6 +292,7 @@ be loaded from the local machine &smbmdash; a bit against the concept of roaming
 </para>
 
 <para>
+<indexterm><primary>domain logon server</primary></indexterm>
 You will now find that the Microsoft Networks Login box contains <constant>[user, password, domain]</constant> instead
 of just <constant>[user, password]</constant>. Type in the Samba server's domain name (or any other domain known to exist,
 but bear in mind that the user will be authenticated against this domain and profiles downloaded from it
@@ -288,6 +313,9 @@ the Samba server and verify that the <filename>Desktop</filename>, <filename>Sta
 </para>
 
 <para>
+<indexterm><primary>cached locally</primary></indexterm>
+<indexterm><primary>shortcuts</primary></indexterm>
+<indexterm><primary>profile directory</primary></indexterm>
 These folders will be cached locally on the client and updated when the user logs off (if
 you haven't made them read-only by then). You will find that if the user creates further folders or
 shortcuts, the client will merge the profile contents downloaded with the contents of the profile
@@ -295,6 +323,10 @@ directory already on the local client, taking the newest folders and shortcut fr
 </para>
 
 <para>
+<indexterm><primary>local profile</primary></indexterm>
+<indexterm><primary>remote profile</primary></indexterm>
+<indexterm><primary>ownership rights</primary></indexterm>
+<indexterm><primary>profile directory</primary></indexterm>
 If you have made the folders/files read-only on the Samba server, then you will get errors from
 the Windows 9x/Me machine on logon and logout as it attempts to merge the local and remote profile.
 Basically, if you have any errors reported by the Windows 9x/Me machine, check the UNIX file permissions
@@ -302,6 +334,10 @@ and ownership rights on the profile directory contents, on the Samba server.
 </para>
 
 <para>
+<indexterm><primary>windows registry settings</primary></indexterm>
+<indexterm><primary>profile path</primary></indexterm>
+<indexterm><primary>user profiles</primary></indexterm>
+<indexterm><primary>desktop cache</primary></indexterm>
 <indexterm><primary>windows registry settings</primary><secondary>profile path</secondary></indexterm>
 If you have problems creating user profiles, you can reset the user's local desktop cache, as shown below.
 When this user next logs in, the user will be told that he/she is logging in <quote>for the first
@@ -348,6 +384,7 @@ time</quote>.
 </orderedlist>
 
 <warning><para>
+<indexterm><primary>ProfilePath</primary></indexterm>
 Before deleting the contents of the directory listed in the <parameter>ProfilePath</parameter>
 (this is likely to be <filename>c:\windows\profiles\username)</filename>, ask whether the owner has
 any important files stored on his or her desktop or start menu. Delete the contents of the
@@ -361,11 +398,18 @@ in their profile directory, as well as the local <quote>desktop,</quote> <quote>
 </para></warning>
 
 <para>
+<indexterm><primary>log level</primary></indexterm>
+<indexterm><primary>packet sniffer</primary></indexterm>
+<indexterm><primary>ethereal</primary></indexterm>
+<indexterm><primary>netmon.exe</primary></indexterm>
 If all else fails, increase Samba's debug log levels to between 3 and 10, and/or run a packet
 sniffer program such as ethereal or <command>netmon.exe</command>, and look for error messages.
 </para>
 
-<para> If you have access to an Windows NT4/200x server, then first set up roaming profiles and/or
+<para>
+<indexterm><primary>roaming profiles</primary></indexterm>
+<indexterm><primary>packet trace</primary></indexterm>
+If you have access to an Windows NT4/200x server, then first set up roaming profiles and/or
 netlogons on the Windows NT4/200x server. Make a packet trace, or examine the example packet traces
 provided with Windows NT4/200x server, and see what the differences are with the equivalent Samba trace.
 </para>
@@ -387,6 +431,8 @@ the new <smbconfoption name="logon home"/> parameter.
 </para>
 
 <para>
+<indexterm><primary>.PDS extension</primary></indexterm>
+<indexterm><primary>profile path</primary></indexterm>
 The entry for the NT4 profile is a directory, not a file. The NT help on profiles mentions that a
 directory is also created with a .PDS extension. The user, while logging in, must have write permission
 to create the full profile path (and the folder with the .PDS extension for those situations where it
@@ -394,6 +440,7 @@ might be created).
 </para>
 
 <para>
+<indexterm><primary>NTuser.DAT</primary></indexterm>
 In the profile directory, Windows NT4 creates more folders than Windows 9x/Me. It creates
 <filename>Application Data</filename> and others, as well as <filename>Desktop</filename>,
 <filename>Nethood</filename>, <filename>Start Menu,</filename> and <filename>Programs</filename>.
@@ -402,6 +449,8 @@ in the .PDS directory, and its purpose is currently unknown.
 </para>
 
 <para>
+<indexterm><primary>NTuser.DAT</primary></indexterm>
+<indexterm><primary>NTuser.MAN</primary></indexterm>
 You can use the <application>System Control Panel</application> to copy a local profile onto
 a Samba server (see NT help on profiles; it is also capable of firing up the correct location in the
 <application>System Control Panel</application> for you). The NT help file also mentions that renaming
@@ -531,6 +580,8 @@ The UPHClean software package can be downloaded from <ulink url="http://www.micr
 <title>Sharing Profiles between Windows 9x/Me and NT4/200x/XP Workstations</title>
 
 <para>
+<indexterm><primary>profile sharing</primary></indexterm>
+<indexterm><primary>profile contents</primary></indexterm>
 Sharing of desktop profiles between Windows versions is not recommended. Desktop profiles are an
 evolving phenomenon, and profiles for later versions of MS Windows clients add features that may interfere
 with earlier versions of MS Windows clients. Probably the more salient reason to not mix profiles is
@@ -546,6 +597,8 @@ location for the profiles. The &smb.conf; parameters that need to be common are
 </para>
 
 <para>
+<indexterm><primary>user.DAT</primary></indexterm>
+<indexterm><primary>NTuser.DAT</primary></indexterm>
 If you have this set up correctly, you will find separate <filename>user.DAT</filename> and
 <filename>NTuser.DAT</filename> files in the same profile directory.
 </para>
@@ -556,6 +609,7 @@ If you have this set up correctly, you will find separate <filename>user.DAT</fi
 <title>Profile Migration from Windows NT4/200x Server to Samba</title>
 
 <para>
+<indexterm><primary>encrypted passwords</primary></indexterm>
 There is nothing to stop you from specifying any path that you like for the location of users' profiles.
 Therefore, you could specify that the profile be stored on a Samba server or any other SMB server,
 as long as that SMB server supports encrypted passwords.
@@ -565,6 +619,7 @@ as long as that SMB server supports encrypted passwords.
 <title>Windows NT4 Profile Management Tools</title>
 
 <para>
+<indexterm><primary>resource kit</primary></indexterm>
 Unfortunately, the resource kit information is specific to the version of MS Windows NT4/200x. The
 correct resource kit is required for each platform.
 </para>
@@ -609,6 +664,7 @@ Follow these steps for every profile you need to migrate.
 
 <para>
 <indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>info</tertiary></indexterm>
 You should obtain the SID of your NT4 domain. You can use the <command>net rpc info</command> to do this.
 See <link linkend="NetCommand">The Net Command Chapter</link>, <link linkend="netmisc1">Other Miscellaneous Operations</link> for more information.
 </para>
@@ -619,8 +675,10 @@ See <link linkend="NetCommand">The Net Command Chapter</link>, <link linkend="ne
 <title>moveuser.exe</title>
 
 <para>
-The Windows 200x professional resource kit has <command>moveuser.exe</command>. <command>moveuser.exe</command> changes the security of a profile
-from one user to another. This allows the account domain to change and/or the username to change.
+<indexterm><primary>moveuser.exe</primary></indexterm>
+The Windows 200x professional resource kit has <command>moveuser.exe</command>.
+<command>moveuser.exe</command> changes the security of a profile from one user to another. This allows the
+account domain to change and/or the username to change.
 </para>
 
 <para>
@@ -634,6 +692,7 @@ This command is like the Samba <command>profiles</command> tool.
 
 <para>
 <indexterm><primary>SID</primary></indexterm>
+<indexterm><primary>GetSID.exe</primary></indexterm>
 You can identify the SID by using <command>GetSID.exe</command> from the Windows NT Server 4.0 Resource Kit.
 </para>
 
@@ -665,17 +724,20 @@ then this must be done through policy settings. See <link linkend="PolicyMgmt">S
 Policies</link>.
 </para>
 
-<note><para>
- Under NO circumstances should the profile directory (or its
-contents) be made read-only because this may render the profile unusable.
-Where it is essential to make a profile read-only within the UNIX file
-system, this can be done, but then you absolutely must use the
-<command>fake-permissions</command> VFS module to instruct MS Windows
-NT/200x/XP clients that the Profile has write permission for the user.
-See <link linkend="fakeperms">fake_perms VFS module</link>.
+<note><para> 
+<indexterm><primary>fake-permissions module</primary></indexterm>
+<indexterm><primary>VFS module</primary></indexterm>
+<indexterm><primary>fake_perms</primary></indexterm>
+Under NO circumstances should the profile directory (or its contents) be made read-only because this may
+render the profile unusable.  Where it is essential to make a profile read-only within the UNIX file system,
+this can be done, but then you absolutely must use the <command>fake-permissions</command> VFS module to
+instruct MS Windows NT/200x/XP clients that the Profile has write permission for the user.  See <link
+linkend="fakeperms">fake_perms VFS module</link>.
 </para></note>
 
 <para>
+<indexterm><primary>NTUser.MAN</primary></indexterm>
+<indexterm><primary>NTUser.DAT</primary></indexterm>
 For MS Windows NT4/200x/XP, the procedure shown in <link linkend="profilemigrn">Profile Migration from Windows
 NT4/200x Server to Samba</link> can also be used to create mandatory profiles. To convert a group profile into
 a mandatory profile, simply locate the <filename>NTUser.DAT</filename> file in the copied profile and rename
@@ -683,6 +745,7 @@ it to <filename>NTUser.MAN</filename>.
 </para>
 
 <para>
+<indexterm><primary>User.MAN</primary></indexterm>
 For MS Windows 9x/Me, it is the <filename>User.DAT</filename> file that must be renamed to
 <filename>User.MAN</filename> to effect a mandatory profile.
 </para>
@@ -694,6 +757,9 @@ For MS Windows 9x/Me, it is the <filename>User.DAT</filename> file that must be
 
 <para>
 <indexterm><primary>group profiles</primary></indexterm>
+<indexterm><primary>template</primary></indexterm>
+<indexterm><primary>profile migration tool</primary></indexterm>
+<indexterm><primary>profile access rights</primary></indexterm>
 Most organizations are arranged into departments. There is a nice benefit in this fact, since usually
 most users in a department require the same desktop applications and the same desktop layout. MS
 Windows NT4/200x/XP will allow the use of group profiles. A group profile is a profile that is created
@@ -702,6 +768,7 @@ assigned access rights for the user group that needs to be given access to the g
 </para>
 
 <para>
+<indexterm><primary>User Manager</primary></indexterm>
 The next step is rather important. Instead of assigning a group profile to users (Using User Manager)
 on a <quote>per-user</quote> basis, the group itself is assigned the now modified profile.
 </para>
@@ -718,6 +785,7 @@ profile, then the result will be a fusion (merge) of the two.
 
 <para>
 <indexterm><primary>default profile</primary></indexterm>
+<indexterm><primary>registry keys</primary></indexterm>
 MS Windows 9x/Me and NT4/200x/XP will use a default profile for any user for whom a profile
 does not already exist. Armed with a knowledge of where the default profile is located on the Windows
 workstation, and knowing which registry keys affect the path from which the default profile is created,
@@ -729,6 +797,8 @@ significant administrative advantages.
 <title>MS Windows 9x/Me</title>
 
 <para>
+<indexterm><primary>System Policy Editor</primary></indexterm>
+<indexterm><primary>registry</primary></indexterm>
 To enable default per-use profiles in Windows 9x/Me, you can either use the <application>Windows
 98 System Policy Editor</application> or change the registry directly.
 </para>
@@ -742,6 +812,7 @@ changes.
 </para>
 
 <para>
+<indexterm><primary>regedit.exe</primary></indexterm>
 To modify the registry directly, launch the <application>Registry Editor</application>
 (<command>regedit.exe</command>) and select the hive <filename>HKEY_LOCAL_MACHINE\Network\Logon</filename>.
 Now add a DWORD type key with the name <quote>User Profiles.</quote> To enable user profiles to set the value
@@ -822,7 +893,13 @@ the following steps are followed for profile handling:
 	exist, then a new profile is created in the <filename>%SystemRoot%\Profiles\%USERNAME%</filename>
 	directory from reading the <filename>Default User</filename> profile. </para> </step>
 
-	<step> <para> If the NETLOGON share on the authenticating server (logon server) contains
+	<step> <para>
+<indexterm><primary>NTConfig.POL</primary></indexterm>
+<indexterm><primary>NETLOGON</primary></indexterm>
+<indexterm><primary>authenticating server</primary></indexterm>
+<indexterm><primary>logon server</primary></indexterm>
+<indexterm><primary>HKEY_CURRENT_USER</primary></indexterm>
+	If the NETLOGON share on the authenticating server (logon server) contains
 	a policy file (<filename>NTConfig.POL</filename>), then its contents are applied to the
 	<filename>NTUser.DAT</filename>, which is applied to the <filename>HKEY_CURRENT_USER</filename>
 	part of the registry. 
@@ -850,6 +927,7 @@ on logout.
 </para>
 
 <para>
+<indexterm><primary>regedt32</primary></indexterm>
 Under MS Windows NT4, default locations for common resources like <filename>My Documents</filename>
 may be redirected to a network share by modifying the following registry keys. These changes may be
 made via use of the System Policy Editor. To do so may require that you create your own template
@@ -932,6 +1010,9 @@ The default entries are shown in <link linkend="regkeys">Defaults of Profile Set
 
 <note><para>
 <indexterm><primary>GPOs</primary></indexterm>
+<indexterm><primary>Windows XP Home Edition</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>domain security</primary></indexterm>
 MS Windows XP Home Edition does use default per-user profiles, but cannot participate
 in domain security, cannot log onto an NT/ADS-style domain, and thus can obtain the profile only
 from itself. While there are benefits in doing this, the beauty of those MS Windows clients that
@@ -940,6 +1021,7 @@ profile and enforce it through the use of Group Policy Objects (GPOs).
 </para></note>
 
 <para>
+<indexterm><primary>Default User</primary></indexterm>
 When a new user first logs onto an MS Windows 200x/XP machine, the default profile is obtained from
 <filename>C:\Documents and Settings\Default User</filename>. The administrator can modify or change the
 contents of this location, and MS Windows 200x/XP will gladly use it. This is far from the optimum arrangement,
@@ -947,9 +1029,10 @@ since it will involve copying a new default profile to every MS Windows 200x/XP
 </para>
 
 <para>
+<indexterm><primary>NETLOGON</primary></indexterm>
 When MS Windows 200x/XP participates in a domain security context, and if the default user profile is not
 found, then the client will search for a default profile in the NETLOGON share of the authenticating server.
-In MS Windows parlance, it is <?latex \linebreak ?><filename>%LOGONSERVER%\NETLOGON\Default User,</filename>
+In MS Windows parlance, it is <filename>%LOGONSERVER%\NETLOGON\Default User,</filename>
 and if one exists there, it will copy this to the workstation in the <filename>C:\Documents and
 Settings\</filename> under the Windows login name of the use.
 </para>