Update 7/29/13: This issue has been addressed in the updated release of Exchange 2013 RTM CU2, build 712.24, which can be obtained via the Download Center.
On July 11th, we became aware of a specific issue with Exchange 2013 RTM CU2 (712.22). 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. To resolve this issue, deploy the updated build of Exchange 2013 RTM CU2 (version 712.24), which is now available on the Download Center.
Questions/Answers
Q: What if I have already deployed CU2 (712.22) 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. Don’t move any more public folder mailboxes until you upgrade to CU2 build 712.24.
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 with the 712.22 build, 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 with the 712.22 build, 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 is now included in an updated build of Exchange 2013 RTM Cumulative Update 2, build 712.24.
Q: When will the IU be available?
A: An IU will not be available as we decided to update the CU2 build to include the fix.
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.
Ross Smith IV
Principal Program Manager
Exchange Customer Experience
Updates
- 7/29/13: Updated recommendation and Q&A sections to include information about installing Exchange 2013 RTM CU2 build 712.24 to resolve the issue.
