Author name: Managecast Technologies

When performing Veeam Explorer restores connecting to a service provider, sometimes these restores can fail with a Connection Failed message. Looking in the Veeam explorer logs there will typically be references to a version mismatch. Ex: 4/26/2023 1:10:47 PM 20 (11320) Connection failed4/26/2023 1:10:47 PM 20 (11320) Error: Incompatible Veeam Backup for Office 365 server version (received: 11.1.0.600, expected: 10.0.3). This is due to a different version of the Veeam explorer being installed on the tenant’s Veeam Backup and Replication server than the service provider’s Veeam for Microsoft 365 server. The solution to this is to download the same version of the Explorers currently installed on the service provider’s Veeam for Microsoft 365 server. This can either be downloaded from Veeam in the form of the Veeam for Microsoft 365 installer .iso or by contacting the service provider and asking for the individual Explorer installer .msi files. Once downloaded and installed. Try the service provider explorer again and the “Connection Failed” error should be gone.

Veeam does not support moving data between object storage buckets. Veeam has guides for: For the scenario where data needs to be moved from one object storage provider to another Veeam support will suggest performing a new full backup to the new repository. However, this will cause a loss of retention if the old bucket is not retained. Note: While we have tested the following method up to VB365 v7 and confirmed it has worked for our data, please be aware that this is an unsupported method for migrating Veeam for Microsoft 365 data. The following method will allow data to be transferred between object storage buckets. We will be essentially following the steps outlined in the first KB article noted above, KB2649, but instead of migrating to a new server the server will not change. You may get an error when trying to add the repository that the repository already belongs to another backup server. In that case, navigate to the RepositoryLock folder in the new bucket and delete the lock file located there. Finally, you can edit the backup job and point it to the new repository. The initial backup pointing to the new repository will take a while to complete depending on the size of your data. This first backup will be marked as a full, because it will be synchronizing the new repository with the production data, however it will still only transfer the changed data.

During an M365 Exchange mailbox restore using Veeam, the following errors can occur: Failed to open mailbox: user.name@domain.com Failed to access mailbox. Mailbox does not exist. The specified object was not found in the store. Default folder Root not found. You can find these additional events in the Exchange explorer logs: Validating if any of the required roles (Global Administrator, Exchange Administrator) is assigned to the current user: admin@domain.com… Error: The account does not have permission to impersonate the requested user. This is caused by missing permissions on the account performing the restore, specifically the ApplicationImpersonation role. To add this permission to the user account we have to connect to Exchange Online using the PowerShell module. The following commands will connect and add the proper role: Make sure to replace admin@domain.com with a global administrator account to run these commands. Then retry the restore and it should go through as expected.

We have run into issues where backups fail with the following message: Failed to pre-process the job Error: Sequence contains more than one element These seem to be related to disconnections to the backup storage or the repository storage filling up while the backups are running. There are a few different ways we have found to resolve these issues: