One benefit of the centralized authentication of Windows NT domains is that a user can log on from more than just one computer. To help users feel more “at home” when logged on at a computer other than their usual one, Microsoft has added the ability for users’ personal settings to “roam” from one computer to another.
All Windows versions can be configured individually for each user of the computer. Windows NT/2000/XP supports the ability to handle multiple user accounts, and Windows 95/98/Me can be configured for use by multiple users, keeping the configuration settings for each user separate. Each user can configure the computer’s settings to her liking, and the system saves these settings as the user’s profile, such that upon logging on to the system, the user is presented with her familiar desktop.
Some of the settings, such as folder options or the image used for the desktop background, are held in the registry. Others, including the documents and folders appearing on the desktop and the contents of the Start menu, are stored as folders and files in the filesystem.
When the profile is stored on the local system, it is called a
local profile
. On Windows NT, local profiles are
stored in C:\winnt\profiles. On Windows 2000/XP,
they can be found in C:\Documents and Settings.
On Windows 95/98/Me, when configured for a single user
(the default case), the local profile is scattered in places such as
the registry and directories such as
C:\Windows\Desktop and
C:\Windows\Start Menu. When Windows 95/98/Me is
configured for multiple users, the local profile of the preexisting
user is moved to a folder in C:\Windows\Profiles
that has the same name as the user, and any users that are
subsequently added to the computer have their local profiles created
in that directory as well. You can browse through the local profiles
to see their structure—each has a
registry file
(USER.DAT
for Windows 95/98/Me and
NTUSER.DAT
for Windows NT/2000/XP) and some folders
that contain shortcuts and documents.
A roaming profile is a user profile that is stored on a server and “follows” its owner around the network so that when the user logs on to the domain from another computer, his profile is downloaded from the server and his familiar desktop appears on that computer as well.
Warning
Samba can support roaming profiles, and it is a fairly simple matter to configure it for them. However, this is one feature that we recommend you do not use, at least until you are sure you understand roaming profiles well and are very confident that you can implement them with no harm incurred. If you want to (or are required to) implement roaming profiles for your Windows clients, we suggest you first set up a small domain with a Samba server and a few Windows clients exclusively for the purposes of research and testing. Under no circumstances should you attempt to implement roaming profiles in a careless or frivolous manner.
We will start out by explaining to you how roaming profiles work when set up correctly. You will need a clear understanding of them to tell the difference between when they are working as they are designed and when they are not. In addition, roaming profiles can be a source of confusion for your users in many ways, and you should know how to detect when a problem with a client is related to roaming profile function or dysfunction.
Tip
A definitive source of documentation on Windows NT roaming profiles is the Microsoft white paper Implementing Policies and Profiles for Windows NT 4.0 , which can be found at http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp.
During the domain logon process, the roaming profile is copied from the domain controller and used as a local profile during the user’s logon session. When the user logs off the domain, the local profile is copied back to the domain controller and stored as the new roaming profile. When the local profile is changed, the server does not receive an update until the user logs off the domain or shuts down or reboots the client. The client does not send an update to the server during the logon session, and a client does not receive an update of a setting changed on another client during a logon session. When the user does log off, changes in the configuration settings in the local profile are sent to the server, and the updates of the roaming profile are available for the next logon session.
This simple behavior can lead to unexpected results when users are logged on to the domain on more than one client at a time. If a user makes a change to the configuration settings on one client and then logs off, the settings can result in the roaming profile being modified accordingly. But the next client that logs off might cause those changes to be overwritten, and if so, the settings from the first client will be lost. The behavior of different Windows versions varies with regard to this, and we’ve seen a wide variety of behaviors—not always in alignment with Microsoft’s documentation or even working the same way on separate occasions. Sometimes Windows will refuse to overwrite a profile, perhaps giving an “access denied” error, and at other times it will seem to work while producing odd side effects. A common source of confusion is what happens if a file is added to or deleted from the desktop, which is by default configured to be part of the profile. A deleted file might later reappear, and it is even possible for a file to irrecoverably disappear without warning (on Windows 95/98). Or maybe a file that is added to the desktop on one client never gets added to the roaming profile and fails to propagate to other clients. This behavior is somewhat improved on Windows 2000/XP, which attempts to merge items into the profile that are added on concurrently logged-on clients.
One factor that comes into play is that Windows compares the
timestamps of the local and roaming
profiles and can refuse to overwrite a roaming profile if it is newer
than the local profile on the client, or vice versa. For this reason,
it is important to keep the clocks of the Windows clients and the
Samba PDC synchronized. We have already shown you how to do this,
using the net time \\
server
/set
/yes command in the
logon script.
Even when the server and clients are correctly configured, a number of things that can happen make things seem “broken.” The most common occurrence is that some shortcuts on clients other than the one that created the roaming profile will not work. These shortcuts can exist on the desktop or as items in the Start menu. This behavior is a result of applications or files that exist on one computer but not others. Windows will display these shortcuts, but if they appear on the desktop, they will have a generic icon and will bring up an error message if a user double-clicks them.
Tip
Because profiles can and usually do include the contents of the
desktop and other folders, it is possible for the roaming profile to
grow to a huge size due to actions of a user, such as creating new
files on the desktop or copying files there. By default, Internet
Explorer keeps its disk cache in the Temporary Internet
Files
folder in the profile and has been
known to populate this directory with thousands of files. This can
result in a huge roaming profile that causes network congestion and
very large delays while users are logging on to the domain. (A fix
for this can be found in article Q185255 in the Microsoft Knowledge
Base.)
One behavior we’ve seen a few times is that if, for some reason (e.g., a network error or misconfiguration), the roaming profile is not available during the logon process, Windows will use the local profile on the client instead. When this happens, the user might receive an unfamiliar profile, and all the benefits of roaming profiles are lost for that logon session.
In an ideal world, different Windows versions would share the same roaming profile, allowing users to log on to the domain from any Windows client system, ranging from Windows 95 to Windows XP, and enjoy their familiar settings. It would even be possible to be logged on concurrently from multiple clients, and a change made to the profile on any of them would quickly propagate to all the others. Settings in a roaming profile made on a client that didn’t apply to another would be handled sanely.
Unfortunately, this scenario does not work in reality, and it is important to maintain separate roaming profiles to prevent different Windows versions from using or modifying a roaming profile created by, and/or in use by, another version.
We do this by using configuration file variables to point to
different profile directories. If you look at Table B-1 in Appendix B, which shows
the variables that can be used, you might be tempted to use the
%a variable, which
is replaced by the name of the operating system the client is
running. However, this does not work because all of Windows 95/98/Me
will be seen as the same operating system, and likewise for Windows
2000/XP. So, we use
%m to get the
NetBIOS name of the client, and combine that with a symbolic link to
point to the directory containing the profile for the Windows version
that particular client is running.
Our additions to smb.conf that appeared earlier
in this chapter included the two lines:
logon path = \\%L\profiles\%u\%m logon home = \\%L\%u\.win_profile\%m
The first line specifies where the roaming profiles for Windows
NT/2000/XP clients are kept, and the second line performs the same
function for Windows 95/98/Me clients. In both cases, the location is
specified as a UNC, but
logon
path (for Windows
NT/2000/XP) is specified relative to the
[profiles] share, while
logon
home (for Windows
95/98/Me) is specified relative to the user’s home
directory. This is done to comply with Samba’s
emulation of Windows NT/2000 PDC behavior.
The logon
home UNC must begin
by specifying the user’s home directory, which in
our previous example would be \\%L\%u. The
variable %L
expands to the NetBIOS name of the
server (in this case, toltec), and
%u
expands to the name of the user. This
must be done to allow the command:
C:\>net use h: /hometo function correctly to connect the user’s home
directory to drive letter H: on all Windows clients. (The drive
letter used for this purpose is defined by logon
drive.) We add the directory
.win_profile
to the UNC to put the Windows
95/98/Me roaming profile in a subdirectory of the
user’s home directory.
Warning
Note that in both logon path and logon home, we absolutely avoid making the profile directory the
same as the user’s home directory, and the directory
that contains the profile is not used for any other purpose. This is
because when the roaming profile is updated, all directories and
files in the roaming-profile directory that are not part of the
roaming profile are deleted.
In the logon
path line in
smb.conf, we use %u to put
the profiles directory in a subdirectory in the
[profiles] share, such that each user gets her own
directory that holds her roaming profiles.
We define the [profiles] share like this:
[profiles]
writable = yes
create mask = 0600
directory mask = 0700
browsable = no
path = /home/samba-ntprofThe first four parameters in the previous share definition specify to
allow roaming profiles to be written with the users’
permissions, to create files with read and write permissions for the
owner, and to create directories with read, write, and search
permissions for the owner and no access allowed for other users. As
with the [netlogon] share, we set
browsable
=
no so that the share will not show up on the
clients in Windows Explorer.
We’ve decided to put our Windows NT/2000/XP profiles
in /home, the default location of the home
directories on Linux. This will make it simple to include the roaming
profiles in backups of the home directories. You can use another
directory if you like.
Notice that in both logon
path
and logon
home, the directory
we specify ends in %m, which Samba replaces with
the NetBIOS name of the client. We are using the
client’s computer name to identify indirectly which
version of Windows it is running.
Initially, the directories you specify to hold the roaming profiles
will be empty and will become populated as clients log off for the
first time. (Samba will even create the directories if they do not
already exist.) At first, the directories will simply contain
profiles that are identical to the clients’ local
profiles, and we highly recommend that you make a backup at this
point before things get complicated. A listing of the roaming profile
directory for user iman, after she has logged off
from Windows 98 clients mixtec and
pueblo and Windows Me clients
huastec and navajo, might look
something like the following:
$ ls -l /home/iman/.win_profile
total 4
drwx------ 6 iman iman 4096 Dec 8 18:09 huastec
drwx------ 9 iman iman 4096 Dec 7 03:47 mixtec
drwx------ 11 iman iman 4096 Dec 7 03:05 navajo
drwx------ 11 iman iman 4096 Dec 7 03:05 puebloIf things were left like this, the clients would not share their roaming profiles, so next we change from using separate directories to having symbolic links point to common directories:
#mv mixtec Win98#mv navajo WinMe#rm huastec pueblo#ln -s Win98 pueblo#ln -s WinMe huastec#chown iman:iman *#ls -l /home/iman/.win_profiletotal 6 lrwxrwxrwx 1 iman iman 5 Nov 16 01:40 huastec -> WinMe lrwxrwxrwx 1 iman iman 5 Nov 16 01:40 mixtec -> Win98 lrwxrwxrwx 1 iman iman 5 Nov 21 17:24 navajo -> WinMe lrwxrwxrwx 1 iman iman 5 Nov 23 01:16 pueblo -> Win98 drwx------ 9 iman iman 4096 Dec 7 03:47 Win98 drwx------ 11 iman iman 4096 Dec 7 03:05 WinMe
Now when iman logs on to the domain from either
Windows 98 system, the client from which she is logging on will get
the profile stored in the Win98 directory (that
started out as her local profile on mixtec). This
works likewise for the Windows Me clients.
To show a more complete example, here is a listing of a fully operational Windows 95/98/Me profiles directory:
$ ls -l /home/jay/.win_profile
total 12
lrwxrwxrwx 1 jay jay 9 Nov 16 22:14 aztec -> /home/jay
lrwxrwxrwx 1 jay jay 5 Nov 16 01:40 hopi -> Win95
lrwxrwxrwx 1 jay jay 5 Nov 16 01:40 huastec -> WinMe
lrwxrwxrwx 1 jay jay 5 Nov 16 01:38 maya -> Win98
lrwxrwxrwx 1 jay jay 5 Nov 16 01:40 mixtec -> Win98
lrwxrwxrwx 1 jay jay 5 Nov 21 17:24 navajo -> WinMe
lrwxrwxrwx 1 jay jay 5 Nov 23 01:16 pueblo -> Win98
lrwxrwxrwx 1 jay jay 5 Nov 22 02:06 ute -> Win95
drwx------ 6 jay jay 4096 Dec 8 18:09 Win95
drwx------ 9 jay jay 4096 Dec 7 03:47 Win98
drwx------ 11 jay jay 4096 Dec 7 03:05 WinMe
lrwxrwxrwx 1 jay jay 5 Nov 21 22:48 yaqui -> Win98
lrwxrwxrwx 1 jay jay 9 Nov 16 22:14 zuni -> /home/jayAgain, the computer name of each client exists in this directory as a
symbolic link that points to the directory containing the actual
roaming profile. For example, maya, a client that
runs Windows 98, has a symbolic link named maya
to the Win98 directory. A listing of
Win98 shows:
$ ls -l Win98
total 148
drwxr-xr-x 3 jay jay 4096 Nov 23 01:30 Application Data
drwxr-xr-x 2 jay jay 4096 Nov 23 01:30 Cookies
drwxr-xr-x 3 jay jay 4096 Dec 7 03:47 Desktop
drwxr-xr-x 3 jay jay 4096 Nov 23 01:30 History
drwxr-xr-x 2 jay jay 4096 Nov 23 01:30 NetHood
drwxr-xr-x 2 jay jay 4096 Dec 7 03:47 Recent
drwxr-xr-x 3 jay jay 4096 Nov 23 01:30 Start Menu
-rw-r--r-- 1 jay jay 114720 Dec 7 03:46 USER.DATThe contents of the Win95 and
WinMe directories appear similar and contain
roaming profiles that work exactly as they should on their respective
operating systems.
Notice in the previous listing that aztec and
zuni are symbolic links to
/home/jay. We’ve cautioned you
never to configure a roaming profile directory to be a
user’s home directory, but this is to handle
something different. The clients aztec and
zuni are Windows XP systems, which handle
logon
home differently than
other versions of Windows. We have set logon
home
=
\\%L\%u\.win
profile, and all versions of Windows except for
Windows XP strip off everything after \\%L\%u and
correctly locate the home directory—in this case,
/home/jay. Windows XP uses the full UNC, so we
simply add a symbolic link to redirect it to the correct directory to
get the net use H: /home command to work as it
should. The roaming profiles for Windows XP systems are not affected
by this and are kept with the other roaming profiles in the Windows
NT/2000/XP family, as shown in this listing:
$ ls -l /home/samba-ntprof/jay
total 16
lrwxrwxrwx 1 jay jay 5 Nov 20 03:45 apache -> Win2K
lrwxrwxrwx 1 jay jay 5 Nov 13 12:35 aztec -> WinXP
lrwxrwxrwx 1 jay jay 5 Nov 13 12:34 dine -> WinNT
lrwxrwxrwx 1 jay jay 5 Nov 24 03:44 inca -> Win2K
lrwxrwxrwx 1 jay jay 5 Nov 13 12:34 pima -> Win2K
drwx------ 13 jay jay 4096 Dec 3 15:24 qero
drwx------ 13 jay jay 4096 Dec 1 20:31 Win2K
drwx------ 12 jay jay 4096 Nov 30 17:04 WinNT
drwx------ 13 jay jay 4096 Nov 20 01:23 WinXP
lrwxrwxrwx 1 jay jay 5 Nov 20 06:09 yavapai -> WinXP
lrwxrwxrwx 1 jay jay 5 Nov 13 12:34 zapotec -> Win2K
lrwxrwxrwx 1 jay jay 5 Nov 13 12:35 zuni -> WinXPAs you can see, we are using a similar method for the Windows
NT/2000/XP roaming profiles. In the listing,
qero is not a symbolic link, but rather a
directory that holds the roaming profile for qero,
a Windows 2000 client that has recently been added. We had not
created a symbolic link called qero before
installing Windows 2000, so when jay logged off for the first time,
Samba created a directory named qero and copied
the roaming profile received from the client to the new directory.
Because this is a separate directory from Win2K,
which all other Windows 2000 clients are using to share their roaming
profiles, the roaming profile for qero works like
a local profile, except that it is stored on the primary domain
controller.
This might seem like an odd thing to do, but it has some purpose.
Sometimes you might wish to isolate a client in this manner,
especially while the operating system is being installed and
initially configured. Remember, if that client, with its default
local profile, is logged off the domain, the local profile will be
written to the roaming profile directory. If the client were using
the shared roaming profile directory, the effect could be
undesirable, to say the least. Using our method, the
qero directory can later be renamed to make it
into an archival backup, or it can just be deleted. Then a new
symlink named qero can be created to point to
the Win2K directory, and qero
will share the roaming profile in Win2K with the
other Windows 2000 clients.
An alternative method is simply to create the symbolic links before the clients are added to the network. After you become more comfortable with the way roaming profiles work, you might find this method to be simpler and quicker.
Again, we urge you to be careful about letting different versions of
Windows share the same roaming profile. The method of configuring
roaming profiles we’ve shown you here allows you to
test a configuration for a few clients at a time without affecting
your whole network of clients. For example, we could install a small
number of Windows 2000 and Windows XP systems in the domain for
testing purposes and then create symlinks for them that point to a
directory called Win2KXP to find out if sharing
roaming profiles between our Windows 2000 and Windows XP systems
meets our expectations. The Win2KXP directory
could be created as an empty directory, in which case it would have a
roaming profile written to it by the first of the clients to log off.
Or, Win2KXP could simply be a renamed roaming
profile directory that was created by one of the clients when it was
added to the domain.
For roaming profiles to work on Windows 95/98/Me clients, all you need to do is change one setting to allow each user to have a separate local profile. This has the side effect of enabling roaming profiles as well.
Open the Control Panel and double-click the Passwords icon to open the Passwords Properties dialog box. Click the User Profiles tab, and the dialog box will appear as shown in Figure 4-12.
Click the button labeled “Users can customize their
preferences and desktop settings.” In the User
profile settings box, you can check the options you prefer. When
done, click the OK button and reboot as requested. During this first
reboot, Windows will copy the local profile data to
C:\windows\profiles but will not attempt to copy
the roaming profile from the server. The next time the system is shut
down, the local profile will be copied to the server, and when
Windows reboots, it will copy the roaming profile from the server.
Roaming profiles are enabled by default on Windows NT/2000/XP. In case you would like to check or modify your settings, follow these directions.
Make sure you are logged in to the local system as Administrator or another user in the Administrators group. Open the Control Panel and double-click the System icon. On Windows NT/2000, click the User Profiles tab, or on Windows XP, click the Advanced tab and then the Settings button in the User Profiles box. You should see the dialog box in Figure 4-13.
Notice in the figure that there are two entries for the username
jay. The entry ZAPOTEC\jay refers to the account
on the local system, and METRAN\jay refers to the domain account.
Recall that when a user logs on, a drop-down menu in the dialog box
allows him to log on to a domain or log in to the local system. When
jay logs in to the local machine, only the local
profile is used. When logged on to the domain, the configuration
shown will use the roaming profile. To switch a
user’s profile type for a domain logon account,
click the account name to select it, then click the Change Type...
button near the bottom of the dialog box. The Change Profile Type
dialog box will appear. Click the radio button for either roaming or
local profile, and then click the OK buttons for each dialog box.
With a simple modification, a roaming profile can be made into a mandatory profile, which has the quality of being unmodifiable by its owner. Mandatory profiles are used in some computing environments to simplify administration. The theory is that if users cannot modify their profiles, less can go wrong, and it is also possible to use the same standardized profile for all users.
In practice, some issues come up. Because the users can still modify the configuration settings in their local profile during their logon session, confusion can result the next time they log on to the domain and discover their changes have been “lost.” If the user of a client reinstalls an application in a different place, the shortcuts to the program on the desktop, in the Start menu, or in a Quick Launch bar cannot be permanently deleted. They will reappear every time the user logs back on to the domain. Essentially, a mandatory profile is a roaming profile that always fails to update to the server upon logging off!
Another complication is that different versions of Windows behave differently with mandatory profiles. If a user who has a mandatory profile creates a new file on her desktop, the file might be missing the next time the user logs off and on again or reboots. Some Windows versions preserve desktop files in the local profile (even if the file does not exist in the mandatory profile), whereas others do not.
To change a
roaming profile to a mandatory
profile, all you have to do is rename the
.dat
file in the roaming profile directory
on the server to have a .man extension instead.
For a Windows 95/98/Me roaming profile, you would rename
USER.DAT to USER.MAN, and
for a Windows NT/2000/XP roaming profile, you would rename
NTUSER.DAT to NTUSER.MAN.
Also, you might want to make the roaming-profile directory and its
contents read-only, to make sure that a user can’t
change it by logging into his Unix user account on the Samba host
system.
If you want to have all your users share a mandatory profile, you can
change the definitions of logon
path and logon
home in your smb.conf file to
point to a shared mandatory profile on the server and adjust your
directory structure and symbolic links accordingly. For example,
logon
path and
logon
home might be defined
like this:
logon path = \\%L\profiles\%m logon home = \\%L\%u\.win_profile\%m
Notice that we’ve removed the %u
part of the path for logon
path, and we would also change the directory
structure on the server to do away with the separation of the
profiles by username and have just one profile for each Windows
NT/2000/XP version.
We cannot use the same treatment for logon
home because it is also used to specify the home
directory. In this case, we would change the symbolic links in each
user’s .win_profile directory
to point to a common mandatory profile directory containing the
mandatory profiles for each of Windows 95/98/Me. Again, check the
ownership and permissions on the files in the directory, and modify
them if necessary to make sure a user can’t modify
any files by logging into her Unix account on the Samba host system.
Table 4-1 summarizes the options commonly used in association with Windows NT domain logon scripts and roaming profiles.
Table 4-1. Logon-script options
|
Option |
Parameters |
Function |
Default |
Scope |
|---|---|---|---|---|
|
|
string (MS-DOS path) |
Name of logon script batch file |
None |
Global |
|
|
string (UNC server and share name) |
Location of roaming profile |
|
Global |
|
|
string (drive letter) |
Specifies the logon drive for a home directory |
|
Global |
|
|
string (UNC server and share name) |
Specifies a location for home directories for clients logging on to the domain |
|
Global |
This option specifies a Windows batch file that will be executed on
the client after a user has logged on to the domain. Each logon
script should be stored in the root directory of the
[netlogon] share or a subdirectory. This option
frequently uses the %U or %m
variables (user or NetBIOS name) to point to an individual script.
For example:
[global]
logon script = %U.batwill execute a script based on the username. If the user who is
connecting is fred and the path of the
[netlogon] share maps to the directory
/export/samba/netlogon, the script should be
/export/samba/netlogon/fred.bat. Because these
scripts are downloaded to the client and executed on the Windows
side, they must have MS-DOS-style newline characters rather than Unix
newlines.
This option specifies the location where roaming profiles are kept. When the user logs on, a roaming profile will be downloaded from the server to the client and used as the local profile during the logon session. When the user logs off, the contents of the local profile will be uploaded back to the server until the next time the user connects.
It is often more secure to create a separate share exclusively for storing user profiles:
[global]
logon path = \\hydra\profile\%UFor more information on this option, see Section 4.5 earlier in this chapter.
This option specifies the drive letter on a Windows NT/2000/XP client
to which the home directory specified with the
logon
home option will be
mapped. Note that this option will work with Windows NT/2000/XP
clients only. For example:
[global]
logon drive = I:You should always use drive letters that will not conflict with fixed drives on the client machine. The default is Z:, which is a good choice because it is as far away from A:, C:, and D: as possible.
This option specifies the location of a user’s home directory for use by the MS-DOS net commands. For example, to specify a home directory as a share on a Samba server, use the following:
[global]
logon home = \\hydra\%UNote that this works nicely with the [homes]
service, although you can specify any directory you wish. Home
directories can be mapped with a logon script using the following
command:
C:\>net use i: /home Get Using Samba, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
