Exchange 2013 RTM CU2 (712.22) Issue - Public Folder Permissions Loss After PF Mailbox Move

Published Jul 12 2013 12:40 PM 11.7K Views

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:

  1. 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.
  2. 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.


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.


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:


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


  • 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.
Not applicable

Guys, Exchange is doing great in market don't mess it up with such kind of mistakes. I said in earlier post also, test it properly. What is the rush?

Not applicable

I echo Amits sentiments.  If Microsoft are going to have such rapid release cycles at least ensure your regression and release testing don't routinely produce defective updates. The regularity of these faulty updates is very disconcerting.  

Not applicable

Please do proper testing before release.

Not applicable

Yes, This type of mistake they did in Exchange 2010 SP3 RU1 regarding multiple archive and transport rule issue.

i dont know when they going to fix. till date there is no update for it.

Not applicable

Despite past apologies and promises to improve process, here we are again. The Exchange Team has slowly but surely eroded the confidence I had in a product I have used for over a decade. IMHO something is broken at Microsoft, or at least in the Exchange Team.

Not applicable

...and then found this.

You guys seem to be working really hard to piss your customers off. I lost permissions on folders. I guess you don't care, apparently, as this CU2 download is still available for download. I guess we should plan accordingly: you do not feel that it isa big deal because what - you did no get many support calls?

Unbeliveable. What a mess...

Not applicable

Although the description above says this does not affect normal mailbox moves, it seems to do.

At least on my CU2 Installation all mailbox folder permissions on a mailbox root folder are lost everytime the mailbox is moved to a different database. Can anyone confirm this ?

Not applicable

Permissions in public folders has always been a bit primitive. Anyway, who uses public folders these days?

Not applicable

Just blast a full CU into production without testing?  Blame goes to both the admin choosing not to test as well as MS for issuing a buggy update.  MS is not solely at fault for your situation.

Not applicable

With this updated CU2 (712.24), are there additional schema changes that we need to be aware of? Do we need to perform the AD preperation steps before installing?

Not applicable

@Mike DiVergilio - there are no schema changes or AD Preparatory steps required if upgrading from 712.22 to 712.24.


Not applicable

Do we need to install 712.24 on source and target or only the target?

Not applicable

@H - you really want to install .24 on all servers involved, due to how move requests can be served within the organization.

Not applicable

"Despite past apologies and promises to improve process, here we are again. The Exchange Team has slowly but surely eroded the confidence I had in a product I have used for over a decade. IMHO something is broken at Microsoft, or at least in the Exchange Team."

Absolutely agree. something is definitely broken.

Not applicable

MS/Exchange developer always try to give their best, just blaming them doesn't make sense. Installing any update on live environment is not recommended. First test them on lab environment and inform MS for bugs/issues, these guys are always available to help.

Not applicable

"If you moved the primary PF mailbox, you will need to manually reassign permissions." Care to explain how to do that?

Version history
Last update:
‎Jul 01 2019 04:14 PM
Updated by: