• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2154
  • Last Modified:

ICACLS.exe inconsistencies

On a Windows Server 2008 R2 system, we heavily use ICACLS.exe within a sizeable command-line batch file script for creating dedicated security groups, creating a specific folder tree, and assigning very specific NTFS permissions to numerous folders within the tree.

The first iteration of the script used XCACLS.vbs, which was very effective, but very slow.  Each use of XCACLS.vbs in the script could take anywhere from 0.25 seconds to more than 120 seconds to complete depending on network and server load factors at the time the script was run.  The script contains approximately 75 separate commands to set specific, granular ACL entries on individual folders.

When we upgraded to Windows Server 2008 R2, we discovered the hard way that XCACLS.vbs doesn't support the newer OS, so we revamped the script to use ICACLS.exe, which turned out to be far, FAR faster anyway.

However, we have come across some odd, inconsistent anomalies when using the script.  Every now and then, we'll discover that some ACLs were not changed after the script has completed.  We generally try to keep an eye on the script results to ensure that "Failed processing 1 files" doesnt appear, and we've confirmed that the results report successful processing even though some permissions are not set according to the scripting.

The biggest point here is that it is NOT consistent.  It correctly sets all of the specified permissions most of the time, and every now and then we find folders that are missing specified permissions.  We've gone through the scripting very carefully, and cannot cause the issue to occur when stepping through.

Is anyone aware of an issue with ICACLS.exe that may account for this?
Is it possible that the script may be processing so quickly that ICACLS actually misses a few steps along the way?
Is it possible that the script may be processing so quickly that the server cannot keep up with the changes and drops a few steps?
(These last two questions are hard to believe they might be true, but we're grasping at straws here...)

We're aware the scripting could be re-written using PowerShell, but the learning curve could be prohibitively steep.  Is there an alternative command-line utility to ICACLS.exe that might be more reliable?

Any information or suggestions would be greatly appreciated.
  • 3
1 Solution
Dimarc67Author Commented:
Completed some more testing, and discovered that the ICACLS results DO report the processing failures.  They were so early in the script results that they were missed before now.

The error is the standard "No mapping between account names and security IDs was done."  

This may narrow the question considerably.  Immediately prior to setting the folder permissions with ICACLS.exe, the script creates the dedicated security groups to add to the ACLs (using DSADD).  

Is it possible that the new groups may sometimes not be propagating fast enough to be found by the ICACLS commands attempting to assign them to the ACLs??
Dimarc67Author Commented:
Using ERRORLVEL result codes, I've confirmed with a "DSGET | Find" combination command that the new groups are immediately available for reference in Active Directory after they are created with DSADD.

ICACLS.exe does not seem to support ERRORLEVEL result codes, so I'll have to determine a manual test after each command to determine if it was successful, and to retry if it's not.

Any additional information or suggestions would be greatly appreciated.
Dimarc67Author Commented:
No direct error handling solution for ICACLS.exe could be identified.

Several seemingly unrelated updates were made to the batch scripting:
--cleaning up the resultant output text by redirecting all ICACLS.exe, DSADD, and DSMOD command output to 'nul'.
--adding folder existance confirmation ("if not exist") and security group existance confirmation ("dsget | find" with errorlevel checking) sub-routines, jumping out of the script if they don't exist.
--formatting echo'ed output for successful and unsuccessful operations.

Subsequent testing of the script could not reproduce the previously experienced inconsistencies.  While there is no apparent indicators, it may be subjectively attributed to network, server, or storage activity loads at the time the script was run.  Only time will tell.

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now