TS/RDS User Home Directory policy Explained
Here is a nice write up on Setting Home Directories via group policy by Jacques Bensimon.
Since I’ve had to deal with this before, I thought I’d review two items related to setting a Home Directory Root path via group policy for TS/RDS/XA servers. This policy is especially useful in the common situation of a farm that has servers in multiple offices but in which users occasionally/frequently need to log on to servers *not* in their home office (where their normal home directory resides) – if the home directories are not on a DFS share replicated to all the possible logon locations (probably the best case scenario), this policy can be used (obviously with a different local root path applied to each server location) to at least ensure that users will not suffer the performance issues associated with having a non-local home directory (especially when some profile folders are being redirected to the home directory). Of course, this implies that users will have different home directories (with different, unsynchronized contents) at each location to which they log on, but that is often acceptable since the apps they run off remote servers are typically different from those they run off their local servers. For example, many law firms have XenApp servers in each of their offices for use by local users when running most apps (MS Office, document management, etc.) but require users to log on to headquarter servers to make their time entries or to access other in-house database apps that would perform poorly over the WAN.
A. Assuming you want users in any given office to use their existing local home directory (the one defined in their AD account) when logging on to the TS/RDS/XA servers in their local office (and why wouldn’t you?), you’ll want to be aware of the sequence that this policy appears to follow to locate (or create) a user’s home directory under the specified root folder [Side note: you’re pretty much screwed if the existing user home directories in an office aren’t all at a single network location or if their names don’t match either %UserName% or %UserName%.%DomainName%. In either scenario, unless you can reconfigure the home directory environment, at least some users are going to wind up with new separate TS home directories if you use the group policy in question]
(1) If a folder named %UserName%.%DomainName% already exists under the specified root *and* the user has Full Control permissions to it, then that folder is used as the home directory.
(2) Otherwise, if a folder named %UserName% exists under the specified root *and* the user has Full Control permissions to it, then that folder is used as the home directory.
(3) If neither (1) nor (2) apply (and %UserName%.%DomainName% does not already exist), then %UserName%.%DomainName% is created (with Full Control given to the user) and used as the home directory.
(4) If %UserName%.%DomainName% exists *but* the user doesn’t have Full Control permissions to it (the last remaining possibility), then the policy doesn’t work at all and the user presumably doesn’t get a home directory (or does (s)he? Might the system fall back to whatever is specified in the user’s AD account? I didn’t test this last possibility. Anybody?)
So, bottom line, if users already have a home directory named %UserName% at the location in question *and* they have Full Control permissions to it (pretty much the case in most places), then you need not fear that a separate new %UserName%.%DomainName% will be created and used (though as you can see the system looks for that first). The other takeaway is that if a home directory is created as a result of this policy, then it will always be named %UserName%.%DomainName% — I can find no way to force the auto-creation of a plain %UserName% home directory via this policy (this should definitely be a new policy option – not many environments have to deal with multiple domains and the possibility of duplicate usernames). The only way around the “.%DomainName%” appendage is to pre-create all the home directories, even for the remote users. Or, come to think of it, this may not be a bad way to distinguish the home directories of local users vs. remote users: those with the added .DOMAIN were auto-created as a result of the policy and therefore belong to remote users.
B. Now, what if scenario (3) above occurs? i.e. a home directory has to be auto-created. What sort of permissions are required on the specified root location in order for the folder auto-creation to succeed? Well, as far as I can tell (and quite inexplicably), the folder creation attempt occurs in the security context of the *user*, so (s)he’d better have the right permissions to the root folder. Basically, anybody has to be able to enumerate and create folders under the root location and have Full Control over the created folder. After a little experimentation, this appears to be a sufficient permission set you need to grant on the root folder only to get the desired result without allowing everybody access to everybody else’s home directories (you’ll obviously need to go to the Advanced permissions dialog to get this done):
· Authenticated Users (with option “This Folder Only”)
– Traverse Folder
– List Folder
– Read Attributes / Read Extended Attributes
– Create Folder
– Read Permissions
· CREATOR OWNER (with option “Subfolders and Files Only”)
– Full Control
Of course, you’ll also already have in there the usual complement of Full Control entries for Administrators, SYSTEM, and whatever else is typical in the particular environment. [Be careful when adding permission entries to the root folder: you don’t want to see users lose their existing home directory permissions, so stay away from that “Replace all child object permissions …” option!]
