Microsoft Windows User Profiles
Both Unix and Windows allow users to configure their computer to their individual taste. A user’s 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 user’s 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.
To help maintain your sanity (and keep your job), these wikis will focus on the wonderful world of Microsoft’s user profiles. They 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.
Windows Profile Basics
With the release of Windows NT, Microsoft made a conscious effort to create a multi-user system with separate settings for each user. To do 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 NT you are running. In Windows NT 4, these profiles are stored by default in C:\WinNT\Profiles\ – in Windows 2000 and XP, they were moved to C:\Documents and Settings\. 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 user’s folders contain the users Registry Hive (NTUSER.DAT), as well as various other folders, such as Desktop, Personal (My Documents), Start Menu, Favorites, Application Data, etc. Depending upon what applications are installed and how many documents a user has, the user profile can range from a few a few megabytes in size to well over a gigabyte in size (especially when running Microsoft Outlook without an Exchange Server).
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 since Windows is only capable of loading one User Registry Hive at a time.
The « Default User » folder contains settings the settings that are used when a user does not already have a profile folder on the machine. 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
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 user’s settings « follow » them from one workstation to another, also there is no feasible way to ensure all of the user’s settings on your network is backed up properly – this is especially important if your user’s store all of their documents within their profile directories (the default functionality).
Roaming Profiles
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 user’s 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.
Mandatory Profiles
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
When you bring up the topic of folder redirection with any Windows Administrator you will get a reaction indicating extreme frustration or one that is peaceful, nearly Zen like. The frustration reaction is a result of either not implementing redirection properly, or implementing them on a faulty or overloaded network. This section will hopefully allow you to have the Zen-like reaction when this issue comes up.
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.
Fortunately, this wiki is about Samba Servers, which are known to be available for months, if not years at a time. However, a word of caution, before you implement any type of services on your network, it is best to ensure all of the hardware is thoroughly tested, especially check or certify all network cables, including patch cables.
Folders within a Profile
To be able to redirect any folder, you really 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. The following table should give you a good idea of what folders are in the profile (by default) and what these folders contain.
Default Folders within a User’s Profile Folder Name Description
Application Data Apps should store extra data here (similar to « dot files » in Linux, a.k.a. « hidden files » in Windows)
Cookies Microsoft Internet Explorer stores user’s cookies here
Desktop User’s Desktop Folder (icons, etc.)
Favorites Microsoft’s IE stores user’s favorites here (url shortcuts)
Local Settings Extra Data for local computer should be stored here (Temp, etc)
My Documents (2k & XP) User’s Document folder on Windows 2000 & XP
NetHood Any Extra Network Neighborhood Shortcuts are stored here
Personal (NT4) User’s Document folder on Windows NT
PrintHood Any Network Printers the user adds are stored here
Recent List of Recently opened files (files that are opened within Explorer)
SendTo Any locations to add to the send-to list are stored here
Start Menu The user’s Start Menu is stored here
Templates Links to create new files with the New -> submenu
Ntuser.dat (file) Actual File that holds the User Hive of the Windows Registry
NOTE: Some Windows Programs do not store all of it’s data in the proper place, as a result profiles may contain more folders than what is listed here.
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 stores quite a bit 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 or Personal when using NT4. (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. I am not sure why these folders do not work well with redirection, but you will eventually get different errors, it may take a week or two but you will get various errors.
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.
Finally, there are folders that are stored within other folders that can also be redirected. A good example of this is the introduction of the « My Music » folder that is usually stored within the « My Documents » folder. These folders include « My Music », « My Pictures » and « My Videos », all of these folders work well with redirection.
How to Redirect Folders
Now that you know what folders you can redirect, how exactly do you redirect these folders ? Well, it is extremely easy as there is a registry setting for every folder within the profile. These registry keys are located in « Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders » in the User Hive of the Windows Registry.
To redirect these folders, you must either set a local policy on each of the workstations connected to the domain, or utilize a Network-wide System Policy which is covered in another wiki. Also, if you redirect folders on a Windows XP based machine you must also ensure that the « offline files » feature is either disabled or that Windows is set to not sync redirected folders (this can also be set within a System Policy).
Implementing Local Profiles with Samba
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. To utilize Local Profiles simply set the following directives to nothing:
* logon path =
* logon home =
NOTE: When using Local Profiles, Samba’s « logon drive » directive has no meaning. If you still want the user’s home directory on a Samba server set to a drive letter, you must set it with a Logon Script.
Even though local profiles are stored on the User’s computer, it is still a good idea to redirect certain folders within their profile to a Samba Share, such as the « Documents » folder. To do this see the wiki article on implementing Windows Policies.
Implementing Roaming Profiles with Samba
To implement Roaming Profiles with Samba a few things must happen. First you must create a share to store these profiles, then you must set a few Samba directives to enable roaming profiles.
NOTE: You can theoretically store profiles within the users home directory, unfortunately Windows does not release a share immediately after logging out. So if you do store user’s profiles within the home directories and another user logs into a machine immediately after another user logs out, the newly logged in user could invariably use the other users profile resulting in a possible security issue, as well as other issues. It is best to simply store all of the user profiles within a separate Samba share.
Creating the Profile Share
To create a Samba share to use for your user’s profiles simply add something similar to your share section of the smb.conf file:
* [profiles]
* comment = Network Profiles Share
* path = /srv/samba/profiles
* read only = No
* store dos attributes = Yes
* create mask = 0600
* directory mask = 0700
* browseable = no
* guest ok = no
* printable = no
* hide files = /desktop.ini/outlook*.lnk/*Briefcase*/
Then ensure that everyone has write access to the directory listed as the path:
* chmod o+rw /srv/samba/profiles
Setting relevant directives for Roaming Profiles
The smb.conf settings required to use Roaming Profiles by default are:
* logon path = \\%L\profiles\%U
* logon home = \\%L\%U\.9xprofile
* logon drive = P:
The logon home directive is only used if you have any Windows 9x based machines on your Domain, otherwise it does not need to be set. The logon drive specifies the Drive Letter Windows will assign your home directory, this alleviates the need to create a logon script that essentially would do the same thing.
The logon path directive is where you actually setup roaming profiles. This directive should contain a Windows Network path to the location of the profile for each user. If the user’s profile directory does not exist, one will be created at that location (as long as the user has write access to that directory).
You can also take full advantage of Samba’s Variable Substitutions and further separate User’s profiles, such as by architecture. Using the directive:
* logon path = \\%L\profiles\%U\%a
will separate the user’s profiles relating to each version of Windows, such as WinXP, WinNT, etc. This is extremely helpful if you have users that jump from computer to computer that have different versions of Windows on them. This can solve a whole slew of problems relating to the registry on different versions of Windows, especially when running different version of Internet Explorer. Separating profiles in this way can be a very powerful feature, especially when you include Folder Redirection into the mix.
