Challenge
The following error occurs when backing up public folders: "Processing mailbox PublicFolderMailbox@xxxxxxxx.onmicrosoft.com failed with error: Failed to synchronize item changes in folder: FOLDERNAME.. Access is denied. Check credentials and try again., ICS synchronization failed.".Log files may contain the following information:
20.12.2012 07:55:14 16 (1448) Processing mailbox: PublicFolderMailbox@xxxxxxxx.onmicrosoft.com... 20.12.2012 07:55:14 16 (1448) Syncing folder items: FOLDERNAME... 20.12.2012 07:55:14 16 (1448) Exchange Web Services error code: ErrorAccessDenied 20.12.2012 07:55:14 16 (1448) Error: Failed to synchronize item changes in folder: FOLDERNAME. 20.12.2012 07:55:14 16 (1448) Type: Veeam.Ews.Internal.ExServerCodeException
In addition, Veeam Explorer for Exchange may fail to show successfully backed-up public folders.
Cause
Either of the following conditions may cause the error:- Public folders are not located under the IPM_SUBTREE folder.
- The Default user does not have permissions to access public folders.
Solution
The Public Folder is not Located Under IPM_SUBTREE
Veeam Backup for Microsoft Office 365 works with public folders located under the IPM_SUBTREE folder only. Other locations such as, for example, NON_IPM_SUBTREE are not supported.
To check if the public folder is located under the IPM_SUBTREE folder, run the following cmdlet and specify credentials used in Veeam Backup for Microsoft Office 365.
$creds = Get-Credential $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $creds -Authentication Basic -AllowRedirection Import-PSSession $Session Get-PublicFolder -Identity \ -Recurse | Format-List Name Remove-PSSession $session
An output similar to the following must be displayed:
Name : IPM_SUBTREE Name : PublicFolderMailbox@*********.onmicrosoft.com Name : FOLDERNAME Name : Second Sub Folder Name : Third Sub Folder
If, according to the output above, a public folder is located under the IPM_SUBTREE folder, no additional actions are needed. Otherwise, if the public folder is located under any other unsupported folder, make sure to move such a public folder to IPM_SUBTREE.
The Default User Does Not Have Sufficient Permissions
Veeam Backup for Microsoft Office 365 uses impersonation to back up public folders. When a public folder is created, it automatically inherits permissions from its parent folder. One of these permissions is assigned to the Default user and grants the Author access rights. In case when an Exchange administrator revokes granted permissions from the Default user, impersonation cannot be performed.
In case you do not want the Default user to have access to public folders and want to use the service account instead, make sure to assign either the Owner or Reviewer permissions to each of the public folders of the service account.
To see the accounts that have access to public folders and the permissions given, run the following cmdlet and specify credentials used in Veeam Backup for Microsoft Office 365.
$creds = Get-Credential $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $creds -Authentication Basic -AllowRedirection Import-PSSession $Session Get-PublicFolder \ -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,@{Expression={$_.User};Label="User";},@{Expression={$_.AccessRights};Label="AccessRights";} | Export-Csv C:\PublicFolderClientPermission.csv Remove-PSSession $session
The cmdlet saves information about users and permissions to the C:\PublicFolderClientPermission.csv file.
To grant access, you can do either of the following:
- Assign either the Owner or Reviewer permission to each of the public folders (and sub-folders) of the Default user.
- Add your service account to public folders with the Owner or Reviewer permissions, and disable impersonation.
$creds = Get-Credential $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $creds -Authentication Basic -AllowRedirection Import-PSSession $Session $folders = get-publicfolder "\" -recurse foreach($folder in $folders) { Add-PublicFolderClientPermission -Identity $folder.identity -user YourServiceAccount@*******.onmicrosoft.com -AccessRights Reviewer } Remove-PSSession $session
NOTE: It is recommended to use PowerShell to assign permissions to public folders.
The following table shows an example of users permissions after the cmdlet is executed.
Once the cmdlet is executed, make sure to disable impersonation for the service account. After impersonation is disabled, the service account will have direct access to public folders.
To disable impersonation, do the following:
1. Open the Veeam Backup for Microsoft Office 365 console and stop active backup jobs (if any).
2. Open the Services.msc console on a proxy server that is responsible for processing public folders.
To find out which proxy server is used, in the Veeam Backup for Microsoft Office 365 console, right-click a backup job, select Edit and go to the Specify Backup Proxy and Repository step.
3. In the Services.msc console, stop the Veeam Backup Proxy for Microsoft Office 365 Service.4. Create a backup copy of the C:\ProgramData\Veeam\Backup365\Proxy.xml file by copying it to another location.
5. Open the original Proxy.xml file using any text editor and add the <Source EwsImpersonatePublics="False" /> line between <Veeam><Archiver> tags.
Example: <Veeam> <Archiver> <Source EwsImpersonatePublics="False" /> ..... ..... </Archiver> </Veeam>
6. Save the Proxy.xml file.
7. Start the Veeam Backup Proxy for Microsoft Office 365 Service.
8. Open the Veeam Backup for Microsoft Office 365 console and run backup jobs with public folders.
NOTE: All PowerShell scripts provided above are intended to get and assign needed permissions automatically to ensure that no public folders are missed.
Please be aware that the commands and parameters may be altered by Microsoft in the future, which may cause thees scripts to function incorrectly.
There is no support provided for these scripts, and should they fail, we ask that you please contact Microsoft support.
These scripts may be updated in the future to reflect changes to the Office 365 PowerShell Environment.