Both Unix and Windows allow users to configure their computer to their individual taste. A users configuration may apply to one particular computer or to any networked computer on which they log in.

The Unix/Linux world provides a “home directory” for each user. This stores all of the users program settings, documents and other files. It is easy to offer network-wide home directories for all of your users using NFS (Network File System). When properly implemented, this system is transparent to the user and provides a nice way to centralize data storage and allow any user to log into any workstation using their own preferences and settings and have all of their data readily available.

Microsoft Windows supports “user profiles” for all users settings. These store all the Registry settings, program settings, documents and other files for each user. Unfortunately, sometimes it is not trivial to offer network-wide user profiles for all of your users.

This HowTo will focus on the world of Microsoft's user profiles. It will cover how profiles work, the different options you have in implementing profiles, how to configure Samba for network-wide (“roaming”) profiles or “local profiles”, and various tips and tricks to get the most out of user profiles.

With the release of Windows NT, Microsoft made a conscious effort to create a multi-user system with separate settings for each user. To make this, user profiles were implemented. User profiles are simply a set of folders and files for each individual user. These folders are located in different places depending upon the version of Windows you are running:

If you browse these folders you will find a few directories contained within: A folder for each individual user that has logged onto the workstation - an “All Users” folder and a “Default User” folder.

The users folders contain the users registry hive (“NTUSER.DAT”), as well as various other folders, such as “Desktop”, “Documents”, “Favorites”, “AppData”, etc. Depending upon what applications are installed and how many documents a user has, the user profile can range from a few megabytes in size to well over gigabytes in size (especially when not setting up folder redirection and storing documents, movies, etc. in your profile, too).

The “All Users” folder contains settings that are in effect for every user that uses the workstation. Mainly this folder is used to place application shortcuts within the start menu and desktop so locally installed applications are available to all users of the workstation. The “All Users” folder does not contain any registry settings.

The “Default User” folder contains settings that are used when a user does not already have a profile folder on the machine, and no default user profiles was found on the “NetLogon” share. In this case, this folder is copied to a new directory named using the username of the user logging in (or a variant of the username). You can control the default appearance and settings of a new user by changing the contents of this directory, more on this later.

When Microsoft designed profiles, they provided options for the administrator to use depending upon the network setup and needs. These options are implemented with either “Local Profiles”, “Server-Side (Roaming) Profiles” and “Mandatory Profiles”.

Local profiles are simply profiles that are stored on the local machine, these, of course, are the default profiles used when not on a network. The downfall of this type of profile is that there is no way to have the users settings “follow” them from one workstation to another, also there is no feasible way to ensure all of the users settings on your network is backed up properly – this is especially important if your users store all of their documents within their profile directories (the default functionality).

Roaming profiles are profiles that are stored on a server and are “downloaded” to the workstation whenever a user logs into the machine. The profiles are then “uploaded” back to the central server, when the user logs out.

In theory these types of profiles would be perfect in an environment where users jump from machine to machine, except for the fact that they are downloaded (copied) every time a user logs into a machine. Whenever you have multiple copies of a file, you run the risk of losing data during the re-syncing of the data over a network. An offset hardware clock, corrupt sectors on a disk or faulty network wiring could cause data corruption.

Another drawback of roaming profiles is the fact that, by default, the users documents and other application data are stored in the profile folder so the profile can grow to be huge. A profile of several hundred megabytes is common. Imagine if 50 users are logging into workstations at the same time, your network would quickly slow to a crawl. To make matters worse, when these users log out, this same data (slightly modified) is then copied back to the server. But to counteract, there you can setup folder redirections.

Mandatory profiles are pretty much the exact same thing as roaming (server-side) profiles, except for the fact that the profile is deleted instead of copied back to the server when a user logs out. This has the benefit of keeping the profile small (since no changes are propagated back to the server), and the fact that you only really need to maintain one profile for your entire network is also nice.

The drawback, of course, is that the profile is never updated – no user settings are retained, if you install certain applications your users would continuously be bugged with different registration wizards (until you update the mandatory profile of course), etc. Using mandatory profiles, although in theory would be wonderful (especially in a controlled environment), are not very feasible to implement on a production network.

Folder redirection allows you to redirect a folder that is usually located within the user profile to an external source, such as a network share. The frustration occurs because not all folders can or should be redirected and if the network share that you are redirecting to becomes unavailable you have issues as well, such as disappearing icons on the desktop, etc.

To be able to redirect any folder, you need to know what folders are actually in the profile, and what folders really work well with redirection and which folders will give you headaches if you try to redirect them.

