Slow logins with roaming profiles

My recollection was that starting with Windows 2000 the roaming profile client would compare the dates / times of files in the server copy of the profile with the local copy and, if the local copy was up-to-date, it would not copy the server-side file back to the client. Finding documnetation from Microsoft of this behaviour has proven impossible. (Yet again, we have one of those situations where access to the Windows source code would put the matter to rest, but instead we're forced to poke at it with sticks and stones like cave men...)

My recollection was based on the story that prompted my behavior of always using Folder Redirection on the "Desktop" folder. At a Customer site, a user was saving several multi-gigabyte CAD drawings to their "Desktop", rather than in the appropriate folders on the server computer. The hard disk drive in their PC died, and my then-employer dispatched a technician to replace the hard disk drive and re-image the PC. I got a call because the replacement image was "freezing up" at the "Loading your personal settings..." dialog. I observed, using "Network Monitor" on the server computer, that files were being copied from the server to the client. A little more sniffing around uncoverd the 20GB+ of files in the user's server-side profile's "Desktop" folder that were copying down to the client. The technician was being impatient and kept rebooting the PC, causing the process to start over with the file that was partially copied on the prior attempt. Once we let everything copy the user could logon and logoff with no problems or delays.

So, with this story in mind, I just did a little mockup in a virtual machine using Windows Server 2003 R2 as the file server computer and Windows XP Professional SP3 as the client.

I logged-on to the VM with a user account who already had a roaming user profile to allow the profile to be cached by the client, then I logged-off. This caused a 12MB roaming user profile to be cached to the client.

I logged-on to the clent again, this time capturing the traffic between the client and the server with Wireshark (running on the server computer). I saw rougly 2,500 Ethernet frames go by during the logon. Under 1.5MB of traffic moved between the client and the server during this logon, though you'll recall the profile directory is over 12MB. This is a pretty good indication that a full copy isn't taking place on each logon (but I wanted more proof, as you'll see).

The behaviour I observed in the capture was a recursive traversal of the folders in the profile, starting with the root directory, using the "Firstfirst" API. After that traversal was complete, the client perfomed a folder-by-folder walk through the profile performing an "open" and then "query file info" on each folder.

Nowhere during this logon did I see the contents of the files in the profile actually traverse the wire (and, as I said, the entire conversation was under 1.5MB, whereas the data that makes up the profile is 12MB).

I dropped a 56MB file into the profile and logged-off. I verified that the file appeared on the server copy of the profile after the logoff completed on the client, then deleted the file from the cached copy on the client computer's hard disk drive (Via the "C$" share).

I logged-on to the client again while watching with Wireshark and observed a 60MB transfer between the client and the server during logon. I could see clearly in the capture where the client requested the contents of the 56MB file from the server.

I logged-off and logged-on again, this time leaving the locally cached 56MB file on the client alone. In that logon, the total transfer between the client and the server was again just under 1.5MB.

This seems to confirm my memory of the behavior, at least in Windows XP Professional SP3.

So, why are you seeing the long logon delays? Besides being "slowish" (I'd argue they're just "slow"), your WAN links are probably fairly latent (as compared to the local Ethernet). The recursive directory traversal I observed in the logon above took about 3 seconds to complete on a LAN. It would be a huge multiple of that on a WAN, even though very little data was actually crossing the wire. SMB sucks like a vacuum cleaner over latent links.

I suspect that if you "cleaned up" a user's profile of extraneous files in the "Application Data" folder, the "Cookies" folder, etc, you'd see a decrease in logon and logoff time. Unfortunately, junk tends to pile up there and it's difficult to keep in check.

Some ideas:

• Immidio Flex Profiles creates a ZIP file that contains all the user profile data and uploads that to the server computer. It would work better on latent links than the built-in profile replication engine. This toolkit used to be no-cost, but I believe it's now a for-pay product.

• If users don't move between off-site offices frequently you could put a "server" in each off-site location to be the "Roaming Profile Server" for those users who work in that office, and back it up remotely. You could use a Windows client PC in this role, so long as more than 10 users don't try to connect to it at once (and it doesn't get turned off). Alternatively, since you're already familiar with Samba you could put a low-end Linux machine out there hosting the roaming profiles in each office, and use something like rsync to copy the files back to the hub location for backup.

• If you want to gold-plate the solution you could put a Windows Server machine into each office, replicate the roaming profiles share with DFS-R, and users would be able to move freely between all the offices.

To get the best experience possible from roaming user profiles, it is important to read all the documentation and plan your implementation thoroughly. This section presents best practices for using roaming user profiles.

Turn off the fast logon enhancement

With the fast logon enhancement in Windows XP when users change from a local to a roaming profile, it will take two logons on each machine for profile changes to be registered. This is because the user always logs on with cached credentials; therefore it takes one logon for the network to notice that the user has become roaming and the second logon to apply these settings.

To ensure the best possible experience, enable the setting Always wait for the network at computer startup and logon, located at Computer Configuration\Administrative Templates\System\Logon.

Redirect the location of the My Documents Folder outside of the users Roaming Profile.

To decrease initial logon time to a new computer, it is recommended that you redirect the location of the My Documents folder outside of the users roaming profile. The best way to do this is with Folder Redirection. If you don't have Active Directory enabled, you can do this with a logon script or instruct the user to do so manually.

Let the system create profile folders for each user.

To ensure that Roaming user profiles work optimally, create only the root profile share on the server, and let the system create the folders for each user. If you must create folders for the users, ensure that you have the correct permissions set. For details on the required permissions see Security Considerations when Configuring Roaming User Profiles.

Don't use Offline Folders on Roaming Profile Shares.

Make sure that you turn off Offline Folders for shares where roaming user profiles are stored. If you do not turn off Offline Folders for a users profile, you may experience synchronization problems as both Offline Folders and Roaming Profiles try to synchronize the files in a users profile.

Windows XP does cache profiles. On login Windows XP will check the last write time of ntuser.dat, if the local cached copy is newer than the version in the roaming profile on the server it will just run off the local cached copy.

Here's a technote on it. You might want to check the ntuser.dat file in a users directory from one day to the next to see if the date/time changes on the file.

It might be different today but back in 2001 I got very specific advice from an MS guy to NOT use roaming profiles, with the primary reason being filesystem performance (loads of small files specifically). Folder redirection, application deployment, desktop lockdown, and living with the rest of the profile being different were advised to be preferable.

I'd also think that even a cached copy must be checked against the master, and that's always going to introduce some additional latency too.