• State Not Answered
  • Replies 6 replies
  • Subscribers 64 subscribers
  • Views 2862 views
  • Users 0 members are here

Update-PWFolderSecurity replaces all existing security

Mohammad Masud
Offline

Hello scripting guy!

Hope this finds you well. 

I noticed, "Update-PWFolderSecurity" replaces all existing security groups in a folder instead of updating/adding just the one defined in the cmdlet run. For example, if a folder "Test" had three groups "grp-1", "grp-2" and "grp-3" in folder security, and all had "create subfolder" rights, then the following replaces all groups with "grp-1" with read rights, and erasing all the previous groups in the process.

Update-PWFolderSecurity -InputFolder Test -MemberType g -MemberName "grp-1" -MemberAccess 'r' -FolderSecurity

What I really wanted was the folder to have grp-1 updated to have read permission only and keep grp-2 and grp-3 to have permissions the same as before.

Any suggestion?

Thanks,
Mohammad

Parents
  • 0 Offline

    Were the original access control entries being inherited? If yes, you would need to include the -IncludeInheritance switch parameter to maintain those entries.

  • 0 Offline in reply to Brian Flaherty

    Thanks Brian. I think that's what it was. 

    Can entries be a mix of inherited and not inherited? Or it is always either 'inherited' or 'none'? Do all entries change to 'none' once an entry's security is updated? 


    So if I only want to update a single entry, the inheritance of which is unknown, should I include -includeInheritance switch regardless? or I should evaluate if the Inheriting_From property, and use the switch if it results true?

    Thanks in advance for your help.

  • 0 Offline in reply to Mohammad Masud

    Inheritance is all or none. Once an access control entry is added to a folder or document security, you ONLY have explicit access control entries.  You can use the Get-PWFolderAccess to get a list of what access control is applied to a folder. If nothing is returned, it is not inheriting any access control and not is explicitly applied.  Otherwise, the returned access control objects will indicate if it is inherited.

    Example: Get-PWFolderSecurity -InputFolder ( Show-PWFolderBrowserDialog ) -Verbose

  • 0 Offline in reply to Brian Flaherty

    Thanks! The Show* cmdlets are really very useful, and I was not aware of them. I can now convert the folder paths received from Get-PWFolders object array to  array of strings, and feed them to Show-PWFolderBrowserDialog's switch parameter -InitialFolderPath.

    $path = Get-PWFolders -FolderName "Some Projects" | Select FullPath | foreach {"$($_.FullPath)"}  
foreach($p in $path) { Show-PWFolderBrowserDialog -InitialFolderPath $p }


    At that point, I can change the displayed folders' permissions manually by going to each folder's property. However, it would be even nicer, if it had the option to default to folder properties, and folder/project security tab. Or is there something that can already do that? 

    I am forced to choose a manual option here, because the Update-PWFolderSecurity is not really updating securities of an existing member for me (with JustOne and Slow options). See the code below:

    Get-PWFolders -FolderPath $fpath -JustOne -Slow | Update-PWFolderSecurity -MemberType "userlist" -MemberName $ul -MemberAccess “r”, “w”, “d", "c", "cp" -FolderSecurity -IncludeInheritance | Out-Null


    Instead, I have to remove the existing member security (Remove-PWFolderSecurity) and then push the same member back with updates through the cmdlet Update-PWFolderSecurity. Do you see any problem in this approach? Theoretically, since the folder is selected with JustOne, it should not have any impact in other sub-folders, except that when the parent member is removed, that member will be removed from the child folders that have inheritance. Now, that can be a problem, because I don't want the child folders to have elevated rights once that member with elevated rights is pushed back in the parent folder. How can I remedy this?

    $path = Get-PWFolders -FolderName $FolderName | Select FullPath | foreach {"$($_.FullPath)"}
Get-PWFolders -FolderPath $fpath -JustOne -Slow | Remove-PWFolderSecurity -MemberType ul -MemberName $ul | Out-Null
Get-PWFolders -FolderPath $fpath -JustOne -Slow | Update-PWFolderSecurity -MemberType "userlist" -MemberName $ul -MemberAccess “r”, “w”, “d", "c", "cp" -FolderSecurity -IncludeInheritance | Out-Null

Reply
  • 0 Offline in reply to Brian Flaherty

    Thanks! The Show* cmdlets are really very useful, and I was not aware of them. I can now convert the folder paths received from Get-PWFolders object array to  array of strings, and feed them to Show-PWFolderBrowserDialog's switch parameter -InitialFolderPath.

    $path = Get-PWFolders -FolderName "Some Projects" | Select FullPath | foreach {"$($_.FullPath)"}  
foreach($p in $path) { Show-PWFolderBrowserDialog -InitialFolderPath $p }


    At that point, I can change the displayed folders' permissions manually by going to each folder's property. However, it would be even nicer, if it had the option to default to folder properties, and folder/project security tab. Or is there something that can already do that? 

    I am forced to choose a manual option here, because the Update-PWFolderSecurity is not really updating securities of an existing member for me (with JustOne and Slow options). See the code below:

    Get-PWFolders -FolderPath $fpath -JustOne -Slow | Update-PWFolderSecurity -MemberType "userlist" -MemberName $ul -MemberAccess “r”, “w”, “d", "c", "cp" -FolderSecurity -IncludeInheritance | Out-Null


    Instead, I have to remove the existing member security (Remove-PWFolderSecurity) and then push the same member back with updates through the cmdlet Update-PWFolderSecurity. Do you see any problem in this approach? Theoretically, since the folder is selected with JustOne, it should not have any impact in other sub-folders, except that when the parent member is removed, that member will be removed from the child folders that have inheritance. Now, that can be a problem, because I don't want the child folders to have elevated rights once that member with elevated rights is pushed back in the parent folder. How can I remedy this?

    $path = Get-PWFolders -FolderName $FolderName | Select FullPath | foreach {"$($_.FullPath)"}
Get-PWFolders -FolderPath $fpath -JustOne -Slow | Remove-PWFolderSecurity -MemberType ul -MemberName $ul | Out-Null
Get-PWFolders -FolderPath $fpath -JustOne -Slow | Update-PWFolderSecurity -MemberType "userlist" -MemberName $ul -MemberAccess “r”, “w”, “d", "c", "cp" -FolderSecurity -IncludeInheritance | Out-Null

Children
No Data

Communities
Support and Services
Training and Learning
Social Media