Determine Office 365 Public Folder Hierarchy Limit

​Last month, in June 2014, the Exchange Team announced that Office 365 would soon have the public folder hierarchy folder count limit raised from 10,000 folders to 100,000 folders.  This limit increase would begin to take effect in July, 2014.

But how can you tell what your tenant’s current folder count limit is?

  1. Open a remote PowerShell session to your Office 365 tenant
  2. Run the following command:
    Get-Mailbox -PublicFolder | Get-MailboxStatistics | fl FolderHierarchy*

The command will return the following results:

FolderHierarchyChildrenCountWarningQuota : 9000
FolderHierarchyChildrenCountReceiveQuota : 10000

FolderHierarchyDepthWarningQuota         : 250
FolderHierarchyDepthReceiveQuota         : 300

Once the FolderHierarchyChildrenCountReceiveQuota is raised to 100000, you’ll know your tenant has been updated.

If your tenant does not have a public folder mailbox created yet, you can run the command without the -PublicFolder parameter and replace it with any mailbox identity.


Populate the “folder path” field for mail-enabled public folders in the address book

If you’re like me you hate when you get a request from a user to modify something with a mail-enabled public folder because users NEVER tell you the path to that folder in the folder hierarchy.  You can find it via powershell if you want:

Get-MailPublicFolder “smtp@address” | Get-PublicFolder | fl Name, ParentPath

Name    : Folder Name
ParentPath : Parent Folder NameSub folder name

If you look in the address book, each mail-enabled public folder in the list has a “folder path” property that never gets populated.  I wish I knew why Microsoft made this information available but didn’t make it easy to populate the values – you’d think it would just automatically be able to look that information up when it generates the address list – but sadly, NO!

Or you could run a powershell script to set each one of them automatically.  You’ll have to schedule the script to run regularly to make sure the values are up to date though.  You’ll also need the Quest ActiveRoles snapin for powershell. 

Here’s the script I wrote to accomplish this:

$mailpub = Get-MailPublicFolder -ResultSize unlimited
foreach ($folder in $mailpub) {
 $pubfolder = Get-PublicFolder -Identity $folder
 $folderpath = $pubfolder.parentpath + “” + $
 $qadpub = Get-QADObject -IncludeAllProperties -Type publicfolder -Identity $folder
 Set-QADObject -Identity $qadpub -ObjectAttributes @{folderPathname=$folderpath}}


Have fun!

Public Folder Mailflow

Last week I installed a new exchange server into the Dallas Administrative Group and the Dallas Routing Group.  Default installs of exchange include a mailbox database and a public folder database.  I wasn’t really concerned with the public folder database (not intending to keep it) so I just left it there for now (planning to delete it at a later date) and proceeded to create a journaling mailbox on the mailbox database.  (This journal mailbox isn’t pertinent to this post other than it only RECEIVED mail and didn’t DELVIER any of it).


Today I noticed that there were a LOT of messages backed up in the various queues on the new server (Ex3) – including over 2900 messages in the Local Delivery Queue destined for public folders on OTHER servers!  This, I thought was quite strange.  Why would those messages be delivered to Ex3 if it doesn’t host any of the public folder replicas???


However, what I didn’t notice at first were ACLs on the “Connection” & “Relay” access on the SMTP virtual servers on every other Exchange server in the Org.  So the new server (Ex3) couldn’t telnet to any other exchange server to deliver messages.  The Journal mailbox was receiving messages just fine because the default configuration on SMTP virtual servers when you install Exchange is to accept all authenticated connections – which would include other Exchange servers.


So I did a little research.  Public folder routing happens like the following:


1.       Message comes in from the internet.

2.       Categorizer looks up homeMDB for the recipient where it finds the DN of the top-level public folder hierarchy.

3.       Next, the categorizer looks up the top-level hierarchy object that is retrieved from the folder’s homeMDB attribute to obtain a list of all the servers in that hierarchy from the msExchOwningPFTreeBL value.

4.       To determine which public folder store or server to deliver to, the categorizer uses the following criteria: 

             Does one of the public folder stores exist on the local server? If so, Exchange uses that store.

             Does one of the public folder stores exist on an Exchange server in the local routing group? If so, Exchange uses that store.

             Does one of the public folder stores exist on any Exchange server? If so, Exchange uses that store. Otherwise, Exchange uses the first store in the list.


In my case, there are 3 servers in the Dallas routing group: Ex1, Ex2, and (new) Ex3.  Ex1 and Ex2 both receive messages from the internet edge servers directly.  Ex1 has a public folder database but Ex2 does not since it’s just basically a Front-End server that’s also used for message routing.  The folder hierarchy is homed on Ex1.


So – Ex2 was receiving messages from the internet destined for public folders.  Based on the 2nd bullet point in #4 above, it would deliver messages to the public folder store on either Ex1 or Ex3 since they were both in the local routing group and had a public folder store in the hierarchy.  BUT since Ex3 couldn’t telnet TO any other server and could only RECEIVE, messages backed up in the local delivery queue.  That’s when I added the IP address for Ex3 to the SMTP virtual servers on all the other Exchange servers in the Org.


The queues on Ex3 to the other routing groups emptied quite quickly once telnet was working – but what they were delivering was hierarchy messages from Ex3 to the other public folder stores (to announce there’s a new public folder store on Ex3 and request a hierarchy replication back to Ex3 so it knows what folder is located where, etc).  However, the Local Delivery Queue on Ex3 wasn’t moving at all and this made me a little concerned.


What I didn’t realize at first was that the PF store on EX3 had to wait for ALL public folder hierarchy replication to complete and come back to EX3 with the full hierarchy before EX3 knew where to deliver those messages stuck in the queue – which explains why the local delivery queue took so long to empty.


After all the messages got delivered successfully, I verified that there were NO replicas in the public folder store on EX3 and promptly deleted it so that it wouldn’t be included in public folder mail delivery again.  Whew!

Troubleshooting Removing Public Folder Replicas

The last few weeks have been challenging for me because of Public Folders.  In my environment I have a site in Tempe, AZ that has two exchange servers (let’s call them server1 and server2).  Server1 is an old box and we want to decomission it.  It was only hosting a few small resource mailboxes and replicas of public folders relevant to that site.

Removing the resource mailboxes was easy – I just used the Move Mailbox function in ESM.  Public folders hasn’t been so easy – though it should have been.

To move all the replicas hosted on Server1, i opened ESM, navigated down to the public folder store node, right-clicked and chose Move All Replicas, then selected Server2 from the list.

Now, Server2 already had replicas of most of these same public folders so all i was really interested in was making sure the hierarchy was updated to show that Server1 was no longer hosting replicas.  I could test this by looking in the Public Folder Instances node on Server1 and looking for it to reveal empty white space.  It worked great except for a few hundred folders that just wouldn’t seem to disappear.

I began to troubleshoot this issue by viewing the public folder replicaion events that are generated when you turn up logging.  To see these events, enable the following options on the Diagnostic Logging tab of each exchange server involved in replicaion:

  • MSExchangeIS
    •  Public Folder
      • Replication AD Updates – Maximum 
      • Replication Incoming Messages – Maximum
      • Replication Outgoing Messages – Maximum
      • Non-delivery Reports – Maximum
      • Replication Backfill – Maximum
      • Replication General – Maximum

There’s a really great article on The Microsoft Exchange Team Blog by Bill Long that goes into great detail about how to troubleshoot Public Folder Replication with these events.

I noticed on my servers that I was still getting 3030 events with a Type of 0x4 which reflects incoming content from Server2.  How could this be when the folder in question no longer shows Server1 as hosting a replica of that folder?

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: Replication Incoming Messages
Event ID: 3030
Date:  8/15/2008
Time:  2:13:20 PM
User:  N/A
Computer: SERVER1
An incoming replication message was processed.

 Type: 0x4
 Message ID: <>
 Folder: (1b-79DC) IPM_SUBTREECompanyLead ManagementPoint Of Sale

 Database “PUBPublic Folder”.
 CN min: 6c-626B02B
 CN max: 6c-626B02B
 MIDs: 1
1: 6c-5C382BE

 MIDSET deleted: {0}

 Server: /O=Company/OU=TEMPE/cn=Configuration/cn=Servers/cn=Server2/cn=Microsoft Public MDB

Confusing options in PFDAVAdmin

So, I used PFDAVAdmin yesterday to make some changes to the replicas of some huge public folder trees.  I used the Custom Bulk Operation to perform a Replica List Operation type and selected the Merge action.  It asked me for the list of stores I wanted to add to the replica list and then it asked me for a list of stores i would like to remove from the replica list.

Doesn’t really tell you that this does both functions independently and is not a Search & Replace feature. 

For instance, say you have a folder tree like the one listed below.  The RootFolder has a replica only on  ServerA but SubFolder3 has additional replicas on ServerB.  You want to move those replicas from ServerB to ServerC.


If you use the Merge action against RootFolder to add ServerC and remove ServerB, the tool will add ServerC to the replicas of the RootFolder and all subfolders and you’ll end up replicating the ENTIRE RootFolder structure to ServerC, not just the folders where the ServerB replicas were removed.

This could be very un-fun if the RootFolder is very large.  You’ll probably get a call from one of your WAN guys asking why you’re hogging all the bandwidth.  🙂

Instead, in SP2 for Exchange2003, they’ve added a context-menup for moving replicas.  More info on that can be found here.

You’ve been forewarned.