Late yesterday we became aware of a specific issue with Exchange 2013 RTM CU2. This issue only occurs within native Exchange 2013 environments that are leveraging Modern Public Folders. The issue exists when you move public folder mailboxes. The specific issue is that if you move a public folder mailbox, there is the potential for the permission structure on some public folders to be lost. Specifically:
- If you move (via New-MoveRequest) a secondary public folder (PF) mailbox, the permissions on any public folder (including well known folders) not stored in the secondary PF mailbox would be lost from the secondary PF mailbox and replaced by the default ACL. The original ACLs can be restored via a full synchronization event by executing Update-PublicFolderMailbox -InvokeSynchronizer <Public Folder Mailbox> -FullSync.
- If you move (via New-MoveRequest) the primary PF mailbox, the permissions on any public folder (including well known folders) not stored in that public folder mailbox are lost and replaced by the default ACL.
The default ACL gives Author permissions to Default authenticated users.
Recommendation
If you have already deployed Exchange 2013 RTM CU2 (712.22) and have Modern Public Folders in your environment, we recommend you do not move public folder mailboxes so that you do not experience this issue. We will be releasing an IU that will address this issue in the near future.
If you are in the midst of a migration to Exchange 2013 and will not be deploying Modern Public Folders for some time, you can proceed with installing Exchange 2013 RTM CU2 (712.22). Once you are ready to deploy Modern Public Folders ensure you have deployed the soon-to-be-released Interim Update or the latest available Cumulative Update.
Questions/Answers
Q: What if I have already deployed CU2 and moved a public folder mailbox?
A: If you have moved a secondary PF mailbox, then you can execute Update-PublicFolderMailbox -InvokeSynchronizer <Public Folder Mailbox> -FullSync to replace the permissions. If you moved the primary PF mailbox, you will need to manually reassign permissions.
Q: What is a Primary Public Folder Mailbox?
A: The primary Public Folder (PF) mailbox is the mailbox defined as the RootPublicFolderMailbox within the organization. You can look up the RootPublicFolderMailbox GUID via the Get-OrganizationConfig cmdlet.
Q: What is a Secondary Public Folder Mailbox?
A: A secondary PF mailbox is any public folder mailbox that is not defined as the RootPublicFolderMailbox within the organization.
Q: Can you explain the issue in a different way?
A: Let’s say you have the following public folder structure:
Hierarchy | Folder Location |
\Root Folder | Primary Public Folder Mailbox |
\Child Folder 1 | Secondary PF Mailbox 1 |
\Child Folder 2 | Secondary PF Mailbox 2 |
\Child Folder 3 | Secondary PF Mailbox 3 |
If you were to move the primary PF mailbox from Database1 to Database2, the permission structure, in the primary PF mailbox, for each of the child folders would be replaced with the default ACL. This hierarchy change would replicate to all other secondary PF mailboxes.
If you were to move secondary PF mailbox 1 from Database1 to Database2, then the permission structure for \Root Folder, \Child Folder 2, and \Child Folder 3 hierarchy objects within secondary PF mailbox 1 would be temporarily reset to the default ACL. However, hierarchy replication would overwrite the permissions when you execute a full synchronization event.
Q: Can this issue occur in an environment that is coexisting with a legacy version of Exchange when the public folders are still hosted on the legacy version?
A: No; this issue only affects Modern Public Folders. You can only migrate to Modern Public Folders once you complete your user mailbox migration.
Q: Does this affect normal mailbox moves?
A: No, this only affects public folder mailbox moves.
Q: Does this affect public folders stored in Exchange Online that are moved by the auto-split process described in the Public Folders and Exchange Online article?
A: No, auto-split moves folders from one mailbox to another using New-PublicFolderMoveRequest and this cmdlet preserves the permissions.
Q: When will this fix be included in a cumulative update so that I do not have to deploy an IU?
A: This fix will be included in Exchange 2013 RTM Cumulative Update 3.
Q: When will the IU be available?
A: The IU will be available shortly; we will update this article with the KB article number once is released.
Q: Why didn’t you test this scenario?
A: The short answer is we thought we did. We didn’t realize we missed validating the permission structure after the public folder mailbox move. The Exchange team has well over 100,000 automated tests that we use to validate our product before we ship it. With the richness and number of scenarios and behaviors that Exchange supports, automated testing is the only scalable solution. We execute these tests in varying scenarios and conditions repeatedly before we release the software to our customers. We also supplement these tests with manual validation where necessary.
Q: What are you doing to prevent similar things from happening in the future?
A: We are conducting an internal review of our processes to determine how to prevent issues such as this in the future.
We deeply regret the impact this has on our customers and as always, we continue to identify ways to better serve your needs through our regular servicing releases.
Principal Program Manager
Exchange Customer Experience