Roaming Windows User Profiles: Difference between revisions

From SambaWiki
mNo edit summary
(Mostly a re-write of the HowTo to lift the content up to AD (was NT4 domain style only). Plus Samba3/4 configuration, added much more details, screenshots, etc.)
Line 1: Line 1:
= Introduction =
== 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.


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 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.


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.


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.


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.
==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''.


= Windows profile basics =
===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).


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 you are running:
=== 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.


{| border="1"
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.
!OS
!Stored in folder
|-
|NT4
|C:\WinNT\Profiles\
|-
|2000, XP
|C:\Documents and Settings\
|-
|Vista, 7, 8
|C:\Users\
|}


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.
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.


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 [[#Configuring_folder_redirection|folder redirection]] and storing documents, movies, etc. in your profile, too).
===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 "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 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.


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.
===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.


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“.
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.


== Local profiles ==
{| border="1"

|+ Default Folders within a User's Profile
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).
! Folder Name !! Description

|-

! Application Data

| Apps should store extra data here (similar to "dot files" in Linux, a.k.a. "hidden files" in Windows)
== Roaming profiles ==
|-

! Cookies
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.
| Microsoft Internet Explorer stores user's cookies here

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 [[#Configuring_folder_redirection|folder redirections]].



== 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 ==

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.




= 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.

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_redirection]].



== In an AD environment ==

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

* Open 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).

:[[Image:ADUC_profile_share_empty.png]]



== In a NT4 domain ==

* If you have and NT4 domain, set the following directive in your smc.conf to empty pm on your PDC:

logon path =

:Note: When using local profiles, Samba's "logon drive" directive has no meaning. If you still want the users home directory on a Samba server, set to a drive letter, you must set it with a logonscript.

* Reload Samba:
# smbcontrol all reload-config




= Implementing roaming profiles with Samba =

== Creating a profiles share and setting permissions==

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.

:[[Image:Shares_view.png]]

* 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.

:[[Image:Advanced_share_settings.png]]

* Set the permissions as shown in the following table

:{| border="1"
!Name
!Permissions
!Apply to
|-
|-
|Administrator
! Desktop
|Full control
| User's Desktop Folder (icons, etc.)
|This folder, subfolders and files
|-
|-
|Domain Users
! Favorites
|Traverse folder/execute file, List folder/read data, Create folder/append data
| Microsoft's IE stores user's favorites here (url shortcuts)
|This folder only
|-
|-
|CREATOR OWNER
! Local Settings
|Full control
| Extra Data for local computer should be stored here (Temp, etc)
|Subfolders and files only
|-
! 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.


:[[Image:Profile_share_permissions_for_group.png]]
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.


: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“.
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).


* Save the new permissions by closing the windows with „OK“.
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.


=== Profiles share on a Samba 3.x server ===
====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.


* Create a folder for the roaming profiles and set permissions
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).
# mkdir -p /srv/samba/Profiles/
# chmod 1770 /srv/samba/profiles
# chgrp „Domain Users“ /srv/samba/profiles


* Add a new share to your smb.conf:
==Implementing Local Profiles with Samba==
[Profiles]
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:
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:
logon path =
# smbcontrol all reload-config
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.


== Configuring roaming profiles for a user ==
==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.


