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

There are 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, a special service was created. The application UPHClean (User Profile Hive Cleanup) can be installed as a service on Windows NT4/2000/XP Professional and Windows 2003.

The UPHClean software package can be downloaded from the User Profile Hive Cleanup Service^[7] web site.

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 and Desktop with Windows 9x/Me, you must 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 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 on to an MS Windows NT4 machine that is a member of a Microsoft security domain, the following steps are followed for profile handling:

MS Windows NT4 profiles may be local or roaming. A local profile is 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:

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 made 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 first creating a default user profile, then while logged in as that user, running 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 Defaults of Profile Settings Registry Keys.

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

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 user's desktop profile is 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 is 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 affects 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\

This 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 stores 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 are 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 is 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 is 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 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/200x).

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. 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 gigabytes 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 this discussion is to show that roaming profiles and good controls of how they can be changed as well as good discipline make 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 preset 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:

Roaming profiles and domain policies are implemented via USERENV.DLL. Microsoft Knowledge Base articles 221833 and 154120 describe how to instruct that DLL to debug the login process.