jbmurphy.com

In my previous post, I showed how to create a new ACL and apply it to a folder. Why apply it to the folder if the folder is already set correctly? I wrote the following function to compare the ACLs of a folder to a desired set of ACLs (either created by hand (lines 3-12) or copied from an existing folder (lines 12-15).

function JBMURPHY-PERMS-ArePermsCorrect {
        Param([parameter(Mandatory = $true)]$Path,
              [parameter(Mandatory = $true)]$CorrectACL,
              [switch]$ShowCorrect)

    $folderACLs=get-acl(get-item $Path)
    if ((compare-object $($folderACLs.access) $($CorrectACL.access) -property FileSystemRights,IdentityReference,InheritanceFlags,PropagationFlags).count -gt 0) {
    Write-host "$PATH is INCORRECT"
    return $false
    }
    else {
    if ($ShowCorrect.IsPresent){write-host "$PATH is correct"}
    return $true
    }
}

If the compare-object command returns nothing, then they are the same, if they are not the same then the items returned will be greater than 0, and the first part of the conditional will be used.

In my previous post, I used PowerShell to change the permissions of a top level folder. In that script, I took the folder in question and copied the inherited permissions to it, and then I tinkered it to be what I wanted. I wanted to do something similar, but I wanted a set of permission that differed from the parent. Basically I wanted the folder to have unique permissions. Below is the function to do that:

function JBMURPHY-PERMS-ClientsFolderReBase {
    Param([parameter(Mandatory = $true)]$Path)
    $correctACLs = New-Object System.Security.AccessControl.DirectorySecurity
    $correctACLs.SetAccessRuleProtection($true,$true)
    $Rule_Admin = New-Object Security.AccessControl.FileSystemAccessRule("BUILTIN\Administrators",@("FullControl"),"ContainerInherit, ObjectInherit","None","Allow")
    $Rule_System = New-Object Security.AccessControl.FileSystemAccessRule("NT AUTHORITY\SYSTEM",@("FullControl"),"ContainerInherit, ObjectInherit","None","Allow")
    $Rule_Users1 = New-Object Security.AccessControl.FileSystemAccessRule("BUILTIN\Users",@("ReadAndExecute", "Synchronize"),"None","None","Allow")
    $Rule_Users2 = New-Object Security.AccessControl.FileSystemAccessRule("BUILTIN\Users",@("Modify, Synchronize"),"ContainerInherit, ObjectInherit","InheritOnly","Allow")
    $correctACLs.AddAccessRule($Rule_Admin)
    $correctACLs.AddAccessRule($Rule_System)
    $correctACLs.AddAccessRule($Rule_Users1)
    $correctACLs.AddAccessRule($Rule_Users2)
    write-host "Changing $Path"
    set-acl $path $correctACLs
}

In line 3 I create a new ACl, and in line 4, I set the cal to not inherit parent permissions.

Lines 4-8 are the specific permissions I want to apply (they are addressing the same issue I described here)

Lines 9-12 add the new perms to the new ACL, and line 14 set the ACL of the folder to the new ACL.

A little different want o go about this, as I created an ACL from the start.

I just figured this out late last night. I was pulling my hair out. If you look at the following PowerShell code

($MyArray=1,2,3,4,5) | foreach-object {
write-host $_
if ($_ -eq 3 ){return}
}

You get a result of:
1
2
3
4
5

Next, if you look at this code (the only real difference being the lack of a pipe.)

foreach ($item in ($MyArray=1,2,3,4,5)) {
write-host $item
if ($item -eq 3 ){return}
}

You get:
1
2
3

That stumped me. Why would they not produce the same thing? Then I ran across this thread. The replier said

I think because ForEach-Object processes each item in the pipeline, but the foreach statement processes the collection as a whole.

This led me to this page, and specifically this quote clears it up for me (kinda):

 . . . [the object] it is sent into the pipeline and execution continues in the next section of the pipeline.  . . . the foreach alias gets executed and the object is run through the process script block of ForEach-Object.  Once the process script block completes, the object is discarded and the next object is [sent] . . .

In summary, last night I learned that when using a pipeline, the first item is passed to the script block, the script block is run, and then the next item is passed to the script block, and so on.

That sound correct? Can you come up with a better description?

I am working on a PowerShell wrapper script to run multiple commands on multiple machines. The first thing I wanted to do was to chop up a space or comma delimited argument. (If you make an argument mandatory, and the user does not provide it, PowerShell will prompt you for it – and when prompted you can use space delimited values).

I was going to use the split() function, but I did not know how to handle “multiple spaces”. For example:

("123  4 5678").Split() = 
123
 
 
4

5678"

I would end up with “empty” array members. I found this post, and they guy used “| where-object {$_ -ne ”“}” to filter out the empty values. But then I stumbled upon a better way to do it, using the built in “StringSplitOptions” of  RemoveEmptyEntries.

("123  4 5678").split(" ",[StringSplitOptions]'RemoveEmptyEntries')

would result in:

123
4
5678

If you don’t know if you are going to have space or comma delimited then I used:

$Argument.split(" ",[StringSplitOptions]'RemoveEmptyEntries') | foreach {
$_.split(",",[StringSplitOptions]'RemoveEmptyEntries')}