Difference between revisions of "Roaming Windows User Profiles"

m (Renaming the sections about shares with/without extended ACLs enabled + minor text changes.)
m (Add info about V5 profiles in Windows10)
Line 223: Line 223:
:If you use the %USERNAME% variable, you can set the profile path to multiple accounts at once, too.
:If you use the %USERNAME% variable, you can set the profile path to multiple accounts at once, too.
:Windows Vista up to Windows 8.0 create .V2 folders for their profiles. Windows 8.1 starts using .V4 folders. This is appended automatically if a profile from those systems is uploaded to the server.
:Windows Vista up to Windows 8.0 create .V2 folders for their profiles. Windows 8.1 starts using .V4 folders and Windows 10 .V5. This is appended automatically if a profile from those systems is uploaded to the server.
=== In a NT4 domain ===
=== In a NT4 domain ===

Revision as of 19:24, 1 October 2014


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 how to setup the profile share, that is stored on a Samba server.

Depending if you want to use Windows ACLs (recommended) or POSIX ACLs for that share, there are different ways to setup:

Profile share with using Windows ACLs

  • Create a folder for the roaming profiles
# mkdir -p /srv/samba/Profiles/
  • Add a new share to your smb.conf:
     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“.

Profile share with using POSIX ACLs

  • 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:
 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 up to Windows 8.0 create .V2 folders for their profiles. Windows 8.1 starts using .V4 folders and Windows 10 .V5. This is appended automatically if a profile from those systems 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:


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 an ADM File.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 Documents.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!).