=== In an AD environment ===
'''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.


In an AD environment, you can setup roaming profiles individual for every user.
=== Creating the Profile Share ===


* Open ADUC.
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:


* Right-click to an user account and choose „Properties“.
[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
profile acls = yes
csc policy = disable


* Go to the „Profile“ tab, and fill the path to the users profile.
Then ensure that everyone has write access to the directory listed as the path:


:[[Image:ADUC_profile_share.png]]
chmod 1777 /srv/samba/profiles


:If you use the %USERNAME% variable, you can set the profile path to multiple accounts at once, too.
=== Setting relevant directives for Roaming Profiles ===
The smb.conf settings required to use Roaming Profiles by default are:


:Windows Vista and later create .V2 folders for their profiles. This is appended automatically, if a profile from that OS is uploaded to the server.
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).


=== In a NT4 domain ===
You can also take full advantage of Samba's Variable Substitutions and further separate User's profiles, such as by architecture. Using the directive:


In a NT4 environment, you can setup roaming profiles only global for all users on the Samba PDC.
logon path = \\%L\profiles\%U\%a


* Add a following to your smb.conf:
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.


=== Troubleshooting Roaming Profiles ===
logon path = \\%L\Profiles\%U


In Windows 7, the registry contains information on each user's roaming profile and should your Samba infrastructure change, such as the network location of user's profiles, this can lead to Windows being unable to find the profile. The list of user profiles are located at:
: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 users 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 Sambas variable substitutions (see „man smb.con“ in the „variable substitutions“ section).

* Reload Samba:
# smbcontrol all reload-config




= Troubleshooting roaming profiles =

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
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList


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





= Configuring folder redirection =

== In an AD environment ==

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.
:[[Image:Edit_group_policy.png]]

* 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.
:[[Image:Folder_Redirection_Documents.png]]

* In the „Folder redirection“ sub-tree you can redirect other folders, too.

* Save the changes by closing the Group Policy Management Editor.



== In a NT4 domain ==

NT4 policies can only be applied to Windows NT4 up to XP machines. Newer Windows version only support group policies.

To keep this guide simple, we set the folder redirection in this example on the default user policy.

* Open the System Policy Editor (poledit.exe).
:You find PolEdit e. g. on your NT4 Server CD or in the Ms Office 2000 Resource Kit (ORK).

* Go to „Options“ / „Policy Template“ and open an ADM file, that contains policies for folder redirection (you can download such an ADM file at Novell: [http://www.novell.com/coolsolutions/tools/downloads/redirect.zip http://www.novell.com/coolsolutions/tools/downloads/redirect.zip]
:[[Image:Poledit_opening_adm.png]]

* Create a new policy or open an existing.

* Double-click „Default User“.

* Follow the tree to the folder redirection (the way depents on the ADM file you use).
:[[Image:Poledit_folder_redirection.png]]

* Set a location where you want to redirect the folder to.

* Redirect other folders, too, if neccessary.


* Close the „Default User Properties“ window.


* Save the policy to \\PDC\NetLogon\ntconfig.pol (the file must be placed on your PDCs NetLogon share with the name „ntconfig.pol!).
----
[[User:Mgpeter|Mgpeter]] 10:04, 6 June 2006 (CDT)
[[Category:Category HowTos]]

Revision as of 19:40, 6 June 2013

Introduction

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.



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 you are running:

OS Stored in folder
NT4 C:\WinNT\Profiles\
2000, XP C:\Documents and Settings\
Vista, 7, 8 C:\Users\

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

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

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

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

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.



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.

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_redirection.


In an AD environment

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

  • Open 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).
ADUC profile share empty.png


In a NT4 domain

  • If you have and NT4 domain, set the following directive in your smc.conf to empty pm on your PDC:
logon path =
Note: When using local profiles, Samba's "logon drive" directive has no meaning. If you still want the users home directory on a Samba server, set to a drive letter, you must set it with a logonscript.
  • Reload Samba:
# smbcontrol all reload-config



Implementing roaming profiles with Samba

Creating a profiles share and setting permissions

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.
Shares view.png
  • 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.
File:Advanced share settings.png
  • Set the permissions as shown in the following 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
File:Profile share permissions for group.png
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


Configuring roaming profiles for a user

In an AD environment

In an AD environment, you can setup roaming profiles individual for every user.

  • Open ADUC.
  • Right-click to an user account and choose „Properties“.
  • Go to the „Profile“ tab, and fill the path to the users profile.
ADUC profile share.png
If you use the %USERNAME% variable, you can set the profile path to multiple accounts at once, too.
Windows Vista and later create .V2 folders for their profiles. This is appended automatically, if a profile from that OS is uploaded to the server.


In a NT4 domain

In a NT4 environment, you can setup roaming profiles only global for all users on the Samba PDC.

  • Add a following to your smb.conf:
logon path = \\%L\Profiles\%U
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 users 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 Sambas variable substitutions (see „man smb.con“ in the „variable substitutions“ section).
  • Reload Samba:
# smbcontrol all reload-config



Troubleshooting roaming profiles

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.



Configuring folder redirection

In an AD environment

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.
File:Edit group policy.png
  • 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.
Folder Redirection Documents.png
  • In the „Folder redirection“ sub-tree you can redirect other folders, too.
  • Save the changes by closing the Group Policy Management Editor.


In a NT4 domain

NT4 policies can only be applied to Windows NT4 up to XP machines. Newer Windows version only support group policies.

To keep this guide simple, we set the folder redirection in this example on the default user policy.

  • Open the System Policy Editor (poledit.exe).
You find PolEdit e. g. on your NT4 Server CD or in the Ms Office 2000 Resource Kit (ORK).
Poledit opening adm.png
  • Create a new policy or open an existing.
  • Double-click „Default User“.
  • Follow the tree to the folder redirection (the way depents on the ADM file you use).
Poledit folder redirection.png
  • Set a location where you want to redirect the folder to.
  • Redirect other folders, too, if neccessary.
  • Close the „Default User Properties“ window.
  • Save the policy to \\PDC\NetLogon\ntconfig.pol (the file must be placed on your PDCs NetLogon share with the name „ntconfig.pol!).