When redirecting folders you should look at two different things; how much data is stored within the directory and how important the data is. If the folder contains a lot of data, it would be optimal to redirect that folder outside the profile so the data is not continuously copied from/to the server when the user logs in/out. Also, if the data is important, such as documents, then it is very important to redirect that data out of the volatile profile – otherwise updated documents could be lost when the network is either congested or times out.

With that in mind, there are a few directories that should usually be re-directed, these include Application Data, Desktop and My Documents. In reality, the My Documents folder should be redirected even when using Local Profiles. Some Administrators also redirect the Favorites folder (mostly for backups and if using different profiles for each architecture which is covered later).

Some folders are not prone to work well when redirected (you will eventually encounter errors). These folders include nearly any folder used with Internet Explorer (except Favorites) as well as NetHood and PrintHood.

The Local Settings folder is a special case. This folder contains files specific to the local machine and should not be propagated to the profile. For this to happen you must either set a registry key on each workstation or utilize a system policy on your network.

The easiest type of profile to implement with Samba is the local profile. Local profiles are stored on each individual computer and are not centrally located on a server.

Even though local profiles are stored on the users computer, it is still a good idea to redirect certain folders within their profile to a Samba share, such as the “My Documents” folder. See Configuring folder redirections.

By default Local profiles are used, so the following is only neccessary if you had changed before.

• Open Active Directory Users and Computers (ADUC).
• Right-click to an user account and choose “Properties”.
• Go to the “Profile” tab. The field for the users profile have to be empty for using a local profile for that account (this is default).

The following sections describe only how to setup the profile, that is stored on a Samba 3.x or 4.x share. This is independend from the version of Samba you run on your DC!

Profiles share on a Samba 4.x server

• Create a folder for the roaming profiles

 # mkdir -p /srv/samba/Profiles/

• Add a new share to your smb.conf:

 [Profiles]
     path = /srv/samba/Profiles/
     read only = no

• Reload Samba:

 # smbcontrol all reload-config

• Log on to a Windows machine as Domain Administrator.
• Go to “\\Servername”. You'll see the new added share.

• Right-click to the share name, choose “Properties” and go to the “Security” tab.
• Click the “Advanced” and then the “Change permissions” button for a more granular way to edit the share permissions.

• Set the permissions as shown in the following table.

-table- Name Permissions Apply to Administrator Full control This folder, subfolders and files Domain Users Traverse folder/execute file, List folder/read data, Create folder/append data This folder only CREATOR OWNER Full control Subfolders and files only -table-

Adjust the group “Domain Users”, if you have a different group, you would allow to store their profiles on this share. Of course, you could add multiple groups with the same recommented group permission for “Domain Users”.

• Save the new permissions by closing the windows with “OK”.

Profiles share on a Samba 3.x server

• Create a folder for the roaming profiles and set permissions:

 # mkdir -p /srv/samba/Profiles/
 # chmod 1770 /srv/samba/profiles
 # chgrp "Domain Users" /srv/samba/profiles

• Add a new share to your smb.conf:

 [Profiles]
   path = /srv/samba/Profiles/
   read only = no
   store dos attributes = Yes
   create mask = 0600
   directory mask = 0700
   profile acls = yes
   csc policy = disable

• Reload Samba:

 # smbcontrol all reload-config

• Open Active Directory Users and Computers (ADUC).
• Right-click to an user account and choose “Properties”.
• Go to the “Profile” tab, and fill the path to the users profile.

If you use the %USERNAME% variable, you can set the profile path to multiple accounts at once, too.

Windows Vista up to Windows 8.0 create .V2 folders for their profiles. Windows 8.1 starts using .V4 folders. This is appended automatically if a profile from those systems is uploaded to the server.

In Windows 7, the registry contains information on each users roaming profile and should your Samba infrastructure change, such as the network location of users profiles, this can lead to Windows being unable to find the profile. The list of user profiles are located at:

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList

Deleting an entry will force Windows to look up the users profile from the domain controller and restore the profile.

To keep the following guide simple, we setup the policy in the “Default Domain Policy”. If you have different requirements, adapt it to your needs.

• Open the Group Policy Management console.
• Go to “Forest: your.domain” / “Domains” / “your.domain”
• Right-click “Default Domain Policy” and choose “Edit” to open the Group Policy Management Editor.

• Navigate to “User Configuration” / “Policies” / “Windows Settings” / “Folder Redirection”, right-click to “Documents” and choose “Properties”.
• Redirect the folder to your needs and adjust the values on the “Settings” tab, too.

• In the “Folder redirection” sub-tree you can redirect other folders, too.
• Save the changes by closing the Group Policy Management Editor.