Exchange 2013 Preview - Public Folders (Part 1)

Public Folders [PFs] were introduced in Exchange 4.0 as a way to collect, organize and easily share information with other users. They were, and still are, used to share documents, e-mail messages, contacts and calendars. By mail-enabling a PF, users can also send e-mails to them, a feature that allows PFs to serve as a distribution group archive or a discussion forum for example.

Until Exchange 2007 and Outlook 2007, PFs were also required in order to provide Free/Busy Information and allow users to download the Offline Address Book. Now, these features are provided by the Autodiscover service, the Microsoft Exchange System Attendant service and the Microsoft Exchange File Distribution service.

PFs have always had their dedicated database which is usually replicated between servers for high availability. This also allows for a PF replica to be closer to users from a network perspective, thus saving bandwidth and improving performance. The drawback is that the replication method used between PF databases is far from ideal and sometimes users have to wait minutes for their PFs to get updated.

Throughout the years PFs have become so popular and useful that some companies have literary thousands and thousands of them. However, they are often used in a way they shouldn’t be. For example:

• To archive data. Using PFs for archiving data in order to overcome mailbox quota limits is not recommended as it affects the performance of the PF server, thus affecting every user that uses it;
• Document collaboration. PFs were never designed for document collaboration as they don’t provide versioning, document check-in and check-out functionality, automatic notifications of content changes, etc.

For many years Microsoft has tried to move away from PFs and their guidance around Exchange 2007 was for administrators to consider moving PFs into SharePoint as they wouldn’t be around for much longer. Although there are many tools currently available to achieve this, for some companies it is simply just not doable as SharePoint still doesn’t deliver the same functionalities of PFs. They might be old, a nightmare to maintain and manage, but they are still very valuable.

So once more, this time with Exchange 2013 and the new Office 365 “Wave 15”, PFs are here to stay! Although they haven’t practically evolved since they were first introduced, with Exchange 2013 they finally have!

Improvements in Exchange 2013 Preview

One of my disappointments with Exchange 2010 is that PFs cannot be part of a Database Availability Group [DAG] and we still have to use the same replication method available for PFs to achieve resilience and high availability.

The good news is that with Exchange 2013 Preview, PFs do take advantage of the existing high availability and storage technologies of the mailbox store, using specially designed mailboxes to store both the hierarchy (the properties of the PFs and the structure in which they are organized) and the content (the actual data) of PFs.

Besides PFs now being special mailboxes, there is no longer a Public Folder Database! The best part is that PF replication now uses the continuous replication model, and high availability for the PF mailboxes is achieved through a DAG, thus moving away from a Multi-Master Replication Model PFs had, to a Single-Master Replication Model of DAGs.

A Multi-Master Replication Model is one where you have two or more PF databases replicating between them. “Multi-Master” comes from the fact all PF databases are writable so you can have some users using one database, other users using the other database to access the same data, but their content is being constantly replicated between them, so all users have access to the same information. The problem is that this replication is done through SMTP messages sent between the servers holding the PF databases and is not very efficient, often causing conflicts when the same data is updated at the same time.

Because now PFs can be part of a DAG, we no longer have this multi-master replication model. Instead they replicate using the standard transaction log shipping method.

One issue with the Preview edition of Exchange 2013, is that because of the way DAGs work, you can only have a single active copy of a particular PF mailbox anywhere in the organization. So if you want to share the same PF between users in different locations, keep this in mind! However, it seems that Microsoft will be changing this in the future!

Creating Public Folder Mailboxes

The first step to start using PFs in Exchange 2013 is to create a PF Mailbox. When you create the first PF Mailbox, this will become the Public Folder Master Hierarchy Mailbox, which is the only one with a writable copy of the PF hierarchy. Every subsequent PF mailbox you create will be a simple PF mailbox with a read-only copy of the hierarchy.

When a user performs a hierarchy change such as creating or deleting a folder, this change is redirected to the Master Hierarchy PF Mailbox and then replicated to all other PF Mailboxes, thus avoiding conflicts.

Because we no longer have the Public Folder Management Console, you have to use the Exchange Management Shell [EMS] or the new Exchange Administration Center [EAC] to manage PFs. Let’s start by using the EMS.

In the screenshot below you can see that I am running the cmdlets on a server named EXC2013, which is an all-in-one server. However, when I create the first mailbox, this gets created on a server named EXC2013MBX01, which hosts just the mailbox server role. This is because Exchange will pick a random database if you do not use the –Database parameter.

Next, we create a second mailbox but this time we manually specify in which database to create it. In this case, both PF mailboxes are on different databases and in different servers, which is not required.

Figure 1.1: Creating Public Folder Mailboxes through the EMS

In order to verify that the Master Hierarchy mailbox has been successfully created, you compare the RootPublicFolderMailbox attribute of your OrganizationConfig with the ExchangeGuid of your PF mailboxes. In this case, you will see that the MasterHierarchy mailbox we just created is indeed the Master:

Figure 1.2: Checking the Master Hierarchy Mailbox

In the screenshot above you can also see that it is using Set-OrganizationConfig that we set global settings for PFs (unlike with Exchange 2007 and 2010), such as the quotas, maximum size for items or retention period, for example. The attributes PublicFolderLockedForMigration and PublicFolderMigrationComplete are used when migrating PFs from Exchange 2010.

You can also use the EAC to create PF Mailboxes. To do this, login to the EAC, navigate to Public Folders on the left side menu and select Public Folder Mailboxes:

