Remove-PWFolderSecurity Not working to remove user from Project Security

Franklin, can you do what you are attempting via ProjectWise Explorer and ProjectWise Administrator?  i.e. can you do what you want manually?  You may need to modify the membership of ProjectWise Groups or User Lists to accomplish what I think you are attempting to do, i.e. remove access by specific ProjectWise users. 

You also need to account for when security is inherited and when it is explicitly applied to a folder, as well as when it is applied via "Object", in this case "folder", or via "Workflow", which can be the workflow itself or the state the folder (or in the case of a document, the contents of the folder).  And for "Workflow" based security, it can be "global", i.e. the security is assigned globally via ProjectWise Administrator, or for the specific folder.  

When I used to teach the ProjectWise Admin and User classes, I would make a point of illustrating that the "Real" security show in the properties dialog box of a folder or document wasn't "real" at all!  It is actually the result of the application of the real security which is shown by the other two drop down values in the dialog box!

"Real" is the combination of the various security types:

So, "Real" is the effective security, and it can be on the folder itself, or inherited from its parent folder or farther up the folder tree, including from other objects such as the environment (yes, you can apply security to an environment!).

Some screenshots of the specifics of a folder's security where this "isn't working" would help.

Here's what I mean.  In the following screenshots, "Bob" has been given only Read access to a folder explicitly, but Bob is also a member of a group which as more access than just Read, and Bob is also a member of a User list which also gives Bob the same access as the Group does.  The result is that if you were to remove just the access granted explicitly to Bob, Bob would still have the access granted via the Group and User List that Bob is a member of.

And noticed that these security "settings" are not inherited, but are actually "on" the folder itself.

If you haven't done so already, I would encourage you to take advantage of Brian Flaherty's excellent Blog site where he often shows how to use PowerShell to do many of the more common tasks such as dealing with changing security.  Here's a link to one of his postings, but you might want to search for more posts about security.  https://powerwisescripting.blog/2018/07/31/update-projectwise-folder-security/ 

Many users export the security settings for a folder or set of folders into a spreadsheet, then edit the spreadsheet, and then import those settings.

I hope that this helps you find the reason why your script isn't doing what you think it should be doing.  If not, please post more specifics.

Franklin, can you do what you are attempting via ProjectWise Explorer and ProjectWise Administrator?  i.e. can you do what you want manually?  You may need to modify the membership of ProjectWise Groups or User Lists to accomplish what I think you are attempting to do, i.e. remove access by specific ProjectWise users. 

You also need to account for when security is inherited and when it is explicitly applied to a folder, as well as when it is applied via "Object", in this case "folder", or via "Workflow", which can be the workflow itself or the state the folder (or in the case of a document, the contents of the folder).  And for "Workflow" based security, it can be "global", i.e. the security is assigned globally via ProjectWise Administrator, or for the specific folder.  

When I used to teach the ProjectWise Admin and User classes, I would make a point of illustrating that the "Real" security show in the properties dialog box of a folder or document wasn't "real" at all!  It is actually the result of the application of the real security which is shown by the other two drop down values in the dialog box!

"Real" is the combination of the various security types:

So, "Real" is the effective security, and it can be on the folder itself, or inherited from its parent folder or farther up the folder tree, including from other objects such as the environment (yes, you can apply security to an environment!).

Some screenshots of the specifics of a folder's security where this "isn't working" would help.

Here's what I mean.  In the following screenshots, "Bob" has been given only Read access to a folder explicitly, but Bob is also a member of a group which as more access than just Read, and Bob is also a member of a User list which also gives Bob the same access as the Group does.  The result is that if you were to remove just the access granted explicitly to Bob, Bob would still have the access granted via the Group and User List that Bob is a member of.

And noticed that these security "settings" are not inherited, but are actually "on" the folder itself.

If you haven't done so already, I would encourage you to take advantage of Brian Flaherty's excellent Blog site where he often shows how to use PowerShell to do many of the more common tasks such as dealing with changing security.  Here's a link to one of his postings, but you might want to search for more posts about security.  https://powerwisescripting.blog/2018/07/31/update-projectwise-folder-security/ 

Many users export the security settings for a folder or set of folders into a spreadsheet, then edit the spreadsheet, and then import those settings.

I hope that this helps you find the reason why your script isn't doing what you think it should be doing.  If not, please post more specifics.