We were able to recover the mailboxes for the end users… However, when an attempt was made to recover the Public Folders, we had significate issues. First, let’s review what we know about Modern Public Folders.
A Little background
When Microsoft created Modern Public Folders in Exchange Server 2013, the Exchange world thought that the new iteration of Public Folders would be worlds better. In some ways it was. No longer were we restricted to SMTP for replication. Or odd behavior with access. In terms of the client access and end user experience, not much changed…..
Now when it comes to Exchange 2013 and newer, we have a new architecture. Instead of Public Folders and its respective hierarchy being mapped to a particular database, we now have Public Folders mapped to a Mailbox. This mailbox is a special mailbox, known as a Public Folder mailbox. The name isn’t all that surprising.
Our Scenario’s Problem Exposed
Why did our recovery go south? Well, first they had no secondary hierarchy. This was the first issue. Second, our database recovery did not go well as was planned. We were able to restore the main database and get the database into a ‘Clean Shutdown’ state. The issue became mounting the database in place. Due to timing and other conditions outside our control, we were not able to mount the clean database. Instead we used a recovery database, mounted the edb file and set the end users up with a Dial Tone Recovery Database. This allowed users to get back to work, to receive and send emails, while we worked on the issue and recovered data from the recovery database.
Using the New-MailboxRestoreRequest cmdlet, we were able to recover the end user’s mailboxes over a day or two. Some additional tweaks were needed in order to get the data recovered in a quick manner. However, Public Folder mailbox recover requests consistently failed with errors about too many missing items, and could not find folders. This is simply because we had no Public Folder hierarchy waiting for the request to work with to sort out the data in the Public Folder Mailbox (Recovery Database).
Public Folder Configuration Scenarios
With all that said, let’s review some real world design options and recommendations so that your Exchange Server environment is protected by potential Public Folder issues. Each of the outlined scenarios should be representative of a real configuration in the wild. Recommendations about each of these scenarios will also be providers.
Scenario 1
In this scenario, the company has deployed one server that contains two mailbox databases. Each mailbox database contains one Public Folder mailbox:
In this scenario we have two copies of the Public Folder hierarchy, one in each Public Folder mailbox and also one copy in each database. This allows for recovery of both a folders, hierarchy, etc. However, this is NOT a good scenario. One more server should be added for additional uptime / recoverability of your Public Folders. This scenario, while recoverable in terms of Public folders, it is NOT a recommended configuration as your single point of failure is your single server.
Scenario 2
In this scenario, we have 2 servers, each with 2 databases and in the end, 2 copies of everything. Now in this scenario, not only are your regular mailboxes protected with additional copies, your Public Folder mailboxes are also protected as well.
With this scenario, we are now closer to what Microsoft has defined in their Preferred architecture. It is the MINIMUM recommended for your Exchange on-premises configuration, with respect to servers, databases, mailboxes and especially Public Folders. Not only can keep your users happier with mailbox copies that are resilient in failures, your Public Folder infrastructure provides the same experience for your end users. Unless you lose everything (both servers and both copies) you should not be concerned with restoring an entire Public Folder hierarchy.
SCENARIO 3
The two iterations of this scenario are both bad, but one is much worse than the other. The main issue here is that the Public Folder mailboxes are relegated to one
Recovery Scenario
When it comes to recovery, why does this matter? Simply put, it’s all about the hierarchy. With good copies, on separate copies in a DAG, Exchange has your recovery scenarios covered. You can lose a mailbox, a database or a server and your Public Folder hierarchy is sage, If you follow the Preferred Architecture, Microsoft has laid out a configuration that covers those bases.
What if we fail to follow Microsoft’s guidance and simply don’t want to build out 4 Exchange servers and we want to protect Public Folders and its hierarchy? Well, we have a couple of options, some better than others:
[1] At least two servers in a DAG that contain at least two Public Folder mailboxes on two different mailbox databases
[2] Single server that contains at least two Public Folder mailboxes on two different mailbox databases
Option 1 is a valid option if you cannot follow the Preferred Architecture.
Option 2 is full of pitfalls:
- Single server = single point of failure
- Hardware failure = downtime
Recovery Failure Scenario – An Explanation
With a bad configuration sometimes comes bad results. In the below scenario we have a single Exchange 2013+ server that has one database and one Public Folder mailbox. An issue occurred with an update that eventually put the server into a non-bootable state. This leads to a full recovery of the OS and Exchange. The mailbox database won’t mount, which is not an uncommon scenario. Multiple uses of EseUtil /R and /P are used. The database eventually gets to a ‘Clean Shutdown’ state. However it won’t mount. Instead of spending more time with the recovered database, a Dial Tone (empty) Database is created and mailboxes are attached to that database. Then the recovered database is mounted as a recovery database and mailbox data is recovered without issue using PowerShell – New-MailboxRestoreRequest. This same cmdlet will FAIL if trying to recover a Public Folder Mailbox from a recovery database to a dial tone database.
Summary
In the end, the recommendation here is multifaceted, but one that should be followed in order to avoid this case:
(1) Always deploy two or more servers in a DAG, no excuse here
(2) Deploy more than one database and put copies on two to four DAG members
(3) Create at least two Public Folder mailboxes to have two copies of the hierarchy
(4) Place Public Folder mailboxes on different mailbox databases
(5) The Public Folder hierarchy CANNOT be restored from a Public Folder mailbox in a Recovery Database
(6) If a database that contains Public Folder mailboxes can be brought to a Clean Shutdown state, then spend the time to get it mounted and avoid the Recovery Database method,
The last point is the most important. Never deploy a single Exchange server by itself. This is NOT recommended for many reasons.
If you find yourself in the bad recovery scenario with a lost or corrupted Public Folder hierarchy, contact MS support for assistance.
