Warning

Office 365 Backup, Veeam

Veeam for Microsoft 365 “User ‘USERNAME’ does not have a valid Microsoft 365 license with SharePoint plan enabled” Warning

If a user is set to back up a SharePoint but doesn’t have a SharePoint plan, you’ll start seeing warnings pop up in your Veeam for Microsoft 365 backups. There are two options for resolving the “User ‘USERNAME’ does not have a valid Microsoft 365 license with SharePoint plan enabled” warning. Option 1: Contact Microsoft to add a SharePoint plan to the current users’ license. Option 2: If the SharePoint site does not need to be backed up, or is not licensed to, then you can exclude the SharePoint for the user. Below are the steps to exclude a SharePoint for a specific user: If you are backing up your entire organization: If you have specific objects selected to backup: If the warning persist, please reach out to Managecast and we are happy to help resolve this and any other Veeam issues.

Office 365 Backup, Veeam

Veeam M365 “Cannot change web part export mode to ‘All’, because custom scripting is disabled for site” Warnings

When setting up your Veeam for Microsoft 365 backups, you may select to backup WebParts. If Custom Scripts are not enabled, you will likely run into the warning “Cannot change web part export mode to ‘All’, because custom scripting is disabled for site.” By default, both the “Allow users to run custom script on personal sites” and “Allow users to run custom script on self-service created sites” options are set to “Prevent.” Here are quick steps to get your web parts backing up successfully: Additional information can be found here at Veeam and Microsoft. If you’d like assistance resolving your Veeam for M365 warnings, please reach out to Managecast. We’re happy to assist in troubleshooting and resolving your issue.

Veeam

Troubleshooting Veeam Application-Aware Backups

Overview In order to get transactionally consistent backups Veeam is capable of using several methods of application-aware guest OS processing. In some cases, issues with application-aware processing can cause backups to fail. These issues can be caused by issues with Microsoft Volume Shadow Copy (VSS), SQL log processing and/or truncation, Hyper-V integration services, or VMware tools. Microsoft VSS VSS Writer Failures Sometimes Veeam can fail with errors similar to the message above. These are typically caused by failed VSS writers on the Guest OS. To check for any failed VSS writers run the following command: In most cases, a reboot will resolve failed writers. Although in certain scenarios the writers can fail again the next time the backup runs. An alternative to a reboot is to restart the services associated with the failed VSS writer. A list of these services can be found here: KB2041: Windows VSS Writers and Corresponding Service Names (veeam.com) VSS Storage Related Failures VSS requires free storage on the guest OS for space that can be used for storing shadow copies. The first thing to check is that there is enough free space on the volumes being backed up. Usually this is around 10% free space, but will depend on the rate of change and total size of the volumes. If there is enough free space on the volumes, the next thing to check is that the “shadow storage” is configured. To find this open command prompt as administrator and run the following command: Make sure that each volume included in the backups is listed with storage configured. If any of the volumes are missing add shadow storage for them with the following command: If any of the volumes with configured shadow storage are configured for less than 10-20%, they can be increased with the following commands: To store shadow copies on a different volume, change the /On=C: flag to the other drive. (For example if the C: drive was close to full but the D: drive had significant free space, the flag would be /On=D:) VSS Provider Failures Sometimes VSS providers can be left over from previous solutions that are no longer in place. In some cases, Veeam will run into problems initiating vss shadow copies when these providers are present. In most cases the fix for these issues is to remove the bad VSS provider. Run the following command to check what providers are installed on the system: This will output a list of the providers, take note of the GUID of non-Microsoft providers or any from unused solutions. Next, open regedit to the following key: Match the previous GUIDs with the keys in the registry. Right click the keys and export them as a backup. Then delete the matching keys. Next, restart the Volume Shadow Copy service (sometimes the machine must be rebooted for the changes to go into effect.) VSS Timeout Veeam has a knowledge base article with information on how to troubleshoot these types of warnings: KB1377: VSS wait timeout (veeam.com) Multiple VSS Applications Conflict Failed to create snapshot. Error code -2147212522. ‘Backup job failed.Error VSS error: VSS_E_SNAPSHOT_SET_IN_PROGRESS. Code:0x80042316 Both of these warnings indicate that there are multiple applications attempting to use the same writers at the same time. It is recommended that you adjusting the time that you run your backup to not interfere with other applications that utilize the same VSS writers. Veeam has a knowledge base article with information on how to troubleshoot these types of warnings:KB1784: 0x80042316 or Error: VSSControl: -2147212522 VMware Tools This warning message occurs when Veeam tries to perform application aware processing or guest indexing, but it cannot communicate with the Guest OS of the VM being backed up. By default, Veeam will try to communicate over the network from the Guest interaction proxy specified in the backup job. But if that fails, Veeam will try to communicate through VMware tools. This message is indicating that Vmware tools is either not installed or not running. Please make sure that VMware tools is installed and running on the affected VM. If it is installed, but not running, you can typically restart the service from Windows Services. If it fails to start, reviewing the Windows Application logs can provide info on what is causing the service to fail to start. Microsoft SQL Veeam has a knowledge base article with information on how to troubleshoot these types of warnings: KB2027: Job reports warning “Failed to truncate transaction logs for SQL instances: Possible reasons: lack of permissions, or transaction log corruption.” (veeam.com) Hyper-V Integration Error Guest processing skipped (check guest OS VSS state and integration components version) (System.Exception) Error: Hyper-V Integration Service is not accessible through the network on source host Veeam has a knowledge base article with information on how to troubleshoot these types of warnings: KB1855: Hyper-V Guest processing skipped (check guest OS VSS state and integration components version) (veeam.com) There is also a great blog post from Veeam on the process to install and setup the Hyper-V integration services: Hyper-V installation and configuration step-by-step (veeam.com)

