This article includes a list of errors that may arise during a public folder migration, as well as steps for resolution and any additional details.
"Access Denied" error on Exchange 2013/Microsoft 365 Destinations for Public Folder migration
Typically, incorrect permissions on the root Public Folder are the cause of "Access Denied" errors for an Exchange 2013/Microsoft 365 Destination.
Follow these instructions to set the correct permissions:
- Log in to the Exchange Administrative Center.
- Navigate to the Public Folders section (left menu).
- Click on the '...' action (the '...' only shows up once a Public Folder mailbox has been created).
- Select Root permissions.
- Add the administrator as an owner to the root Public Folders, and check the box for applying changes to all subfolders. Once this is done, you should no longer get the 'Access Denied' error when performing migrations.
Explanation and resolution
This error message can result for a variety of reasons depending on if the issue originates in the Source or Destination endpoint.
If the error is for the Source server, the most often seen reasons for this error are as follows:
- The source administrator account being used at the source does not have mailbox enabled
- The source administrator account does have a mailbox enabled, but it is not in a location on the source server that can see the public folder database or mailbox. Try moving the administrator account mailbox to the same database as the public folder database or mailbox.
ResolutionEnsure a mailbox is created for the source administrator account and that the public folders to be migrated can be access through the OWA mailbox for the account.
If the error is for the Destination server, the most often seen reasons for this error are as follows:
- The primary hierarchy public folder mailbox has not been created, or it has been created incorrectly using the steps outlined in your migration guide. Note: If your environment is set up for hybrid public folders, you should be using the migration guide here: Public Folder Migration Guide From On-Premises Exchange 2007+ to Office 365 (Hybrid Mode)
- The administrator account being used for the migration does not have a mailbox provisioned (This is required)
- The administrator account mailbox being used for the migration is does not have the DefaultPublicFolderMailbox set to the primary hierarchy public folder mailbox.
Review your configuration of the migration Destination. If all the above causes have been checked off as the cause, try the following:
- In the Exchange Admin Center, click on the Public Folders section.
- Click on '...' . Add the destination administrator account being used in the project as Owner. If there is a box for applying the permissions to sub-folders, make sure it is checked before saving.
- Create a test public folder on the same page where you just added the Owner permissions. Ensure that the test folder has inherited the Owner permission for your administrator account you just granted permissions to.
- If logged in as the administrator account being used for the migration, log out.
- After 30 - 60 minutes have passed, log into the OWA mailbox for the administrator account being used for the project and attempt to successfully add the test folder created in step 3 as a Favorite.
- If step 5 is successful, try resubmitting a Verify Credentials in your project.
Additional information relating to this error can be found in the following articles:
Unexpected error mail-enabling Public Folder "foldername"
Unexpected error mail-enabling public folder "foldername": Shell: exception while executing PowerShell. Cause: Shell: exception while executing PowerShell.
This error occurs for one of two reasons. First, it can happen when Microsoft 365 truncates the public folder name to fit mail enabled Name and Alias requirements. If the source public folder name is longer than 64 characters (including spaces), and the 64th character is represented by a space, Microsoft 365 will treat it like a trailing white space and not allow it to be mail enabled.
It can also happen if an attempt to mail-enable a Public Folder is made with an account that is not part of the "Organization Management" role group.
Instructions for resolution are in the below tabs based on the cause of the error.
Add-RoleGroupMember -Identity "Organization Management" -Member ""Example:
Add-RoleGroupMember -Identity "Organization Management" -Member "firstname.lastname@example.org"