This section documents how to configure Samba for MS Windows client profile support.

There certain situations that cause a cached local copy of roaming profile not to be deleted on exit, even if the policy to force such deletion is set. To deal with that situation special service was created. The application UPHClean (User Profile Hive Cleanup) can be installed as service on Windows NT4/2000/XP Professional, and Windows 2003.

The UPHClean software package can be downloaded from User Profile Hive Cleanup Service.

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 that when logging off an earlier version of MS Windows, the older format of profile contents may overwrite information that belongs to the newer version resulting in loss of profile information content when that user logs on again with the newer version of MS Windows.

If you then want to share the same Start Menu/Desktop with W9x/Me, you will need to specify a common location for the profiles. The smb.conf parameters that need to be common are logon path and logon home.

If you have this set up correctly, you will find separate user.DAT and NTuser.DAT files in the same profile directory.

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.

To enable default per use profiles in Windows 9x/ME, you can either use the Windows 98 System Policy Editor or change the registry directly.

To enable default per user profiles in Windows 9x/ME, launch the System Policy Editor, then select File -> Open Registry, next click on the Local Computer icon, click on Windows 98 System, select User Profiles, and click on the enable box. Remember to save the registry changes.

To modify the registry directly, launch the Registry Editor (regedit.exe) and select the hive HKEY_LOCAL_MACHINE\Network\Logon. Now add a DWORD type key with the name “User Profiles,” to enable user profiles to set the value to 1; to disable user profiles set it to 0.

On MS Windows NT4, the default user profile is obtained from the location %SystemRoot%\Profiles which in a default installation will translate to C:\Windows NT\Profiles. Under this directory on a clean install there will be three (3) directories: Administrator, All Users, and Default User.

The All Users directory contains menu settings that are common across all system users. The Default User directory contains menu entries that are customizable per user depending on the profile settings chosen/created.

When a new user first logs onto an MS Windows NT4 machine, a new profile is created from:

When a user logs onto an MS Windows NT4 machine that is a member of a Microsoft security domain, the following steps are followed in respect of profile handling:

MS Windows NT4 profiles may be local or roaming. A local profile will stored in the %SystemRoot%\Profiles\%USERNAME% location. A roaming profile will also remain stored in the same way, unless the following registry key is created as shown:

 HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\
winlogon\"DeleteRoamingCache"=dword:0000000
 

In this case, the local copy (in %SystemRoot%\Profiles\%USERNAME%) will be deleted on logout.

Under MS Windows NT4, default locations for common resources like My Documents may be redirected to a network share by modifying the following registry keys. These changes may be affected via use of the System Policy Editor. To do so may require that you create your own template extension for the policy editor to allow this to be done through the GUI. Another way to do this is by way of first creating a default user profile, then while logged in as that user, run regedt32 to edit the key settings.

The Registry Hive key that affects the behavior of folders that are part of the default user profile are controlled by entries on Windows NT4 is:

HKEY_CURRENT_USER
	\Software
		\Microsoft
			\Windows
				\CurrentVersion
					\Explorer
						\User Shell Folders

The above hive key contains a list of automatically managed folders. The default entries are shown in the next table.

The registry key that contains the location of the default profile settings is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ User Shell Folders

The default entries are shown in the next table.

When a new user first logs onto an MS Windows 200x/XP machine, the default profile is obtained from C:\Documents and Settings\Default User. 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 since it will involve copying a new default profile to every MS Windows 200x/XP client workstation.

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,%LOGONSERVER%\NETLOGON\Default User, and if one exists there it will copy this to the workstation to the C:\Documents and Settings\ under the Windows login name of the user.

If a default profile does not exist in this location, then MS Windows 200x/XP will use the local default profile.

On logging out, the users' desktop profile will be stored to the location specified in the registry settings that pertain to the user. If no specific policies have been created or passed to the client during the login process (as Samba does automatically), then the user's profile will be written to the local machine only under the path C:\Documents and Settings\%USERNAME%.

Those wishing to modify the default behavior can do so through these three methods:

The registry hive key that effects the behavior of folders that are part of the default user profile are controlled by entries on Windows 200x/XP is:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\

The above hive key contains a list of automatically managed folders. The default entries are shown in the next table

There is also an entry called “Default” that has no value set. The default entry is of type REG_SZ, all the others are of type REG_EXPAND_SZ.

It makes a huge difference to the speed of handling roaming user profiles if all the folders are stored on a dedicated location on a network server. This means that it will not be necessary to write the Outlook PST file over the network for every login and logout.

To set this to a network location, you could use the following examples:

%LOGONSERVER%\%USERNAME%\Default Folders

This would store the folders in the user's home directory under a directory called Default Folders. You could also use:

\\SambaServer\FolderShare\%USERNAME%

in which case the default folders will be stored in the server named SambaServer in the share called FolderShare under a directory that has the name of the MS Windows user as seen by the Linux/UNIX file system.

Please note that once you have created a default profile share, you MUST migrate a user's profile (default or custom) to it.

MS Windows 200x/XP profiles may be Local or Roaming. A roaming profile will be cached locally unless the following registry key is created:

 HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\
	winlogon\"DeleteRoamingCache"=dword:00000001

In this case, the local cache copy will be deleted on logout.

With Samba-2.2.x, the choice you have is to enable or disable roaming profiles support. It is a global only setting. The default is to have roaming profiles and the default path will locate them in the user's home directory.

If disabled globally, then no one will have roaming profile ability. If enabled and you want it to apply only to certain machines, then on those machines on which roaming profile support is not wanted it is then necessary to disable roaming profile handling in the registry of each such machine.

With Samba-3, you can have a global profile setting in smb.conf and you can override this by per-user settings using the Domain User Manager (as with MS Windows NT4/ Win 200xx).

In any case, you can configure only one profile per user. That profile can be either:

A user requested the following: “ I do not want Roaming profiles to be implemented. I want to give users a local profile alone. Please help me, I am totally lost with this error. For the past two days I tried everything, I googled around but found no useful pointers. Please help me. ”

The choices are:

The roaming profile choices are:

A Windows NT4/200x/XP profile can vary in size from 130KB to very large. Outlook PST files are most often part of the profile and can be many GB in size. On average (in a well controlled environment), roaming profile size of 2MB is a good rule of thumb to use for planning purposes. In an undisciplined environment, I have seen up to 2GB profiles. Users tend to complain when it takes an hour to log onto a workstation but they harvest the fruits of folly (and ignorance).

The point of all the above is to show that roaming profiles and good controls of how they can be changed as well as good discipline make up for a problem-free site.

Microsoft's answer to the PST problem is to store all email in an MS Exchange Server backend. This removes the need for a PST file.

Local profiles mean:

On the other hand, use of roaming profiles means:

“When the client logs onto the Domain Controller, it searches for a profile to download. Where do I put this default profile?”

First, the Samba server needs to be configured as a Domain Controller. This can be done by setting in smb.conf:

There must be a [netlogon] share that is world readable. It is a good idea to add a logon script to pre-set printer and drive connections. There is also a facility for automatically synchronizing the workstation time clock with that of the logon server (another good thing to do).

Windows clients need to be members of the domain. Workgroup machines do not use network logons so they do not interoperate with domain profiles.

For roaming profiles, add to smb.conf: