Quantcast
Channel: File Services and Storage forum
Viewing all articles
Browse latest Browse all 13565

Two USV issues: %username% & permissions

$
0
0

Hello all,

I recently-ish (~7 months) migrated our domain over from Roaming User Profiles (RUP) to RUP + Folder Redirection (USV).  Everything works fantastically, except two small issues. Warning: Long post ahead, but I try to cover all bases from the get-go.

Issue #1: %Username%

It seems that when copying an existing user with a configured roaming profile path (e.g. \\server\Users$\%username%\profile), the new user's profile path exactly matches the user it was copied from. This was not the behavior when using only RUP - it always changed the profile path to include the new user's name.

I have USV configured so that a user's redirected folders and roaming profiles are combined to one spot on the network for consolidation of information and ease of management. For example, each users redirected folders are set for "Create a folder for each user under the root path" to \\server\Users$\ and their roaming profile paths are \\server\Users$\%username%\profile. The \profile suffix is so that when the profile is created, it is placed at the same level as all the other redirected folders.

The interesting thing is that it appears the issue has something to do with the \profile suffix.  In creating some test users, if I take that \profile off the end of the path, the %username% variable works fine - even in the same \Users$ folder I normally use (so it isn't a permissions thing).

Issue #2: Permissions

When a user is first created or is migrated to USV, they have Full Control on their root folder and all subfolders. However, the entries are all set to "This folder only".  In normal operation when creating their own folders and files, they encounter no issues. Unfortunately, if data is copied/moved into their profile from another user (which happens frequently for various reasons - data recovery, profile migration, copying files from another account, etc), they do not have any rights to it.

The workaround is to make sure to go into the user's root folder after creation, tick off inheritance, change 'This folder only' to 'This folder, subfolders and files', and tick 'Replace all child object permissions...'. However, even with an internal KB, this is hard for most of my team to remember. I find I either need to go in after them to change these settings or, if I am unable to, we have seen some users able to log in but then get 'Access Denied' to everything in their profile (which, understandably, freaks them out).

Here are the relevant steps on how I set up a new Users$ share:

  1. Create folder -> Click Change Permissions -> Untick 'Include inheritable permissions...' -> clickAdd.
  2. Edit Users "Special" ACL and change Apply To: to "This folder only" and change Name to regional security group.
  3. Edit Users "Read & execute" ACL and changeApply To:"This folder only" and change Name to regional security group.
  4. Sharing tab -> Click Advanced Sharing -> Tick "Share this folder" and give it Users$.
  5. Permissions button -> Allow Full Control to Regional security group and Domain Admins.

I am sure this issue stems from how permissions on the Users$ share are configured, but I set it this way so that users couldn't get into each others' folders. I don't want to enable ABE as that would only be 'security by obscurity' - they could still get there if typing the path manually, and we have plenty of users savvy enough to do that. I have tried setting them up without the "This folder only" change, but they each get Full Control to all profiles. Is there a better way?

Conclusion

Obviously these aren't huge issues as they both have workarounds, but they do introduce two more avenues of complexity and human error which we have already suffered from more than once since switching over to USV.

I was hoping someone else had encountered these issue and knew of a fix aside from creating two entirely separate shares for RUP and Folder Redirection as that would increase complexity and reduce manageability.

Our domain functional level is Windows Server 2003 (we still have some older 2k3 DCs), but all file servers with this set are 2008 or 2008 R2. Most clients are running Win7, though we still have about 20 XPs floating around until March.

I look forward to and appreciate any input. Thank you very much!


Viewing all articles
Browse latest Browse all 13565

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>