Thursday, March 6, 2014

Exchange 2007 (SP3) - Public Folders - permissions - recurse parameter

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


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
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}

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.

No comments:

Post a Comment