Issues With New-ADGroup, Set-ACL and Network Folders - powershell

Question

I'm playing with some PowerShell code to dynamically generate AD security groups and then apply them to folders on a network share, but having issues with resolving the newly created group.
Consider this:
import-module activedirectory
for ($i = 0; $i -lt 10; $i++) {
$group = New-ADGroup -Path "OU=Groups,OU=Department,DC=Domain,DC=Network" -Name "z-test-group-$i" -GroupScope DomainLocal -GroupCategory Security -PassThru
$acl = Get-Acl C:\Temp
$permission = $group.SID,"FullControl","Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
$acl.SetAccessRule($accessRule)
$acl | Set-Acl C:\Temp
}
Which works fine.
However, if I change the folder to a network folder, such as G:\Temp, or \\domain.network\DFS\GroupShare\Temp, I get a 'Method failed with unexpected error code 1337'.
I tired using SetACL.exe and received a similar error:
C:\Temp\SetACL.exe -on "\\domani.network\dfs\GroupShare\Temp" -ot file -actn ace -ace "n:$GroupSID;p:full;s:y"
SetACL finished with error(s):
SetACL error message: The call to SetNamedSecurityInfo () failed
Operating system error message: The security ID structure is invalid.
INFORMATION: Processing ACL of: <\\?\UNC\domain.network\dfs\GroupShare\Temp>
If I wait say 10 to 20 seconds, and run the Set-ACL (or SetACL.exe) portion of the code again, it completes successfully.
At first I thought this was related directly to the domain controllers (4 of them which are a mix of 2003 and 2008 R2), but the fact that it worked fine on local folders was intriguing (and annoying).
I did a Wireshark trace during the execution of the code on a local folder and then a network folder. The main difference is when trying to apply the ACLs to the network folder I see LDAP lookups and (amongst other things) the following SMB response:
NT Trans Response, FID: 0x0040, NT SET SECURITY DESC, Error: STATUS_INVALID_SID
Which I assume is what causes my Set-ACL command to fail.
The underlying network filesystem is EMC Celerra 6.0.xx. I am very unfamiliar with this technology, however from what I understand it holds some kind of SID cache which would explain the above error (it doesn't yet know of the new group even though AD does).
So I guess there are two questions:
Is there any way around this (PowerShell/C# ect) that doesn't
involve sleeping/waiting? IE, set the ACL even though the SID is
invalid?
If EMC Celerra is the issue (I assume it is), is there any
way I can force it to update its 'SID cache' or whatever it may be?
I have read various articles about this issue, but none seem to have an effective resolution (or work for me).
Thanks for your help.
Rhys.

Answer 1

If the issue is just the delay involved in waiting for the cache to update blocking other work the script needs to be doing you could ship that off to a background job and let your main script go on to other things.

Answer 2

Figured it out!
Modified the acl.mappingErrorAction on our EMC Celerra NAS.
Was set to 0, updated it to 1.
server_param server_2 -facility cifs -modify acl.mappingErrorAction -value 1
Now we have no issues in setting the newly created security group into the ACLs for the folder on a network share (no delays).
Info: acl.mappingErrorAction
Defines the rules for unknown mapping between security, user, and group identifiers (SID/UID/GID) on ACL settings.
Two kinds of errors might occur:
The SID set in the ACL is unknown to the domain controllers being used.
The username is not yet mapped to a UID/GID.
The bit list consists of four binary bits (bits 0 through 3, right to left). Each bit is 1 when set; otherwise 0.
Bit 0 (0001 or +1): Store unknown SID.
Bit 1 (0010 or +2): Store SID with no UNIX mapping.
Bit 2 (0100 or +4): Enable debug traces.
Bit 3 (1000 or +8): Do lookup only in cache (secmap or global SID cache or per connection SID cache).
Values: 0 – 15
Default: 0
Seems obvious enough now that I understand more about the underlying CIFS/ACL settings on the NAS then I ever wanted to know.
Rhys.