For space reasons, this text is another bit that was cut out of my Exchange 2013 Inside Out: Mailbox and High Availability book. FWIW, here it is…
As you’re probably well aware, public folders are scrubbed and polished to become bright, new, and modern in Exchange 2013. Instead of the legacy public folder database, the folders are stored in public folder mailboxes alongside other mailboxes (both user and system) in regular mailbox databases so that they can benefit from the investment Microsoft has made over the last decade to give Exchange many high availability features.
The good news is that the new scheme works for both on-premises and cloud deployments. As usual, migration is a bit of a pain, but once you have moved the older public folders across to mailboxes, everything works quite nicely as long as you have clients that understand how to access the new content. For now that means Outlook 2013 or Outlook Web App.
The first public folder mailbox created in an organization holds the primary or writeable copy of the folder hierarchy. All other public folder mailboxes contain a not-writeable or secondary copy of the hierarchy that are updated by an Exchange mailbox assistant every 24 hours at a minimum, or every 15 minutes if clients are connected to a public folder mailbox that contains a secondary copy of the hierarchy.
Synchronization ensures that all of the public folder mailboxes present the same hierarchy to clients. By reference to the writeable copy, public folder mailboxes that hold secondary copies learn about additions and removals of public folders and the mailboxes that hold public folder content. The older form of public folders also synchronize information between databases but use replication messages for this purpose. By contrast, Exchange 2013 synchronizes public folder mailboxes by connecting to the mailbox that contains the primary hierarchy and adjusting a secondary copy based on the primary.
Synchronization is obviously tremendously important. Normally everything happens automatically and you should never have to interfere. But if such a situation arose, as in the case when a user reports that no trace of a newly created public folder is visible to them, you can force synchronization for a mailbox that holds a secondary copy of the public folder hierarchy by running the Update-PublicFolderMailbox cmdlet. For instance, this example instructs Exchange to synchronize the hierarchy in the “PFMBX2” mailbox with the primary copy:
Update-PublicFolderMailbox –Identity ‘PFMBX2’ –InvokeSynchronizer –FullSync
[Note: this is also the solution to the bug that Microsoft discovered soon after Exchange 2013 RTM CU2 was released when permissions on secondary public folder mailboxes disappeared following a move]
If everything goes to plan, you’ll see a message saying that “Sync with mailbox that contains primary hierarchy is complete” and you can go on with your life. The more curious will want more detail and fortunately this can be gained by running the Get-PublicFolderMailboxDiagnostics cmdlet. As its name indicates, this cmdlet is designed to help debugging problems with public folder mailboxes, but it does reveal some interesting data. In this example we run the cmdlet for the same public folder mailbox and direct the output to a variable. We then look at the synchronization data that is revealed by the cmdlet.
$Info = Get-PublicFolderMailboxDiagnostics –Identity "PFMBX2" $Info.SyncInfo NumberOfBatchesExecuted : 1 NumberOfFoldersToBeSynced : 0 BatchSize : 500 NumberOfFoldersSynced : 0 DisplayName : Public Folder Diagnostics Information LastSyncFailure : LastAttemptedSyncTime : 28/08/2013 12:17:13 LastSuccessfulSyncTime : 28/08/2013 12:17:15 LastFailedSyncTime : NumberofAttemptsAfterLastSuccess : 0 LastSyncCycleLog : 2013-05-28T11:17:13.925Z,,Entry,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,Sync started,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee362013-05-28T11:17:15.064Z,,Verbose,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,Delay:0;Iteration:1,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee36 2013-05-28T11:17:15.064Z,,Verbose,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,BeginReconcilation,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee36 2013-05-28T11:17:15.204Z,,Verbose,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,EndReconcilation,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee36 2013-05-28T11:17:15.204Z,,Statistics,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,0 folders have been added,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee36 2013-05-28T11:17:15.204Z,,Statistics,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,0 folders have been updated,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee36 2013-05-28T11:17:15.204Z,,Statistics,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,0 folders have been deleted,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee36 2013-05-28T11:17:15.204Z, Success,,f58fcb52-7d9e-44c1-9647-0e6b12a19823,Diagnostics for monitoring is successfully completed,,2e42c4a7-5ed9-4b42-b08c-ebd4e79eee36
Everything seems good in this instance, which is what we’d expect.
Remember that these hints only work when the commands are run against a public folder mailbox that holds a secondary copy of the hierarchy. The mailbox that holds the primary copy doesn’t have the same need to synchronize as it already knows everything about the hierarchy. And of course, if you use public folders with Office 365, you won’t see any trace of these cmdlets because Microsoft takes care to maintain public folders in good health for its cloud tenants.
Follow Tony @12Knocksinna
Thoughtsofanidlemind's Blog 
Pingback: Weekly IT Newsletter – February 16-20, 2015 | Just a Lync Guy
Pingback: NeWay Technologies – Weekly Newsletter #135 – February 19, 2015 | NeWay
Pingback: NeWay Technologies – Weekly Newsletter #135 – February 20, 2015 | NeWay
We just completed our migration to Exchange 2013 and intermittently there will be times when users cannot create new public folders. In Outlook they’ll get “cannot create the folder” even though it appears in EAC with a yellow banner saying “cannot process properties” or something like that. Hours later the folder will appear. Sometimes users can create folders instantly. Any ideas? Our PF structure has about 75,000 folders and 13 million emails stored over 32 public folder mailboxes all in the same database (about 143GB). We have passive copies on another local Exchange server and one off site. We are on CU7.
If users cannot create public folders, it’s an indication that an update cannot be performed against the public folder mailbox holding the writable copy of the hierarchy. I’d start by looking at why this might be so. Where is that mailbox, how available is it, and how do users connect to it. The fact that you are running such a large deployment of PFs makes it critical that the primary PF mailbox should a) be highly available, b) in a location that is accessible to all clients that need to update PFs (adds, deletes, update properties) and c) the mailbox should not hold any content – it should be reserved for PF hierarchy management
Thank you for your quick response. We don’t have multiple datacenters or offices, so the primary mailbox is local to where all the users and their mailboxes are. I do have the databases with the user mailboxes on one local DAG member and the database with the PF on another DAG member, but this shouldn’t matter should it? It does make sense to have an empty primary mailbox, I don’t know why Microsoft doesn’t mention that or recommend it. Our public folders are used heavily and maybe the primary is too busy serving up content at times. What do you mean by highly available? If you just mean HA then I have that covered, although when I’ve activated the passive database hosting the public folders on the other server it seems to hose everybody’s Outlook client. I don’t have that same experience when I activate a passive copy of a database with just user mailboxes, that works smoothly.
Is this the only method I can use to move all of the content out of the primary mailbox and into a new secondary? https://technet.microsoft.com/en-us/library/jj906435(v=exchg.150).aspx
I was wonder if there is a way to just create a new public folder mailbox and make it the primary. I didn’t see a way to do that except for recovery scenarios. Also, would you recommend that I move the primary mailbox to one of the smaller databases I have with user mailboxes, or leave it where it is?
I would move all PF content to another PF mailbox using the TechNet guidance… and no, you can’t make another mailbox the primary. Given the size of your implementation and the number of client connections, I would move the primary PF mailbox to a lightly used database.
Is there a way to tell how “busy” an exchange database is? Or just assume that if a database hosting user mailboxes that are mostly in cached mode would be less busy than a database hosting public folder mailboxes accessed in online mode? All of the active/passive of one DAG member are on one set of physical drives and the active/passive of the other DAG member are on another set of physical drives. The I/Os of both a well under the drives capacity but the DAG member with the active pf mailboxes normally always has about double the I/O activity than the DAG member with the four databases with user mailboxes. Is there another way to measure how busy they are other than I/O?
Makes sense to have it on a less busy DB though, I read that in one forum that was recommended to have the primary mailbox in it’s own DB but thought it was a typo and they meant to have the primary hierarchy it’s own mailbox with no content.
Thanks again for your quick response.
I/O to the drive is a great measurement of how busy a database really is. Again, better to be safe than sorry when starting off… so care and cherish the mailbox containing the primary hierarchy and give it the resources that it needs to do its work. Isolating it into its own database makes a lot of sense given the number of folders you have.
Does it matter if that that database would be on the same physical drives as the other database? Or just having it in it’s own database is the key?
Start off with a database on a disk shared with other databases; check I/O. If heavy at peak periods, move PF database (I know, an obsolete term) to its own drive.
Thanks, I will start with these recommendations. Any idea why our outlook clients completely freeze up and stop responding when the passive copy of the database holding the public folder mailboxes is activated on the server with the other databases? I wasn’t looking at I/Os at the time but CPU and Memory were not choked by any means. I have 4 CPUs and 40GB of RAM on each server. We’ve been running user mailboxes on 2013 for a couple months now and never had a problem switching between DAG members for those databases. Maybe it’s all related to that primary PF mailbox. 🙂 Just curious on your thoughts.
Sorry… I don’t know why your Outlook clients are freezing. Time for a support call with Microsoft.
Final question. 🙂 Can you think of a reason why public folders wouldn’t appear for someone when they first open Outlook (closing a reopening outlook resolves it), or public folders would disappear from someone’s outlook client (again, closing and reopening outlook resolves it). This has only happened twice to two different users this week. I know a lot of our users have public folders in their Outlook favorites, probably putting more strain on outlook and the public folders. Your thoughts.
I assume that you’re using the latest version of Outlook 2010/2013 and all available updates and patches are installed? If not, I would make sure that this is the case.
Ok, I think it was all a matter of not having an empty primary mailbox because that issue has gone away after clearing it out. Now I have a new problem. I need help restoring a public folder in Exchange 2013 CU7. The folder is named Human Resources and on the backup tape it was in the mailbox named “PF-Hierarchy”. I now want to restore this in mailbox named “Mailbox33”. I’ve already created this folder in Mailbox33 and ran the following command:
New-MailboxRestoreRequest –SourceDatabase “RecoveryDB” –SourceStoreMailbox “PF-Hierarchy” –TargetMailbox “Mailbox33” –AllowLegacyDNMismatch –IncludeFolders “Human Resources”
get-mailboxrestorerequest shows that it completed. However, I have no subfolders and there were a lot. There were no emails originally in the root folder so the only thing that I can see that was restored are the permissions that were set on this folder from the backup.
If I try to run the following to restore a subfolder I get the following error:
[PS] C:\Windows\system32>New-MailboxRestoreRequest -SourceDatabase “RecoveryDB” -SourceStoreMailbox “PF-Hierarchy” -Targ
etMailbox “Mailbox33” -AllowLegacyDNMismatch -IncludeFolders “Human Resources\Benefits Info”
The provided IncludeFolders or ExcludeFolders value is invalid. Folder path ‘Human Resources\Benefits Info’ contains
an invalid escaped character at position 16.
+ CategoryInfo : InvalidArgument: (System.String[]:String[]) [], FolderFilterInvalidPermanentException
+ FullyQualifiedErrorId : [Server=MAIL02,RequestId=0d453ca4-cf9e-40ab-a62a-e69fde36ec39,TimeStamp=5/30/2015 6:1
4:42 PM] [FailureCategory=Cmdlet-FolderFilterInvalidPermanentException] 3534F10B
+ PSComputerName : mail02.company.com
Now I’m seeing the following error in the event logs. It will still show that the restore completes but nothing appears, not even permissions this time.
Log Name: Application
Source: MSExchange Mailbox Replication
Date: 5/30/2015 1:56:24 PM
Event ID: 1006
Task Category: Service
Level: Warning
Keywords: Classic
User: N/A
Computer: MAIL02.company.com
Description:
The Microsoft Exchange Mailbox Replication service was unable to process jobs in a mailbox database.
Database: RecoveryDB
Error: MapiExceptionRecoveryMDBMismatch: Unable to open message store. (hr=0x80004005, ec=1165)
Diagnostic context:
Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=132]
Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=256][latency=0]
Lid: 52176 ClientVersion: 15.0.1044.25
Lid: 50032 ServerVersion: 15.0.1044.6025
Lid: 23226 — ROP Parse Start —
Lid: 27962 ROP: ropLogon [254]
Lid: 17082 ROP Error: 0x48D
Lid: 26937
Lid: 21921 StoreEc: 0x48D
Lid: 27962 ROP: ropExtendedError [250]
Lid: 1494 —- Remote Context Beg —-
Lid: 61208 StoreEc: 0x8004010F
Lid: 57721 StoreEc: 0x8004010F
Lid: 61692 StoreEc: 0x8004010F
Lid: 50608
Lid: 45768 StoreEc: 0x48D
Lid: 56872 dwParam: 0xFE
Lid: 42712 StoreEc: 0x48D
Lid: 10786 dwParam: 0x0 Msg: 15.00.1044.021:MAIL02
Lid: 1750 —- Remote Context End —-
Lid: 26849
Lid: 21817 ROP Failure: 0x48D
Lid: 26297
Lid: 16585 StoreEc: 0x48D
Lid: 32441
Lid: 1706 StoreEc: 0x48D
Lid: 24761
Lid: 20665 StoreEc: 0x48D
Lid: 25785
Lid: 29881 StoreEc: 0x48D
[PS] C:\Windows\system32>Get-mailboxstatistics -database recoverydb | ft -auto
DisplayName ItemCount StorageLimitStatus LastLogonTime
———– ——— —————— ————-
SystemMailbox{8771b6f0-602f-419f-a51f-65f62904c421} 193
HealthMailbox-MAIL02-DB_PF 46427 5/22/2015 10:11:54 PM
In-Place Archive – HealthMailbox-MAIL02-DB_PF 1
HealthMailbox-MAIL01-DB_PF 41 5/19/2015 3:35:27 PM
In-Place Archive – HealthMailbox-MAIL01-DB_PF 1
PF-Hierarchy 470962 5/22/2015 6:48:57 PM
Mailbox1 298496 5/22/2015 5:36:09 PM
Mailbox2 444304 5/22/2015 8:31:03 PM
Mailbox3 136689 5/22/2015 9:10:56 PM
Mailbox4 499201 5/22/2015 5:59:10 PM
Mailbox5 295731 5/22/2015 9:13:45 PM
Mailbox6 254293 5/22/2015 6:24:24 PM
Mailbox7 508087 5/22/2015 10:00:40 PM
Mailbox8 168142 5/22/2015 4:27:35 PM
Mailbox9 380414 5/22/2015 6:06:58 PM
Mailbox10 579099 5/22/2015 7:40:31 PM
Mailbox11 652505 5/22/2015 4:10:41 PM
Mailbox12 688822 5/22/2015 6:29:21 PM
Mailbox13 234466 5/22/2015 5:02:33 PM
Mailbox14 473333 5/22/2015 8:03:39 PM
Mailbox15 452060 5/22/2015 5:38:02 PM
Mailbox16 460851 5/22/2015 8:03:37 PM
Mailbox17 324923 5/22/2015 6:02:59 PM
Mailbox18 483054 5/22/2015 8:51:49 PM
Mailbox19 458755 5/22/2015 9:43:09 PM
Mailbox20 305449 5/22/2015 7:23:17 PM
Mailbox21 531844 5/22/2015 8:51:48 PM
Mailbox22 244694 5/22/2015 7:59:56 PM
Mailbox23 456732 5/22/2015 6:26:50 PM
Mailbox24 153565 5/22/2015 5:57:16 PM
Mailbox25 500841 5/22/2015 9:12:06 PM
Mailbox26 474182 5/22/2015 6:20:06 PM
Mailbox27 227054 5/22/2015 6:12:06 PM
Mailbox28 288744 5/22/2015 5:28:52 PM
Mailbox29 396849 5/22/2015 6:48:48 PM
Mailbox30 384781 5/22/2015 5:57:09 PM
Mailbox31 457674 5/22/2015 9:12:06 PM
Dave, this is not a support site. As I said before, given the size of your PF deployment, when you run into problems you are best to contact Microsoft support.
I am trying to move some public folders post migration to Exchange 2016. I am relatively successful with small folder moves, but if the move (large folder or folders) takes a while, something is causing it to fail – could be it be the every 15 minute Hierarchy Update?
“If users cannot create public folders, it’s an indication that an update cannot be performed against the public folder mailbox holding the writable copy of the hierarchy. ”
After migration to Ex2016 I have the same problem like Dave. User can only create new folder under existing folders which located in “Mailbox1” – primary hierarchy, but not in folders, which located in secondary hierarchy (sample Mailbox2). User has full rights and their standard pf Mailbox is Mailbox1.
Goodd reading this post