Replacing permissions on Public Folder Trees

You wouldn’t expect that in 2020 we would still be trying to manage Public Folders in Exchange, especially given that people originally expected them to die a death nearly fourteen years ago, with Exchange 2007.

Unfortunately, they’re still around and as Exchange 2010 lives beyond the grave, with its life-support extended until October 2020 you, like many others, are trying to get rid of Public Folders or move them to modern Exchange or Office 365.

One common ask is to be able to quickly replace a set of Public Folder permissions on Exchange 2010. There are scripts from Microsoft to do this on Exchange 2013 and above, but not a quick and simple one for Exchange 2010. To help with this requirement for one of my customers, I’ve written a simple script that can be used to achieve this.

The ReplacePFPermissions script is a simple script that enables you to remove non-default permissions from a Public Folder and it’s sub-folders and add a new Public Folder permission – such as a group, or perhaps an admin account if you are removing general user access.

One common problem you may be trying to solve (and failing) is removing permissions that aren’t identified as problematic by the Source Side Validation scripts provided by Microsoft. For example, you might find some recently deleted users, or users who are not mailbox-enabled still have Public Folder permissions, as shown below:

I’ll cover a quicker way of performing a search and destroy for these type of issues in my next article on the subject, but if you want to perform a clean of a Public Folder tree and remove spurious permissions that should not be there, then using the ReplacePFPermissions script may help.

To use the script, download it from my GitHub. In the example below, I’m going to replace the existing permissions with a Mail-Enabled Security Group, called PFPGroup. I’ll give this group Owner permissions down the tree, starting from a folder called TopLevel.

The structure looks like this screenshot below, with each folder having a mix of different permissions added:

Before I replace the permissions, I will want to test the script to see which permissions will be removed. It is, obviously, crucial to validate what damage any script you run will perform in case you review the changes and find that it will cause you problems.

In the example below, I use the TestMode parameter with the script:

.\ReplacePFPermissions.ps1 -NewUser PFPGroup -FolderTree "\TopLevel" -AccessRights Owner -TestMode:$True

The output will show the “WhatIf” output from the Remove-PublicFolderClientPermission cmdlets that will be ran:

For safety’s sake I’ll also recommend running the Start-Transcript cmdlet to ensure you have a handy log of script output as well.

As I am reasonably happy with the above output, I’ll run the script again with the TestMode parameter removed:

.\ReplacePFPermissions.ps1 -NewUser PFPGroup -FolderTree "\TopLevel" -AccessRights Owner

You’ll see below a much simpler output – only errors will be shown, should one occur.

Examining the Public Folders in the EMC now will show that the PFPGroup has replaced all of the custom permissions:

You will note that I’ve chosen to leave any Anonymous and Default permissions intact.

If you want to remove those as well, then use the KeepDefaultAnon parameter and set it to $False, for example:

.\ReplacePFPermissions.ps1 -NewUser PFPGroup -FolderTree "\TopLevel" -AccessRights Owner -KeepDefaultAnon:$False

Using this parameter will remove all permissions before adding the new permission, and result in Default and Anonymous showing like this:

Hopefully this solves a problem you are having when you are attempting to clean up your public folders. Check out my other new article on tidying up permissions after using the Source Side Validation scripts from Microsoft to identify other issues.