Slow logins with roaming profiles

Question

We are running an ActiveDirectory environment with Windows 2008 as DC and Samba 3.3 as fileserver, using roaming profiles. Some of our offices are connected to HQ via slowish links (1/2 Mbit). Naturally this is not very fast but that was expected.

What I do not understand is, that if a user logs out (taking a long time to sync, as expected) and then logs in again the next day it also takes a long time to login. And that is what I don't understand. Shouldn't the sync recognize that nothing has changed rather quickly? Also: Is there any decent docu on how the synchronization is implemented?

---

EDIT: Thanks for all the help. In the end it turned out to be Sophos Antivirus scanning the remote profiles. One checked "Disable On-Access Scan for Remote Shares" checkbox later, everything is fast. (As fast as 1mbit will get. So it only takes 5 minutes to loging…)

Solution 1

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.

Solution 2

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.

Comments

[Zoredache]

I don't have any docs or links but I believe that that the roaming profile is not a sync and instead a full copy at login and logoff. Perhaps someone will be able to confirm that.

[voretaq7]

If it hasn't changed since the last time I was in a Windows environment Zoredache is correct: Roaming profiles do a full copy of the profile every time you log in/out. This can lead to some heinous delays if your users store large files in their profile-managed directories.

[Spence]

I have a vague memory of the profile reconciliation behaviour changing in Windows 2000, but I'm only find docs describing the new "merge" algorithm for logoff change merging (see technet.microsoft.com/en-us/library/cc961679.aspx for details). For kicks, I'm mocking-up the scenario in a VM right now just to see how it looks.

[John Gardeniers]

Try disabling the antivirus on-access scan from scanning network locations (i.e. Only scan the local drive), as that can introduce some serious performance issues.

[Spence]

That document references Windows NT 4.0. Significant changes to the profile merge behavior were implemented in Windows 2000, and it wouldn't surprise me if the behavior is different in Windows XP as compared to Windows NT 4.0.

[Spence]

The Cookies folder is, arguably, the biggest pain point. I run a logon script to trim the contents of the Cookies folder to the 25 most recent files and find that it helps matters somewhat. Once Application Data and My Documents are redirected out life is a lot better.

[Spence]

This answer is, at best, tangentially-related to the question. The only item of any value in the answer is the "Redirect the locaton of the My Documents Folder..." bit. The rest have nothing to do with the delay that the poster is experiencing.