I was working with a user who wanted to rearrange public folders, moving some and deleting others as needed. He could do neither. I had not worked with public folders for a while, and even then, mostly for practice (certification exams), so it took me a while to solve the problem. This is what I did...
First, I checked his permissions:
[PS] C:\>Get-PublicFolderClientPermission -id "\Sales Email" -user jsmith | fl
Identity : \Sales Email
User : mynet.lan/staff/John Smith
AccessRights : {PublishingEditor}
Note the syntax:
- We can abbreviate -identity with -id or simply omit this parameter, since it is positional.
- The name of the folder, in quotes, must be preceded by a backslash.
Note: for confidentiality, I am replacing the real names with fictitious names.
I thought that the problem could be resolved by granting him "Owner" permissions.
[PS] C:\>Get-PublicFolder "\Sales Email" | Add-PublicFolderClientPermission -user jsmith -AccessRights Owner
First obstacle for this solution:
Add-PublicFolderClientPermission : The user,mynet.lan/staff/John Smith , already has some of the permissions (ReadItems, CreateItems, [...]) specified to be added on the public folder \Sales Email. You cannot add a right that the user already has.
The current permission for mynet.lan/staff/John Smith is "ReadItems, CreateItems, EditOwnedItems, DeleteOwnedItems, EditAllItems, DeleteAllItems, CreateSubfolders, FolderOwner, FolderContact, FolderVisible".
After some unsuccessful attempts, I concluded that the best solution would be to remove the current permissions ("Publishing Editor") and then add the desired permissions ("Owner").
Of course, I do this after communicating with the user so I do not remove their permissions exactly when they might be working with the folders.
Here are the commands to remove permissions:
[PS] C:\>Get-PublicFolderClientPermission -id "\Sales Email" -user jsmith | Remove-PublicFolderClientPermission
There is a confirmation prompt and I confirm the operation.
Of course, this leaves the user in a worse situation than before, since they now have no permissions at all. We need to assign the new permissions immediately after, so it's a good idea to have our commands ready.
[PS] C:\>Add-PublicFolderClientPermission -id "\Sales Email" -user jsmith -AccessRights Owner
I verify the new permissions:
[PS] C:\>Get-PublicFolderClientPermission -id "\Sales Email" -user jsmith | fl identity,user,AccessRights
Identity : \Sales Email
User : mynet.lan/staff/John Smith
AccessRights : {Owner}
That should do the trick... or so I think.
Consulting the user, I learn that he can still not move and delete certain folders.
I suspect that public subfolders, unlike folders in the Windows file system, do not automatically inherit the permissions of their parent folder.
I run the "Get-PublicFolderClientPermission" on some of these subfolders and see that the user also has Owner permissions. But there are quite a few subfolders and it is possible he was granted Owner permissions to some subfolders and not to others.
I want a fresh start. But... how can I grant the user "Owner" permissions on all these subfolders if, indeed, permissions are not inherited?
This is where I use the -recurse parameter... with some effort.
I first try this:
[PS] C:\>Add-PublicFolderClientPermission "\Sales Email" -user jsmith -AccessRights Owner -recurse
Error:
Add-PublicFolderClientPermission : A parameter cannot be found that matches parameter name 'recurse'.
What's the problem?
Well, there is no -recurse parameter for the "Add-PublicFolderClientPermission" cmdlet:
[PS] C:\>get-command Add-PublicFolderClientPermission | fl
Name : Add-PublicFolderClientPermission
CommandType : Cmdlet
Definition : Add-PublicFolderClientPermission [-Identity] <PublicFolderIdParameter> -User
<PublicFolderUserIdParameter> -AccessRights <Collection`1> [-Server <ServerIdParameter>] [-DomainController <Fqdn>] [-Verbose] [-Debug] [-ErrorAction <ActionPreference>] [-WarningAction <ActionPreference>] [-ErrorVariable <String>] [-WarningVariable <String>] [-OutVariable <String>] [-OutBuffer <Int32>] [-WhatIf] [-Confirm]
On the other hand, the cmdlet get-publicfolder does have such a parameter:
[PS] C:\>get-command get-publicfolder | fl
Name : Get-PublicFolder
CommandType : Cmdlet
[snip]
Get-PublicFolder [[-Identity] <PublicFolderIdParameter>] -Recurse [-ResultSize <Unlimited`1>] [-Server <ServerIdParameter>] [-DomainController <Fqdn>] [-Verbose] [-Debug] [-ErrorAction><ActionPreference>] [-WarningAction<ActionPreference>] [-ErrorVariable <String>] [-WarningVariable <String>] [-OutVariable <String>] [-OutBuffer<Int32>]
So let's try this:
[PS] C:\>Get-PublicFolder "\Sales Email" -recurse | Get-PublicFolderClientPermission -user jsmith | Remove-PublicFolderClientPermission
I confirm the operation (I've edited out the verbiage here) and the permission changes on the folder and each of the subfolders displays on the screen:
Identity User AccessRights
-------- ---- ------------
\Sales Email mynet.lan/staff/John Smith {Owner}
\Sales Email\2005 Email mynet.lan/staff/John Smith {Owner}
[snip]
This solved the problem... for the most part. There were still some subfolders that, for some strange reason, could not be moved. For those, I created comparable subfolders in the target location, copied the content (emails) from the old to the new location, and then, after confirming with the user, deleted the original subfolders.
Thank you for reading the article about Exchange 2007 (SP3) - Public Folders - permissions - recurse parameter on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.