I wrote this article several years ago.  The server that used to host it is no longer available so I’ve reposted it here at request.  The material is a bit dated now.

Intro

We use Samba as our PDC (the 2.2 series) with around 75-80 XP clients. Your mileage with this stuff may vary, and if you are not careful, users could possibly lose data.

As XP roaming profiles grow, so does the amount of time it takes to log in and out. We were experiencing login and logout times of greater than 5 minutes for some of our users, with most users taking around a minute. In a classroom environment, taking up to 5 minutes to log into the system is not acceptable and so we started looking into things that could be done to speed things up.

Roaming profile background

An XP roaming profile consists of the HKEY_CURRENT_USER hive file NTUSER.DAT and a dozen or so folders (My Documents, Application Data, Desktop, Start Menu, Templates, NetHood, Favorites, etc.). Every time a user logs in, all this data is copied to the local machine and placed in %USERPROFILE%. While the user is logged in, any changes made to any of these folders or to the CURRENT_USER branch of the registry are done to this local copy of the profile. At logout all of the profile data is copied back out to the server.

Temporary fixes

The first thing we tried was to decrease the size of the profile. This included removing all the shortcuts in the Recent directory, making sure Mozilla’s cache was not being dumped into the Application Data folder, removing the Java plugin’s cache (the .jpi_cache directory in the profile), as well as training the user to not place large files on the Desktop and to use his mapped home directory for saving documents instead of the My Documents folder.

While this seemed to temporarily relieve things, it was only a matter of time before things would slow down again. Using a folder other than My Documents to save things to was a nuisance for some of our users since many applications default to using My Documents.

Profile and Local Group Policy changes

In order to really speed things up we decided to try to keep parts of the profile from being copied back and forth, without losing any functionality. It turns out that this isn’t quite as hard as we had originally feared and involves making changes to the Local Group Policy on each client as well as changing some paths in each user’s NTUSER.DAT hive. Updating the hive turned out to be the tricky part, but I found Petter Nordahl-Hagen’s Offline NT Password Editor which will modify hive files from Linux and modified it to work non-interactively (ie. within a script). Get my modified version here.

  • Local Group Policy

    Without an Active Directory PDC, you cannot take full advantage of Group Policy Objects. However, you can still make changes to the Local Group Policy just fine of course by using the Group Policy editor (gpedit.msc).

    Jeremy Nelson notes the following about Group Policies:

    Group Policies were originally used in Windows 9X and NT, and applied to everyone logging into a domain simply by placing a CONFIG.POL file (Win 9X) or NTCONFIG.POL file (Windows NT) in the NETLOGON share of the PDC. These could be modified with the poledit.exe tool, but were very primitive and applied to all users of a machine.

    Windows 2000/XP allowed for GPO (Group Policy Objects) that can be selectively applied as a part of Active Directory, and have many more options than the primitive NT4 policies. They are modified using gpedit.msc and can apply to groups of users instead of all users when in an AD environment. On a Samba (i.e. non-AD) network, it is possible to still use these settings as follows:

    All group policy settings for Windows 2000/XP reside in %SYSTEMROOT%\System32\GroupPolicy (hidden by default). The particular files in there are less important than the directory as a whole. What is important is that these policy files apply to ALL users who can read them. If you want them to apply to only certain users (say, NOT restricting C: drive access for your administrator - BE CAREFUL what you set), you can change the permissions on the files. Of course, if you are running FAT32 instead of NTFS, you won’t be able to modify the permissions as FAT lacks permission info, so the settings will apply to ALL users.

    Keep a backup copy of your GroupPolicy directory someplace (in case you lock yourself out), run gpedit.msc to edit the polcies, then drag and drop the GroupPolicy to wherever you’d like. You can apply this to any other XP/2000 machine by simply dropping this folder into %SYSTEMROOT%\System32.

    Going back to gpedit.msc…. Of particular interest is the “Exclude directories in roaming profile” setting that can be found under “User Configuration -> Administrative Templates -> System -> User Profiles”. By default this setting contains “Local Settings;Temporary Internet Files;History;Temp”.

    Simply add the folders you do not wish to be copied back and forth to this semicolon separated list. We use “Local Settings;Temporary Internet Files;History;Temp;My Documents;Desktop;Recent;Start Menu;Application Data”. Note that this change must be made on all clients that will be using roaming profiles.

  • Profile changes

    Next there are two changes that should be done to each user’s profile. The first is to move each of the directories that you have excluded from being copied back and forth out of the usual profile path.

    For example, on our network each user’s profile is stored in his home directory under the .settings/profile_Win2K directory (the 2K part of the path is legacy - it does contain the XP profile). So we created a .windows_settings directory in each user’s home and moved his Application Data, Desktop, Recent, Start Menu, and My Documents folders from .settings/profile_Win2K into this directory.

    Next we had to modify each user’s NTUSER.DAT file to point to the new paths (shared over the network) instead of the default path (%USERPROFILE%). This is where Petter’s utility was used.

    The keys that should be changed can be found in Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. Be sure to change the paths for each of the directories you have excluded in the Local Group Policy above. For example, here’s a registry export of the changes we make:

    REGEDIT4

[Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]
"AppData"="X:\.windows_settings\Application Data"
"Desktop"="X:\.windows_settings\Desktop"
"Programs"="X:\.windows_settings\Start Menu\Programs"
"Recent"="X:\.windows_settings\Recent"
"Start Menu"="X:\.windows_settings\Start Menu"
"Startup"="X:\.windows_settings\Start Menu\Programs\Startup"
"My Pictures"="X:\My Documents\My Pictures"
"Personal"="X:\My Documents"

    The above will modify existing user profiles. If you want new profiles to have these settings, you will need to modify the NTUSER.DAT in the C:\Documents and Settings\Default User folder on each client machine, changing the same registry keys. You could do this by copying NTUSER.DAT to a Linux box and using the chntpw utility on it and then copy it back, or you could use regedt32 and load the NTUSER.DAT hive underneath of the HKEY_USERS branch making your changes and then unloading the hive when you are done.

    Daniel Gillmor notes that you can also put the “Default User” profile on the network: If you’re using Samba as your PDC, you should create a fileshare called ‘netlogon’, and within that, create a directory called ‘Default User’ which is a copy of the desired default user information (including a copy of ntuser.dat, and other similar. For example (from a samba PDC I’m running):

    [dkg@ocelot Default User]$ pwd
/usr/local/samba/netlogon/Default User
[dkg@ocelot Default User]$ ls -la
total 552
drwx---rwx  11 root  unknown     374 Oct 15 15:13 .
drwxr-xr-x   6 root  wheel       204 Oct 15 15:13 ..
drwxr-xr-x   6 root  unknown     204 Mar  3  2003 Cookies
drwxr-xr-x   2 root  unknown      68 Mar  3  2003 Desktop
drwxr-xr-x   7 root  unknown     238 Mar  3  2003 Favorites
drwxr-xr-x   2 root  unknown      68 Mar  3  2003 NetHood
drwxr-xr-x   2 root  unknown      68 Mar  3  2003 PrintHood
drwxr-xr-x   5 root  unknown     170 Mar  3  2003 Recent
drwxr-xr-x   6 root  unknown     204 Mar  3  2003 SENDTO
drwxr-xr-x   3 root  unknown     102 Mar  3  2003 Start Menu
-rwxr--r--   1 root  unknown  282624 Mar  3  2003 ntuser.dat
[dkg@ocelot Default User]$

    If this share exists, and the ‘Default User’ folder exists, then the first login of a new account will pull its configuration from there. See also: http://isg.ee.ethz.ch/tools/realmen/det/skel.en.html

    Jeremy Nelson is building a Wiki of Samba and Profile related issues. You can find it here.

Results

It has worked pretty well for us so far through all our testing giving us big speedups, but the real test for how well it will work will happen when all the students come back in September. (UPDATE: Several people have asked how the system is working, now that school is back in swing. Short and sweet answer: It is working like a charm and we have not had any major problems with it.)

We did run into several small things to note about this setup:

  1. Office XP (possibly earlier versions too??) lags a bit when typing in a filename to save or open in the respective dialog boxes. The issue seems to be that Office XP opens the “Application Data/Microsoft/Office/Recent” folder and follows each of the links as you type in order to try to guess what you are trying to type. Network latency seems to be the cause of this slowdown. By cleaning out the Office XP recent files, this can be sped back up.

  2. Mozilla’s user profile data stored in “Application Data/Mozilla/registry.dat” references the profiles as if they were in %USERPROFILE%, which they no longer are. If you have only one Mozilla profile that you use, you can safely delete the registry.dat file and it will be reconstructed the next time you start Mozilla with the correct paths.

Credits

  • Adam Griffis and Chris Swiontek for doing research and debugging of registry changes, Group Policy settings, etc.
  • Petter Nordahl-Hagen for the chntpw utility for modifying registry hives from within Linux.
  • Jim Kreuziger for pointing out some things that were left out.
  • Daniel Gillmor for noting the central “Default User” folder stuff.
  • Dave MacCrimmon for pointing out that user profiles are stored in %USERPROFILE% - not necessarily C:\Documents and Settings\%USERNAME%.
  • Jeremy Nelson for additional comments about Group Policies.