Roaming Windows User Profiles: Difference between revisions

From SambaWiki
m (/* minor update)
(61 intermediate revisions by 7 users not shown)
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.


A Windows profile is a set of files that contains all settings of a user including per-user configuration files and registry settings. In an Active Directory or NT4 domain you can set that the profile of a user is stored on a server. This enables the user to log on to different Windows domain members and use the same settings.
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.


When using roaming user profiles, a copy of the profile is downloaded from the server to the Windows domain member when a user logs into. Until the user logs out, all settings are stored and updated in the local copy. During the log out, the profile is uploaded to the server.
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.


= Windows Roaming Profile Versions =
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.


Depending on the operating system version, Windows uses separate profile folders for a user to support Windows version-specific features. Version 2 profiles and later append the <code>.V*</code> suffix to the user's profile folder.
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''.


The following Windows profile versions exist:
===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).


:{| class="wikitable"
=== Roaming Profiles ===
!Windows Client OS Version
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.
!Windows Server OS Version
!Profile Suffix
!Example Profile Folder Name
|-
|Windows NT 4.0 - Windows Vista
|Windows NT Server 4.0 - Windows Server 2008
|''none''
|user
|-
|Windows 7
|Windows Server 2008 R2
|V2
|user.V2
|-
|Windows 8.0 - 8.1*
|Windows Server 2012 - 2012 R2*
|V3
|user.V3
|-
|Windows 8.1*
|Windows Server 2012 R2*
|V4
|user.V4
|-
|Windows 10 (1507 to 1511)
|Windows Server 2016
|V5
|user.V5
|-
|Windows 10 (1607 and later)
|
|V6
|user.V6
|}


: <nowiki>*</nowiki> Using the default settings, Windows 8.1 and Windows Server 2012 R2 use V3 profiles. However, the profiles are incompatible with Windows 8.0 and Windows Server 2012. For this reason it is recommended that you configure Windows 8.1 and Windows Server 2012 R2 to use V4 profiles. For further details, see: [https://support.microsoft.com/en-us/help/2890783/incompatibility-between-windows-8.1-roaming-user-profiles-and-those-in-earlier-versions-of-windows Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows].
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.


When you set the profile path for a user, you always set the path without any version suffix. For example:
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.
\\server\profiles\user_name


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


= Setting up the Share on the Samba File Server =
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.


== Using Windows ACLs ==
====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.


To create a share, for example, <code>profiles</code> for hosting the roaming profiles on a Samba file server:
{| border="1"

|+ Default Folders within a User's Profile
* Create a new share. For details, see [[Setting up a Share Using Windows ACLs]]. Set the following permissions:
! Folder Name !! Description

:* Share tab permissions:
::{| class="wikitable"
!Principal
!Allow
|-
|-
|Everyone
! Application Data
|Full Control / Change / Read
| Apps should store extra data here (similar to "dot files" in Linux, a.k.a. "hidden files" in Windows)
|}

:* Security tab file system permissions on the root of the <code>profiles</code> share:

::{| class="wikitable"
!Principal
!Access
!Applies to
|- style="vertical-align:top;"
|Domain Users *
|Traverse folder / execute file<br />List folder / read data<br />Create folder / append data
|This folder only
|-
|-
|CREATOR OWNER
! Cookies
|Full control
| Microsoft Internet Explorer stores user's cookies here
|Subfolders and files only
|-
|-
|Domain Admins
! Desktop
|Full control
| User's Desktop Folder (icons, etc.)
|This folder, subfolders and files
|-
|-
|SYSTEM **
! Favorites
|Full control
| Microsoft's IE stores user's favorites here (url shortcuts)
|This folder, subfolders and files
|-
! 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
|}
|}
::<nowiki>*</nowiki> You can alternatively set other groups, to enable the group members to store their user profile on the share. When using different groups, apply the permissions as displayed for <code>Domain Users</code> in the previous example.
'''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.

::<nowiki>**</nowiki> For details, see [[The SYSTEM Account]].

:: Verify that permission inheritance is disabled on the root of the share. If any permission entry in the <code>Advanced Security Settings</code> window displays a path in the <code>Inherited from</code> column, click the <code>Disable inheritance</code> button. On Windows 7, unselect the <code>Include inheritable permissions from this object's parent</code> check box to set the same setting.

::[[Image:Profiles_Folder_File_System_ACLs.png]]

These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Members of the <code>Domain Admins</code> group are able to access all directories on the share.



== Using POSIX ACLs on a Unix domain member ==

On a Unix domain member server, you can set up the <code>profiles</code> share using POSIX ACLs instead of using Windows access control lists (ACL). This will not work on a Samba Active Directory Controller.



{{Imbox
| type = warning
| text = When setting up the share on a Samba Active Directory (AD) domain controller (DC), you cannot use POSIX ACLs. On an Samba DC, only shares using extended ACLs are supported. For further details, see [[Setting_up_a_Share_Using_Windows_ACLs#Enable_Extended_ACL_Support_in_the_smb.conf_File|Enable Extended ACL Support in the smb.conf File]]. To set up the share on a Samba AD DC, see [[#Using_Windows_ACLs|Setting up the Profiles Share on the Samba File Server - Using Windows ACLs]].
}}


* Add the following share configuration section to your <code>smb.conf</code> file:

[profiles]
comment = Users profiles
path = /srv/samba/profiles/
browseable = No
read only = No
force create mode = 0600
force directory mode = 0700
csc policy = disable
store dos attributes = yes
vfs objects = acl_xattr

: For details about the parameters used, see the descriptions in the <code>smb.conf(5)</code> man page.

* Create the directory and set permissions:

# mkdir -p /srv/samba/profiles/
# chgrp -R "Domain Users" /srv/samba/profiles/
# chmod 1750 /srv/samba/profiles/

: These settings enable members of the <code>Domain Users</code> group to store their roaming profiles on the share, without being able to access other user's profiles. Alternatively, you can set a different group.

* Reload Samba:

# smbcontrol all reload-config





= Assigning a Roaming Profile to a User =

Depending on the Windows version, Windows uses different folders to store the roaming profile of a user. However, when you set the profile path for a user, you always set the path to the folder without any version suffix. For example:
\\server\profiles\user_name

For further details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].

Note that you must not set a trailing backslash.



== In an Active Directory ==

=== Using <code>Active Directory Users and Computers</code> ===

In an Active Directory, you can use the <code>Active Directory Users and Computers</code> Windows application to set the path to the user's profile folder. If you do not have the Remote Server Administration Tools (RSAT) installed, see [[Installing RSAT|Installing RSAT]].

To assign <code>\\server\profiles\demo</code> as profile folder to the <code>demo</code> account:

* Log in to a computer using an account that is enabled to edit user accounts.

* Open the <code>Active Directory Users and Computers</code> application.

* Navigate to the directory container that contains the <code>demo</code> account.

* Right-click to the <code>demo</code> user account and select <code>Properties</code>.

* Select the <code>Profile</code> tab.

* Fill the path to the home folder into the <code>Profile path</code> field.
: Set the path always without any profile version suffix and without trailing backslash. For details, see [[#The_Windows_Roaming_Profile_Versions|The Windows Roaming Profile Versions]].

:[[Image:ADUC_Set_Profile_Folder.png]].

* Click <code>OK</code>.

The setting is applied the next time the user logs in.



=== Using a Group Policy Object ===

Using group policy objects (GPO), you can assign settings to organizational units (OU) or to a domain. This enables you, for example, to automatically assign profile paths to all users that log on to a computer that is a member of the OU or domain. If you move the computer to a different OU or domain, the setting is removed or updated. Using this way, you do not have to assign manually the settings to each user account.

{{Imbox
| type = note
| text = Windows only supports assigning a profile path using GPOs on a per-computer basis. This means that the path is also applied to local users on domain members, which have no access to the profile share. To set the profile path on a per-user basis, see [[#Using_Active_Directory_Users_and_Computers|Using Active Directory Users and Computers]].
}}

To create a group policy object (GPO) for the domain that automatically assigns the <code>\\server\path\''user_name''</code> path to every user that logs on to a Windows domain member:

* Log in to a computer using an account that is allowed to edit group policies, such as the AD domain <code>Administrator</code> account.

* Open the <code>Group Policy Management Console</code>. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see [[Installing RSAT|Installing RSAT]].

* Right-click to your AD domain and select <code>Create a GPO in this domain, and Link it here</code>.

:[[Image:GPMC_Create_GPO.png]]

* Enter a name for the GPO, such as <code>Profiles on ''server''</code>. The new GPO is shown below the domain entry.

* Right-click to the newly-created GPO and select <code>Edit</code> to open the <code>Group Policy Management Editor</code>.

* Navigate to the <code>Computer Configuration</code> &rarr; <code>Policies</code> &rarr; <code>Administrative Templates</code> &rarr; <code>System</code> &rarr; <code>User Profiles</code> entry.

* Double-click the <code>Set roaming profile path for all users logging onto this computer</code> policy to edit:

:* Enable the policy and set the profile path. For example:

\\server\profiles\%USERNAME%

:: Windows replaces the <code>%USERNAME%</code> variable with the user name during login. Set the path without trailing backslash.

::[[Image:GPME_Set_Profiles_Properties.png]]

:* Click <code>OK</code>.

* Close the <code>Group Policy Management Editor</code>. The GPOs are automatically saved on the <code>Sysvol</code> share on the domain controller (DC).

* Close the <code>Group Policy Management Console</code>.


The GPO is applied at the next reboot of the Windows domain members or when they reload the group policies.
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.


=== Using <code>ldbedit</code> on a Domain Controller ===
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.


On a domain controller (DC), to assign, for example, the <code>\\server\profiles\demo\</code> path as profile folder to the <code>demo</code> account:
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.


* Edit the <code>demo</code> user account:
====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.


# ldbedit -H /usr/local/samba/private/sam.ldb 'sAMAccountName=demo'
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).


* The accounts attributes are displayed in an editor. Append the following attribute and value to the end of the list:
==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:


profilePath: \\server\profiles\demo
* logon path =
* logon home =


: You must not set a trailing backslash to the path.
'''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.


* Save the changes.
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.


The setting is applied the next time the user logs in.
==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 ===


== In an NT4 Domain ==
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:


In an Samba NT4 domain, to set <code>\\server\profiles\%U</code> as path to the profile folder:
*[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*/


* Add the following parameter to the <code>[global]</code> section in your <code>smb.conf</code> file:
Then ensure that everyone has write access to the directory listed as the path:


logon path = \\%L\Profiles\%U
* chmod o+rw /srv/samba/profiles


: During logging in to the domain member, Samba automatically replaces the <code>%U</code> variable with the session user name. For further details, see the <code>Variable Substitutions</code> section in the <code>smb.conf(5)</code> man page.
=== Setting relevant directives for Roaming Profiles ===
The smb.conf settings required to use Roaming Profiles by default are:


* Reload Samba:
* logon path = \\%L\profiles\%U
* logon home = \\%L\%U\.9xprofile
* logon drive = P:


# smbcontrol all reload-config
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.


= Configuring Windows Profile Folder Redirections =


See [[Configuring Windows Profile Folder Redirections]].
----
[[User:Mgpeter|Mgpeter]] 10:04, 6 June 2006 (CDT)
[[Category:Category HowTos]]

Revision as of 08:09, 24 April 2020

Introduction

A Windows profile is a set of files that contains all settings of a user including per-user configuration files and registry settings. In an Active Directory or NT4 domain you can set that the profile of a user is stored on a server. This enables the user to log on to different Windows domain members and use the same settings.

When using roaming user profiles, a copy of the profile is downloaded from the server to the Windows domain member when a user logs into. Until the user logs out, all settings are stored and updated in the local copy. During the log out, the profile is uploaded to the server.



Windows Roaming Profile Versions

Depending on the operating system version, Windows uses separate profile folders for a user to support Windows version-specific features. Version 2 profiles and later append the .V* suffix to the user's profile folder.

The following Windows profile versions exist:

Windows Client OS Version Windows Server OS Version Profile Suffix Example Profile Folder Name
Windows NT 4.0 - Windows Vista Windows NT Server 4.0 - Windows Server 2008 none user
Windows 7 Windows Server 2008 R2 V2 user.V2
Windows 8.0 - 8.1* Windows Server 2012 - 2012 R2* V3 user.V3
Windows 8.1* Windows Server 2012 R2* V4 user.V4
Windows 10 (1507 to 1511) Windows Server 2016 V5 user.V5
Windows 10 (1607 and later) V6 user.V6
* Using the default settings, Windows 8.1 and Windows Server 2012 R2 use V3 profiles. However, the profiles are incompatible with Windows 8.0 and Windows Server 2012. For this reason it is recommended that you configure Windows 8.1 and Windows Server 2012 R2 to use V4 profiles. For further details, see: Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows.

When you set the profile path for a user, you always set the path without any version suffix. For example:

\\server\profiles\user_name



Setting up the Share on the Samba File Server

Using Windows ACLs

To create a share, for example, profiles for hosting the roaming profiles on a Samba file server:

  • Share tab permissions:
Principal Allow
Everyone Full Control / Change / Read
  • Security tab file system permissions on the root of the profiles share:
Principal Access Applies to
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
Domain Admins Full control This folder, subfolders and files
SYSTEM ** Full control This folder, subfolders and files
* You can alternatively set other groups, to enable the group members to store their user profile on the share. When using different groups, apply the permissions as displayed for Domain Users in the previous example.
** For details, see The SYSTEM Account.
Verify that permission inheritance is disabled on the root of the share. If any permission entry in the Advanced Security Settings window displays a path in the Inherited from column, click the Disable inheritance button. On Windows 7, unselect the Include inheritable permissions from this object's parent check box to set the same setting.
Profiles Folder File System ACLs.png

These settings enable members of the Domain Users group to store their roaming profiles on the share, without being able to access other user's profiles. Members of the Domain Admins group are able to access all directories on the share.


Using POSIX ACLs on a Unix domain member

On a Unix domain member server, you can set up the profiles share using POSIX ACLs instead of using Windows access control lists (ACL). This will not work on a Samba Active Directory Controller.



  • Add the following share configuration section to your smb.conf file:
 [profiles]
         comment = Users profiles
         path = /srv/samba/profiles/
         browseable = No
         read only = No
         force create mode = 0600
         force directory mode = 0700
         csc policy = disable
         store dos attributes = yes
         vfs objects = acl_xattr
For details about the parameters used, see the descriptions in the smb.conf(5) man page.
  • Create the directory and set permissions:
# mkdir -p /srv/samba/profiles/
# chgrp -R "Domain Users" /srv/samba/profiles/
# chmod 1750 /srv/samba/profiles/
These settings enable members of the Domain Users group to store their roaming profiles on the share, without being able to access other user's profiles. Alternatively, you can set a different group.
  • Reload Samba:
# smbcontrol all reload-config



Assigning a Roaming Profile to a User

Depending on the Windows version, Windows uses different folders to store the roaming profile of a user. However, when you set the profile path for a user, you always set the path to the folder without any version suffix. For example:

\\server\profiles\user_name

For further details, see The Windows Roaming Profile Versions.

Note that you must not set a trailing backslash.


In an Active Directory

Using Active Directory Users and Computers

In an Active Directory, you can use the Active Directory Users and Computers Windows application to set the path to the user's profile folder. If you do not have the Remote Server Administration Tools (RSAT) installed, see Installing RSAT.

To assign \\server\profiles\demo as profile folder to the demo account:

  • Log in to a computer using an account that is enabled to edit user accounts.
  • Open the Active Directory Users and Computers application.
  • Navigate to the directory container that contains the demo account.
  • Right-click to the demo user account and select Properties.
  • Select the Profile tab.
  • Fill the path to the home folder into the Profile path field.
Set the path always without any profile version suffix and without trailing backslash. For details, see The Windows Roaming Profile Versions.
ADUC Set Profile Folder.png.
  • Click OK.

The setting is applied the next time the user logs in.


Using a Group Policy Object

Using group policy objects (GPO), you can assign settings to organizational units (OU) or to a domain. This enables you, for example, to automatically assign profile paths to all users that log on to a computer that is a member of the OU or domain. If you move the computer to a different OU or domain, the setting is removed or updated. Using this way, you do not have to assign manually the settings to each user account.

To create a group policy object (GPO) for the domain that automatically assigns the \\server\path\user_name path to every user that logs on to a Windows domain member:

  • Log in to a computer using an account that is allowed to edit group policies, such as the AD domain Administrator account.
  • Open the Group Policy Management Console. If you are not having the Remote Server Administration Tools (RSAT) installed on this computer, see Installing RSAT.
  • Right-click to your AD domain and select Create a GPO in this domain, and Link it here.
GPMC Create GPO.png
  • Enter a name for the GPO, such as Profiles on server. The new GPO is shown below the domain entry.
  • Right-click to the newly-created GPO and select Edit to open the Group Policy Management Editor.
  • Navigate to the Computer ConfigurationPoliciesAdministrative TemplatesSystemUser Profiles entry.
  • Double-click the Set roaming profile path for all users logging onto this computer policy to edit:
  • Enable the policy and set the profile path. For example:
\\server\profiles\%USERNAME%
Windows replaces the %USERNAME% variable with the user name during login. Set the path without trailing backslash.
GPME Set Profiles Properties.png
  • Click OK.
  • Close the Group Policy Management Editor. The GPOs are automatically saved on the Sysvol share on the domain controller (DC).
  • Close the Group Policy Management Console.

The GPO is applied at the next reboot of the Windows domain members or when they reload the group policies.


Using ldbedit on a Domain Controller

On a domain controller (DC), to assign, for example, the \\server\profiles\demo\ path as profile folder to the demo account:

  • Edit the demo user account:
# ldbedit -H /usr/local/samba/private/sam.ldb 'sAMAccountName=demo'
  • The accounts attributes are displayed in an editor. Append the following attribute and value to the end of the list:
profilePath: \\server\profiles\demo
You must not set a trailing backslash to the path.
  • Save the changes.

The setting is applied the next time the user logs in.


In an NT4 Domain

In an Samba NT4 domain, to set \\server\profiles\%U as path to the profile folder:

  • Add the following parameter to the [global] section in your smb.conf file:
logon path = \\%L\Profiles\%U
During logging in to the domain member, Samba automatically replaces the %U variable with the session user name. For further details, see the Variable Substitutions section in the smb.conf(5) man page.
  • Reload Samba:
# smbcontrol all reload-config



Configuring Windows Profile Folder Redirections

See Configuring Windows Profile Folder Redirections.