SetAccessRule failing while in script, works otherwise - windows

Question

I'm trying to figure our why a call to Set-Acl in powershell failes.
The call is part of a larger script used in setting up an AD OU. The basic steps of that scripts are:
Create a new OU
Add a group to that OU
Create a folder on a file share.
Add permissions for the newly created group to that newly created folder.
Copy the content of a template folder to the newly folder.
Create a DFS folder to pointing to the new folder.
The script works fine except for a call to SetACL:
#Some initialization data. In reality, the exact values are generated using the script parameters.
$NewDataPath="\\server\share\folder\"
$NewGroupName="UserGroup_1234"
#The actual code from the original script
$Acl = Get-Acl $NewDataPath
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule($NewGroupName, "Modify", "ContainerInherit,ObjectInherit", "None", "Allow")
#exception happens on the following line
$Acl.SetAccessRule($Ar)
#whetever happens afterward works fine
Set-Acl -Path $NewDataPath $Acl
This raises the following exception:
Exception calling "SetAccessRule" with "1" argument(s): "Some or all
identity references could not be translated."
+ $Acl.SetAccessRule <<<< ($Ar)
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException
The really weird thing is that if I run each line manually, it works. I have moved the code to a separate function and calling it manually after the initial code fails (with the exact same parameter) works as well.
Even weirder: if I move the section of code that update the permissions AFTER I have copied data into it, it works.
It is as if the SetAccessRule method call (or perhaps the FileSystemAccessRule object) wasn't able to access the new data in AD, even though all other calls works fine and if a slight delay is introduce, it recovers.
While I was able to find a workaround, I'd really would like to understand what is happening here.

Answer 1

This seems to be a typical race-like condition when creating multiple new AD objects that depend on each other.
I haven't confirmed this, but I suspect that when you supply an account name as a string to the FileSystemAccessRule constructor, .NET uses the LSA Lookup Cache on your machine to resolve the name to a security identifier.
Since you literally just created the account on another machine (the DC) a few hundred milliseconds ago, the lookup cache fails to translate the name.
You can easily circumvent this by supplying the Security Identifier of the new account instead.
To get the SID, specify the -PassThru switch when you create the group, this will return the new object (including it's SID):
$NewGroupInstance = New-ADGroup -Name $NewGroupName -PassThru # -Path and so forth
# ...
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule($NewGroupInstance.SID, "Modify", "ContainerInherit,ObjectInherit", "None", "Allow")