Figure 1.3: Public Folder Mailboxes in the EAC

Now click on the + icon to create a new PF Mailbox. Note the message saying that the first PF Mailbox created will have a writable copy of the hierarchy. If you want you can enter the desired Organizational Unit [OU] and Database where this mailbox will be created but as we saw before, these are optional:

Figure 1.4: Creating a Public Folder Mailbox through the EAC

Security

For security reasons, the Active Directory accounts of these mailboxes are disabled as one would expect so that no one can use them to login into a workstation for example:

Figure 1.5: Disabled Active Directory Accounts

If you look in the EMS, you will see that a Public Folder Mailbox is similar to a Shared mailbox, which also has its Active Directory account disabled:

Figure 1.6: Public Folder Mailbox Properties

You will also see that now we have a new value for RecipientTypeDetails called PublicFolderMailbox and that the mailbox has an SMTP address. However, Exchange rejects any e-mails sent to a PF mailbox, and if you try to e-mail one you will receive a similar error to this:

Figure 1.7: Error e-mailing a Public Folder Mailbox

But if this is simply a Shared mailbox, can’t we give users access to it and add the mailbox in Outlook or Outlook Web App [OWA]? One would expect so, but Exchange does a good job in preventing this.

If you give a user FullAccess permissions to a PF mailbox and you try to open it in OWA you will get a webpage with the error ErrorExplicitLogonAccessDenied:

Figure 1.8: OWA error when opening a Public Folder Mailbox

In Outlook you will see the mailbox added to your profile, but when you try to expand it you receive another error:

Figure 1.9: Outlook error when accessing a Public Folder Mailbox

Creating Public Folders

Now that we have Public Folder Mailboxes, we can start creating some Public Folders. At this stage, your clients will not have access to Public Folders in Outlook or OWA because there are none to be accessed yet. To be honest, the current version of OWA does not yet support PFs...

Figure 1.10: No Public Folders in Outlook (left) or in OWA (right)

So let’s start by creating our first PF using the EAC. First note that when using the EAC to create a PF, you can only set the name and the path for the PF. To configure additional settings, you have to edit it after it has been created. Important: if you want to specify the mailbox that will host the PF, you have to use the EMS...

In the EAC, go to Public Folders and then click in Public Folders:

Figure 1.11: Public Folders in the EAC

Click the + icon to create a new PF. Because this is the first PF to be created, you can’t create it as a subfolder. Type the name of the PF that you are creating and click save:

Figure 1.12: Creating a Public Folder in the EAC

Once finished, you will be able to see some details of the PF:

Figure 1.13: Public Folder Details

If you click on the pencil icon, you can edit the PF and see more details. In the General tab, you can see the name, path, number of items and size of the PF, the PF mailbox that is hosting the PF, when it was last modified and if you want to use per-user read and unread information:

Figure 1.14: Public Folder General Properties

Note that the mailbox used for this PF was the Master Hierarchy Mailbox! This is because this mailbox apart from being the only one with a writable copy of the hierarchy, is just another simple PF mailbox that can also hold content! Because through the EAC we cannot specify which mailbox to use, Exchange picks a random one.

By clicking in the Statistics tab, you will be able to see statistics regarding the number of items in the PF and their size, how many owners and contacts the PF has:

Figure 1.15: Public Folder Statistics Properties

The final tab, Limits, allows you to set individual quota limits and retention periods for the PF, or to use the organization defaults as we saw previously:

Figure 1.16: Public Folder Limits Properties

By using the EMS to create PFs, you can specify the mailbox and the OU where you want to create the PF:

Figure 1.17: Creating Public Folders in the EMS

To check that the PFs have been successfully created you can refresh the EAC (note that the PF Exchange 2013 Project now has subfolders):

Figure 1.18: Public Folders in the EAC

You can check in Outlook where you now should see the recently created PFs:

Figure 1.19: Public Folders in Outlook

Or you can use the EMS:

Figure 1.20: Public Folders in the EMS

You can also use the EMS to check the details for a particular PF. For example, if we check the Office 365 Project PF that we created in the London mailbox, we will see that MasterHierarchy mailbox is the ParentFolder and the MailboxOwnerID:

Figure 1.21: Public Folder Details in the EMS

So does this mean that even though we created the PF in the London mailbox, it is actually in the MasterHierarchy mailbox?! Not exactly as this only refers to the PF Hierarchy!

If we check the size of both mailboxes before and after I add some data into the Office 365 Project PF (remember this PF is in the London mailbox), we will see that the content is actually in the London mailbox:

Figure 1.22: Public Folder Mailbox Size

Since Get-PublicFolder doesn’t tell us which mailbox holds each PF, how do we get this information?! You can use the EAC as we saw in Picture 1.14 or you can use Get-PublicFolderStatistics. With this cmdlet, the Identity and the MailboxOwnerId reflect the actual mailbox that is holding the PF’s content:

Figure 1.23: Public Folder Statistics

If you want to check what mailbox is hosting all of your PFs, you just need to make a slight change to this cmdlet to check every single PF:

Figure 1.24: All Public Folder Statistics

Conclusion

In this first part of the article, we explored the new features of Public Folders in Exchange 2013 Preview, their improvements and how to work with them. In the second and final part of the article, we will see how to mail-enable Public Folders and how to configure permissions and quotas. We will finalize with an overview of the steps involved in migrating Public Folders from Exchange 2010.