Veeam

Issues Running Backups or Rescanning Repository After Veeam Upgrade

Just recently, right after upgrading to Veeam 9.5, we ran into an error with one of our customers that would show up whenever backups started to run and when we tried to rescan the Veeam repository. The errors messages were: Warning Failed to synchronize Backup Repository Details: Failed to synchronize 2 backups Failed to synchronize 2 backups Warning Failed to import backup path E:|PATH|TO|BACKUP|FILES|BackupJobName.vbm Details: Incorrect file system item link received: BackupJobName Based on the errors it looked like there were issues with the database entries for the backup job mentioned in the error. As a troubleshooting step we tried removing the backup files from the GUI under Backup & Replication>Backups by right clicking on the backup and selecting ‘Remove from Configuration.’ However, this ended up giving us the same error in a popup dialogue: Incorrect file system item link received: BackupJobName After opening a ticket with Veeam they informed us that this is a known issue caused by unexpected backup entries in the VeeamBackup SQL database. Namely, the issue backup jobs were listed in the database with a zero entry for the job ID or repository ID causing Veeam to not be able to locate the backup files. Because this involves the Veeam SQL database we are going to be making changes to the database so it’s best to back it up before the next steps. Here’s a knowledge base article from Veeam that shows the suggested methods to backing up the database. To determine whether there are any errant backup entries in the SQL database run the following query: SELECT TOP 1000 [id] ,[job_id] ,[job_name] ,[repository_id] FROM [VeeamBackup].[dbo].[Backup.Model.Backups] Under ‘repository_id’ you should see one or more of the backup jobs showing ‘00000000-0000-0000-0000-000000000000’ or ‘NULL’ as the id for job or repository. Any entries with this issue will need to be removed from the database in order to resolve the error. It’s best practice to save a backup of the SQL database before making any changes. If you’re unsure of how to back up the SQL database, follow Veeam’s knowledge base article.  After backing up the SQL database run the following query for each job with ‘00000000-0000-0000-0000-000000000000’ as the repository_id: EXEC [dbo].[Backup.Model.DeleteBackupChildEntities] ‘REPLACE_WITH_ID’ EXEC [dbo].[Backup.Model.DeleteBackup] ‘REPLACE_WITH_ID’ Replacing the ‘job_id’ with that of any backups with the unexpected ‘repository_id’ found with the previous query. After that issues with the local backup server was resolved. However, we were still seeing errors when trying to connect the backup server to our cloud connect repository to do backup copies. We were still getting the following errors: Warning Failed to synchronize Backup Repository Details: Failed to synchronize 2 backups Failed to synchronize 2 backups Warning Failed to import backup path E:|PATH|TO|BACKUP|FILES|BackupJobName.vbm Details: Incorrect file system item link received: BackupJobName In order to resolve this we had to remove the entries for the problem jobs from the cloud connect server database. For those using a cloud connect service provider you will have to have them make changes to the SQL database. We had 2 VMs that were giving the ‘Incorrect file system item link received: JobName” error. So we had to remove any entries for those jobs from the SQL db. We ran the following query to get the Job ID of both jobs mentioned in the errors: SELECT TOP 1000 [id] ,[job_id] ,[job_name] FROM [VeeamBackup].[dbo].[Backup.Model.Backups] Then we ran the same delete query as before using the new job_id’s: EXEC [dbo].[Backup.Model.DeleteBackupChildEntities] ‘REPLACE_WITH_ID’ EXEC [dbo].[Backup.Model.DeleteBackup] ‘REPLACE_WITH_ID’ After those entries were deleted we were able to rescan the repository. Lastly, once we rescanned our cloud repository and imported the existing backups we started getting the following error message: Warning Failed to import backup path E:|PATH|TO|BACKUP|FILES|BackupJobName.vbm Details: Path E:|PATH|TO|BACKUP|FILES|BackupJobName2016-11-21T220000.vib is absolute and cannot be added to other path This error indicates that there is a problem where the backup chain isn’t accurately resolving the location of the GFS restore points. In order to resolve this we had to manually remove the Imported backups from the cloud connect server by going to Backup & Replication>Backups and selecting the backup job and choosing ‘Remove from Configuration’ making sure to check ‘Include archived full backups.’ After the backups had been removed from the cloud connect repository we were able to manually rescan the repository on the local backup server and the backup files were imported again successfully. Update:  After deleting these affected rows using the commands above you may get the following error message: Unable to map tenant cache ID ‘ID-GOES-HERE’ to service provider side ID ‘ID-GOES-HERE’ because it is already mapped to ID ‘ID-GOES-HERE’ If you do see this error a solution can be found in this Veeam KB article. Essentially, the data for these deleted rows still exists in the Veeam DB cache table and needs to be removed. In order to do this run the following query on the VeeamBackup database: delete from [cachedobjectsidmapping] This will delete the DB cache table. In order to re-populate it you will need to rescan the service provider and the Cloud Repository.

Scroll to Top