Some of my users are very frustrated, because their login/logout times are reaching into the minute ranges. We have a few shift workers using the same machine, and invariably, the second shift has to sit around for literally 5-10 minutes while the previous user logs out, and the new user can log in. There is high network traffic at this time, so I assume its copying the user's profile back to the server and vice versa. This time wait goes away if I disable roaming profiles for the user, but then their stuff isn't being backed up because we don't back up each machine.

To solve this, I figured I'd just use a network share instead of a roaming profile. Simple right? In this question: Auto-mapping network drive when a user logs in, it looks like I found a solution, but no dice. Probably because I'm using Windows 7 on the desktop and Windows Server 2008 as the AD server.

Here's the case:

  • a) In AD, under the "profile" tab for the user, I've set the profile to load from a network share (e.g. \\nfs\profiles\david)
  • b) Also in the "profile" tab, I've set the "Home Folder" to "Connect:", and mapped drive H: to \\nfs\homes\david
  • c) I log in to the desktop, and drive H: is correctly mapped, but the user's home folder (and thus desktop, documents, etc.) is still stored on the local machine and copied with every login/logout.

What am I still missing?


The feature you're looking for is folder redirection. This feature, on it's own or in combination with roaming user profiles (I recommend using both) will allow you to keep the largest folders of the user's profiles on the server and speed up logon times.

I also recommend creating the folders and setting the permissions yourself on the destination folders. The OS default method seems buggy brain-damaged to me.


My issue with the built-in functionality that allows clients to create the folders is that I stronly prefer not to have a world-writable folder for such a critical purpose (redirected user folders) on my server computers. I'm not sure that Microsoft has ever cleaned up the idiotic "feature" where the client blocks NTFS permission inheritance when it creates the user's folder and applies permission to it, either. I want to be in control of my filesystem permissions, I want inheritance turned on throughout the entire folder hierarchy, and I don't want a world-writable folder laying around on my servers.

I generally redirect "My Documents", "Desktop", and "Application Data". I always disable the idiotic "Grant the user exclusive access..." functionality (since it screws up my NTFS permission inheritance hierarchy). I may do redirection based on group membership if I have multiple destination file server computers and want all my redirection handled in a single GPO... that's more of a GPO design concern than a Folder Redirection configuration issue.

"AppData" redirection has been somewhat problematic. I've had issues with Adobe Reader 9.0 versions and the current Apple iTunes 9.2 versions not working properly when the user has a redirected AppData folders. Still, with the huge proliferation of small files that get created there, leaving "AppData" in the user's roaming user profile isn't an option if you want short logon / logoff times.

Generally I wouldn't exclude any "normal" users from Folder Redirection. Administrative and service account context users would be excluded, typically by being located elsewhere in the OU hierarchy such that the GPO applying Folder Redirection settings doesn't apply. WMI filters aren't useful because Folder Redirection is a user setting, and WMI filters only apply to computers.

Slow links and disconnected computers are good candidates for Offline Files. If a user isn't ever going to be connected to the LAN with high speed I might be apt not to use Folder Redirection at all, but I don't have any situations where that's the case in my current Customer base so I haven't really thought about it. Offline Files works very well in Windows 7 and Windows Vista. It works acceptably in Windows XP if the user's redirected folders are under 2GB in size. Anything more than 2GB and it starts working poorly because of a frustrating signed 32-bit integer size limit on the amount of data that will be automatically cached by Offline Files.

  • Agreed, and while I do sometimes create destination folders manually, I've not experienced any issues letting the client create the destination folder automatically. Evan, I'm curious as to what the policies look like that you use for redirection (which exclusions, any WMI filters, etc). Are you able to share that? And what's your solution for folder redirection and roaming profiles for users on laptops that are occasionally connected to the network, but more frequently on a slow link or disconnected? What I'm doing now works, I'm just wondering if you've done the same as I have. – aNullValue Aug 7 '10 at 17:10
  • @Stemen: I dropped on an edit. – Evan Anderson Aug 8 '10 at 2:52
  • I created a new group policy object, and edited "user conf->policies->windows settings->folder redirection->Desktop". Changed the "Root Path" to a UNC path, used "Basic" setting... and nothing. I logged in as me, created a 1 Gb file on my desktop, logged out, and it sat there for 3 minutes while it copied the huge file to my roaming profile folder. There was a folder created in my unc "Root Path", but it was empty. – user46506 Aug 17 '10 at 21:58
  • @David Dombrowsky: The Application event log on the client computer should give you some details as to why Folder Redirection didn't like the folder you redirected the user's desktop to. Initially, I wonder if Windows had trouble setting the permissions on the subfolder it created under the "Root Path". As I said in my answer, I don't allow the Folder Redirection CSE to create folders on my server-- I pre-created them, set the permissions as I want them, and untick the box for the silly "Grant the user exclusive access..." "feature". – Evan Anderson Aug 17 '10 at 22:41
  • You can tell if your desktop has been successfully redirected w/o cycling thru logons / logoffs, too. Just make a file on the desktop and look at the "Properties" sheets. It'll tell you where the file really is. – Evan Anderson Aug 17 '10 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy