Contrary to some documentation out there in the internet ethers (how great icacls is compared to its predecessor, cacls), icacls has a serious flaw in bulk processing on server 2008 r2. As a followup to a post I wrote a year ago , I discovered that icacls does not set permissions properly when scripting acl’s in bulk.  Here’s my scenario:

Last July I changed employers, and one of my tasks in the past year was to deploy a new file server to replace a very badly configured, poorly deployed virtual machine file server. In addition, I discovered five different naming conventions were used when previous accounts were created in Active Directory. So, to get to a place where I can also prepare for an Exchange migration, I had a lot of account clean up.

Step one was to establish a new naming convention. What’s worked well in the past is firtname.lastname, so obviously home folders would be named identically. When I ran my original cacls script, server 2008 r2 offered me a wonderful alert: “cacls is now deprecated, please use icacls”. Odd, I remember running cacls on server 2008, without issue. R2 is full of surprises 😉

I am of the firm belief that giving users FULL access to their home folders is a really, really bad thing. I have learned over the years that 1) folks out there don’t understand why “Administrator” (or domain admins) has access to their private data in their home folder and 2) when given the power to set permissions themselves, they often remove the Administrator (or group) from their folder, wreaking havoc on backups etc. Anyway, I set MODIFY perms for all home folders for end users…

So, it turns out that a simple:

ICACLS.exe  /GRANT MyDomainuser:M /GRANT MyDomainDomain Admins:F

won’t work on SOME folders. Digging in a bit, I noticed I needed the /grant:r , with the “r” meaning to “replace” the permissions if the ACL is already set for that particular user SID. Great, I thought. And off I went, only to discover that the /grant:r does not replace the ACL as advertised. This really baffled me for a bit and after an early morning awakening (yeah, I dream about this stuff sometimes), I had an epiphany.

In Checking the standard security tab I saw that a user still had FULL access, indicating the script did not work. But when clicking on the advanced button, there it was…the user also had a separate ACL with MODIFY access. So, to make the process work correctly, I had to break it into two separate scripts, one to remove all ACL’s assigned to the user, then add the ACL back with the correct perms. Obviously, running the below scripts should be done OFF hours, as the first one removes ALL access for users to their home folders.

Script 1: For /D %%I in (*) DO ICACLS.exe %%I /remove MYDOMAIN%%I

Script 2: For /D %%I in (*) DO ICACLS.exe %%I /GRANT:r MYDOMAIN%%I:(CI)(OI)M  /GRANT:r MYDOMAINDomain Admins:(CI)(OI)F

Now, I am not sure if it was my mistake in the first place when I ran a simple /GRANT or if ICACLS just doesn’t remove the ACL’s on Server 2008 R2 (as purported), but the above is what worked for me. Hope this helps someone else out there when it comes to the inconsistent processing of ICACLS.

Leave a Reply

Your email address will not be published. Required fields are marked *