Modern Public Folders: Part 1

Over the past decade of working with dozen of Exchange environments, I can say that Public Folders are that one part of Exchange that most admins wish weren’t there. Some of you newer admins or have had the benefit of being in an environment where Public Folders were underutilized likely can’t relate with these feelings. But those of us who have been working in these older environments have a hierarchy with hundred- of-thousands of folders.

Legacy Public Folders

Long ago, probably before most people in the Internet were born, Public Folders were meant to fill a gap that allowed groups to share data and information. Remember this is long before Google Drive, SharePoint and the other dozens of collaborative tools that didn’t exist.

Exchange 2010 and prior, Public Folders where hosted on their own separate unique databases. However, the databases weren’t clustered. Instead public folders where synced accrossed databases using PF replication. So the advantage to this method is that you can choose which folders are replicated to which databases. If you wanted to geo-locate data, you could force data to specific databases/servers.

The Cloud Killed Legacy Public Folders

Around the time of Exchange 2007 and 2010, there where rumors spreading about Microsoft killing off Public Folders. Why? Well there was a time that Microsoft was encouraging organizations to move their Public Folder infrastructures to SharePoint. When Microsoft realized that organizations weren’t adopting this strategy they were faced with an issue. See Microsoft wanted to encourage people to start using it’s new cloud based Exchange environments, but it didn’t want to bring Legacy Public Folders to the cloud.

Modern Public Folders

So out of necessity the Modern Public Folders where created started in Exchange 2013. So what is different?

There are no longer any Public Folder Databases.

That’s right, no Public Folder Databases. So where do my public folders go? Well Microsoft decided to create something called a Public Folder Mailbox. These mailboxes can be hosted on regular mailbox databases. Which means, the data can now be protected through Database Availability Groups.

There are two kinds of Public folder mailboxes, Primary and Secondary Hierarchy Mailboxes. There is one and only one Primary Hirearchy Mailbox. The purpose of this mailbox is to maintain the only writable copy of the Public Folder structure and permissions. Every other Public Folder Mailbox is a Secondary  Mailbox. These maintain read-only copies of the hierarchy.

Watch for the next post for strategies on working with large Modern Public Folders.

PF Permissions

To be honest, I’ve never been a big fan of Public Folders (PFs). Actually, now that I think of it, I’ve never met an Exchange Administrator who doesn’t have a distaste for PFs. However, they are one of those things that many older and larger organizations started to used a long time ago, when it was one of the only choices for collaboration.

One of the nuances of PFs is permissions. When a Root (\) folder is created, typically us admins will setup the permissions for clients. At that point any new child item of folder inherits the permission of it’s parent folder. This works great, until you get into organizations where there can be hundreds of thousands of folders that make a giant mess.

Additionally, when you add PF permissions, the permissions do not get propagated to child folders. Of course you can use the EWS interface, however for very large trees, you will see the command timeout.

So to address this issue I made the below script. The intention of it is to set the permission on a public folder and all child directories. It is built to allow for multiple users and PF branches. This will look at the trees provided and get a list of all of the child public folders. Then it will check if the user already has permissions on the folder, and if so remove the current permissions. Why is this? Well a user can’t have more than on permission on a folder. So any attempt to add the desired permission will produce an error. So instead I strip out the current permission and then replace it with the desired permission.

Enjoy! Download

<#
.SYNOPSIS
Set the PF permissions on all children Public Folders
.DESCRIPTION

.PARAMETER PFrOOT
The path to the ROOT file that you want to set permission. This attrubte accepts multiple paths.
.PARAMETER Users
Provide the list of user
.EXAMPLE
C:\PS> .\Set-PFClientPermissions.ps1 -PFRoot ".\Folder" -Users "User1", "user2" -Perm PublishingEditor

.NOTES
Author: Joshua Wortz
Date: octover 12th, 2016
#>
paramaters(
[array]$PFRoot,
[array]$users,
[string]$Perm
)


$pfs = $pfroot | %{Get-PublicFolder $_ -Recurse}

foreach ($pf in $pfs)
{
foreach ($user in $users)
{

if (Get-PublicFolderClientPermission -User $user -Identity $pf.Identity -ErrorAction:SilentlyContinue)
{
Get-PublicFolderClientPermission -User $user -Identity $pf.Identity | Remove-PublicFolderClientPermission -Confirm:$false

}

Add-PublicFolderClientPermission -Identity $pf.Identity -AccessRights $Perm -User $user -ErrorAction:Stop

}
}