An observation first: Every time you block inheritance you're cutting yourself off from future flexibility. I avoid blocking inheritance at all costs.
If you need users to be able to list the contents of the top-level "E:\Home Directories" folder, for example, consider the following permission:
- SYSTEM - Full Control - Applied to this folder, sub-folders, and files
- BUILTIN\Administrators - Full Control - Applied to this folder, sub-folders, and files
- BUILTIN\Authenticated Users - Read and Execute - Applied to this folder only
The last permission doesn't inherit down into the subfolders. At each subfolder, inheritance remains enabled and you simply specify the user with "Modify" or "Full Control" rights (depending on how you feel about users being able to set permissions inside their home directory). (Typically I set that last permission by adding "Authenticated Users" in the non-"Advanced" Security properties sheet, unchecking the "Read" and "Read and Execute" check boxes. I then proceed into the "Advanced" dialog and change the "Apply onto" setting for that ACE to "This folder only". That's about the easiest way, in terms of number of clicks, to set it.)
Then, your script becomes:
set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
I strongly suspect that the addition of the "Authenticated Users" permission I've described above w/ the inheritance set to "This folder only" will give you what you're looking for in functionality and will give you future flexibility if you find out that you have to set a permission that might need to inherit into all the user home directories in the future.
This is my SOP for user home directories, redirected "My Documents", "Desktop", etc folders, and for roaming user profile directories. It works great.
Edit
re: your comment about BUILTIN\Administrators access
I've had various arguments with people about my take on granting BUILTIN\Administrators access over the years, and my take is this:
It's easier to solve a certain class of user problems if you can get to their files. It's a pain to "take ownership" and can be quite slow if there are a large number of files present, too.
As you've seen with ICACLS, BUILTIN\Administrators can "assign" ownership (besides "taking" it) so there's no "security" added by not having the files accessible to BUILTIN\Administrators in the first place.
Unless you're using auditing (and sifting through a potentially huge number of false-positive entries) there won't be an audit trail when a BUILTIN\Administrators user takes ownership of files they shouldn't be accessing, copies them, and then returns the files back to their "proper" owner and permission.
In the Microsoft world, Encrypting filesystem (EFS) is meant to solve the problem of keeping unauthorized BUILTIN\Administrators access from happening. NTFS ACLs don't solve that problem. (Obviously, EFS isn't the only show in town. Encryption is the real answer to solving the "limit the network Administrator's access" problem no matter how you slice it.)
To my mind, not specifying BUILTIN\Administrators with access to user home directories (and, in fact, any folder) means that you're increasing the complexity and time needed to resolve issues while providing less than no real security ("less than none" because it imparts a false sense of security where there is none).
I've given up trying to win the argument with people by way of logic. It seems to be an emotional issue with some people. It's like the silly "Deny / Receive As" ACE that gets placed at the root of an Exchange organization to prevent certain privileged groups from opening users mailboxes. It offers no real security (since w/o auditing one could remove / re-apply the ACE as necessary), a false sense of security, and gets in the way when solving real problems.
Even if you don't like my argument about BUILTIN\Administrators having access you want to keep the inheritance hierarchy intact by using "This folder only" inheritance where appropriate. Blocking inheritance in permission hierarchies is a sure sign that something about the design is "broken" (inverted, etc).
Ended up achieving what I wanted with Setacl. I wrote the following script which ripped through the entire folder structure and files, and gave ownership to the local Administrators group, then went through again and added a full control ACE for our IT domain group. It did this without replacing or removing the existing permissions/ACEs (other than replacing the owner), and I didn't get any access denied errors:
setlocal
set logDir=%1
set targetDir=%2
set logFileName=%~n2
set logFileNameEnding=%3
SetACL.exe -on %targetDir% -ot file -actn setowner -ownr "n:S-1-5-32-544;s:y" -rec cont_obj -log "%logDir%\%logFileName%-TAKEOWN-%LogFileNameEnding%.txt" -silent
SetACL.exe -on %targetDir% -ot file -actn ace -ace "n:domain\group;p:full;s:n;m:set;w:dacl" -rec cont_obj -log "%logDir%\%logFileName%-ADD-DOMAIN-GROUP-%LogFileNameEnding%.txt" -silent
endlocal
Best Answer
I strongly suggest you find a utility called SetACL. It is much more powerful than ICACLS, plus the utility's website also provides a very good introduction to NTFS privileges.
(Sorry, I'm typing this on my smartphone, so I can't directly give you the site myself).