Challenge

If a Virtual Machines MoRef is changed due to migration to new vCenter / inventory change in vCenter, you would receive the error "Object "vmname" is not found". Please see KB1299 for more details.

This utility is designed to assist in re-mapping the MoRef ID's of the Virtual Machines you are backing up and/or replicating using Veeam Backup & Replication, so that backup incremental chains remain intact, after an inventory change in VMware vSphere vCenter. Do not run any jobs before using migration tool otherwise migration process won't be possible.

Please note that this utility is provided as a courtesy, and is not supported by Veeam Technical Support. Use at your own risk.

This tool cannot fix jobs targeting a Cloud Connect repository. You must perform and Active Full backup.

Important! If you are migrating to a 6.5U2 VCSA, VMware has a new migration utility, which could preserve existing VM MoRef IDs:
https://blogs.vmware.com/vsphere/2016/09/vcenter-server-migration-tool-vsphere-6-0-update-2m.html
https://blogs.vmware.com/vsphere/2017/01/vcenter-server-appliance-6-5-migration-walkthrough.html
This VMware utility only works for a 5.5 VC to a 6.5U2 VCSA!

Cause

Veeam Backup & Replication tracks Virtual Machines in its jobs by a Managed Object Reference ID (MoRef), which will change when moved to another vCenter, or removed and re-added to inventory.

Solution

Please download this bundle: tool and instructions.
Before using this tool, it is highly recommend to take a configuration backup of your VeeamBackup database.

Note:

• The utility will work only with a source vCenter migration. If Replication target vCenter is changed, you will need to manually map source VMs to their replicas.
• If for some reason you have already added the new vCenter or ran any jobs which will have added new Ref-IDs to the database, you can roll the Veeam Backup & Replication database back using the Configuration Restore function.

If you use the VMware provided VCSA Migration tool, you will need to remove and re-add VMs to jobs manually through the new VCSA after adding it to Veeam.

VMware highly recommends migrating to a VCSA, as they are phasing out the Windows based vCenter.
https://blogs.vmware.com/vsphere/2017/08/farewell-vcenter-server-windows.html

More Information

Challenge

Cause

• Backup of failover clusters is supported in Veeam Agent for Microsoft Windows managed by Veeam Backup & Replication only. You cannot process a failover cluster by Veeam Agent for Microsoft Windows operating in the standalone mode.
• Agent license with a server counter must be installed in Veeam Backup & Replication to enable Agent Management features including failover cluster support.
• Veeam Agent for Microsoft Windows supports Windows Server Failover Clusters running Microsoft Windows Server 2008 R2 and later.
• Workgroup clusters, multi-domain clusters, Windows Server 1709 core edition clusters, and mixed OS version clusters are not supported.
• Cluster Shared Volumes (CSV) are skipped automatically during the backup.
• The following Microsoft Failover Cluster applications are supported: Microsoft SQL Server Failover Cluster Instances (Microsoft SQL Server 2008 SP4 or newer), Microsoft SQL AlwaysOn Availability Groups, Microsoft Exchange Database Availability Groups (Microsoft Exchange Server 2010 or newer).
• Microsoft Exchange Database Availability Groups should be protected by independent managed by backup server jobs with server type.
• When using Basic Availability Groups on Microsoft SQL Server 2016 Standard Edition, consider that secondary replica node cannot be backed up because the secondary node is not readable. See the following article for more information.
•  AlwaysOn Availability Groups based on multiple Failover Cluster Instances are not supported.
• AlwaysOn Clusterless Availability Groups are not supported.
• Managed by backup server job with failover cluster type does not support the file-level backup mode.
• Recovery must be performed via Veeam Backup & Replication console.

Solution

Microsoft Windows Server Failover Clusters, Microsoft SQL Server Failover Cluster Instances, SQL Always On Availability Groups

Microsoft Exchange Database Availability Group

Challenge

Cause

Solution

• Additional Hypervisor support vSphere 6.7. VMware vSphere 4.0 and later (including vSphere 6, vSphere 6.5, and vSphere 6.7) 
• Monitoring SQL Transaction Log Backup Job. Veeam MP separately monitors SQL Transaction Log Backup jobs running inside backup jobs with the enabled application-aware processing option. For this purpose, Veeam MP includes a new Veeam SQL Transaction Log Backup Jobs view and Veeam Backup: SQL Transaction Log Job Status monitor.
• Improved performance of Morning Coffee Dashboards. In previous versions, Morning Coffee Dashboards tended to load slowly for large-scale environments. In Veeam MP 8.0 Update 6, the performance of Morning Coffee Dashboards has been significantly improved.
• New metric for Veeam VMware Collector. Due to the Ops Mgr Health Service (Monitoring Agent Service) limitations that appear when a Veeam VMware Collector processes a large amount of data, it is required to distribute monitoring load among multiple Veeam VMware Collectors in large environments. To assess monitoring load on Veeam VMware Collectors more precisely, Veeam MP provides a new % Object Monitoring Load metric.

• No monitoring for Hyper-V hosts that exceeded license limit. Veeam MP license limits the number of Hyper-V hosts enabled for monitoring in Ops Mgr. Earlier, if the number of licensed Hyper-V hosts was exceeded and new hosts were added to the Ops Mgr infrastructure, Ops Mgr automatically stopped monitoring the old infrastructure and started monitoring the newly added hosts. In Veeam MP 8.0 Update 6, the issue was resolved, and Ops Mgr continues monitoring the old infrastructure.
• Ops Mgr event log shows excessive BackupCopyJobSessionFinished events. In previous versions, the Ops Mgr event log contained a large number of 3101 events caused by errors in backup copy job status collection process. In Veeam MP 8.0 Update 6, the issue was resolved.

• Collector Autodeploy limitations. If you use the Collector Auto-Deployment feature to automatically deploy Veeam VMware Collectors on Management Servers, keep in mind that it will install clear 8.0 version without patches. When installation completes, run the ISO\Update\VeeamMP80_Update6.exe installation file on each Veeam Collector to install patches.  
• Veeam MP for Hyper-V stops collecting storage metrics. If a storage migrates to another volume, the storage performance collection will halt and Veeam MP will stop collecting the following metrics: Storage IOPS, Storage KB Total/sec, Storage Flush Count and Storage Error Count. Note that this issue does not affect migration between hosts. To work around the issue, restart the Ops Mgr agent after storage migration.

More Information

Challenge

25/07/2018 10:05:17 PM   61 (6188) Error: Specified argument was out of the range of valid values.
25/07/2018 10:05:17 PM   61 (6188) Type: System.ArgumentOutOfRangeException
25/07/2018 10:05:17 PM   61 (6188) Stack:
25/07/2018 10:05:17 PM   61 (6188)    at Microsoft.SharePoint.Client.ChunkStreamBuilder.ReadonlyChunkStream.set_Position(Int64 value)

Cause

Solution

Challenge

Solution

 Implementation step 1 - Backup & Replication  

1. Use a new Windows Server and install Veeam Backup & Replication v9.5 Update 3a or newer if you do not have a Veeam Backup Server. The Server can run within any VMware cloud on AWS SDDC, AWS S3 or on-premises environments, if the network connection to the VMC vCenter/Veeam Servers potentially the VMs (for Guest processing) is possible.
2. Add DNS network settings so that this Server can resolve Internet DNS names to be able to resolve the fully qualified domain name of the VMC vCenter server
3. Check the below information carefully for any known limitations and configuration steps before you proceed.

Implementation step 2 - VMware Cloud on AWS

Firewall Configuration for vCenter connection

1. Usage of the vCenter public IP for customers with NSX-v (default) 
   • Open Port TCP 443 from Backup Server and Proxy Server to the predefined vCenter object on the Compute Network.
   • Allow the Compute Gateway Public IP to communicate over TCP 443 with the predefined vCenter object on the Management Network.
     
2. Usage of a VPN tunnel for customers with VMware NSX-v 
   To be able to directly access the vСenter within VMC, please follow the VMC internal guidelines to create a VPN tunnel from the compute network to the management network: https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws.getting-started/GUID-30BED7B3-D312-4DF3-BD7A-66F8D1C619DC.html
   Please update your DNS Servers to resolve the FQDN of the vСenter to its private IP address. If you want to use hosts entries on the Veeam Server for it, add them on all Veeam Backup and Proxy Servers.
   If your Backup & Replication (Management) Server is outside of the VMC cluster, please implement the same VPN connection for it.
3. Usage of the local connection for customers with VMware NSX-t 
   NSX-t allows VMC customers to directly access the management network over the built-in firewall. TCP Port 443 needs to be opened from all Veeam Backup and Veeam Proxy Servers as a Source with the vCenter internal IP as a target.
   a) Configure DNS entry of the vCenter for local IP address usage.

   Go to your SDDC Management – Settings – vCenter FQDN and select the Private vCenter IP address.
   Hint: If you configure the vCenter DNS record for the internal IP address, you will lose VMC connection from Backup and Replication Server outside of VMC. You can use the local hosts file or any other DNS method to resolve the vCenter FQDN with the public IP address on the Veeam Server outside of VMC. Optionally, use the Public IP address for the VMC internal and external Veeam Server.

   b) Open firewall ports for vCenter Server access

   On the Management Network
   
   On the Compute Gateway
   

1. Create a vCenter User with required rights (Active Directory linked mode) described here, or use the cloudadmin@vmc.local user.
2. When adding a vCenter server, specify the fully qualified domain name (FQDN) that ends with vmwarevmc.com or vmc.vmware.com (depending on the URL shown in the VMC interface for the vCenter).

1. On the Compute Network:
   1. Open TCP 22 (SSH) port from Veeam Backup server and Veeam proxy server to the Amazon VPC where the EC2 Server was installed. You can as well define the exact IP addresses of the repository server as Destination.
   2. Open TCP 2500-5000 ports for Veeam Data Transport in both directions for same servers. It is recommended to use the VMware Cloud on AWS integrated high throughput/low latency ENI network connection to avoid any traffic costs.
2. Open the same ports on the Inbound Firewall of the Amazon EC2 server used as a repository server. As the Firewall Rule Source you should add all Veeam Backup Servers (including Proxy/Repository/MountServer/Console/…) instead of 0.0.0.0/0                                                                                                                                                                 

1. Veeam Backup Copy Job to a second EC2 Server used as an additional Repository. The second EC2 Server can be placed on another AWS Availability Zone or AWS Geo Location.
2. AWS Storage Gateway Software in VTL mode can be used to emulate a Tape Library to write data to S3. Veeam Backup to Tape Jobs can be used with it. For details see: https://www.veeam.com/wp-using-aws-vtl-gateway-deployment-guide.html
3. Veeam Backup Copy Job to on premises or Veeam Cloud Connect (Enterprise). There is no special configuration needed for this use case beside network and firewall connections. For standard Repository usage on premises it is recommended to create a VPN tunnel from VMware Cloud on AWS to the on premises datacenter. This can be done by the VMC integrated VPN functionality, by Veeam PN or Third Party.

1. VMware Cloud on AWS used as Restore target. 
   1. Implementation steps 1-4 are needed.
2. Veeam VM Replication.
   1.  Implementation steps 1-5 are needed. The Repository Server (when NOT used for Backups, can run within the VMware Cloud on AWS SDDC to store the Veeam Replication data. On premises to VMC, VMC to VMC and VMC to on premises is possible. Usage of Veeam Availability Orchestrator is possible in specific scenarios, see VAO deployment guide: https://helpcenter.veeam.com/docs/vao/deployment/welcome.html?ver=10

More Information

VMware Cloud on AWS specific problems and solutions:

Problem

Solution

1. Create a vCenter User with required rights (Active Directory linked mode) described here, or use the cloudadmin@vmc.local user.
2. When adding a vCenter server, specify the fully qualified domain name (FQDN) that ends with vmwarevmc.com or vmc.vmware.com (depending on the URL shown in the VMC interface for the vCenter).

Problem

Solution

• vsanDatastore datastore
• Management VMs folder
• Mgmt-ResourcePool resource pool

Problem

Solution

Problem

Solution

Challenge

You have backup files on a standard repository that you wish to move to a Scale-Out Backup Repository (SOBR).

Cause

Scale-Out Backup Repositories have special considerations for how backup files and metadata are distributed. Thus, simply copying files to one extent may be insufficient for a rescan of the repository to detect them properly and import them.

Solution

IMPORTANT: This process does not apply to Cloud Connect, and should not be used by providers. If you are a provider attempting to migrate tenant data to SOBR, please contact support for assistance.

If you have not yet created a SOBR:

1. Create simple repositories, and at least one of them should be a path where backup files to be imported are stored (e.g., if backup files are in D:\Backups\Backup_Job_1\ then create a repository referencing the path D:\Backups).
2. Re-scan the simple repository or repositories, and ensure all backups are imported.
3. Create the SOBR and add the relevant repositories as extents.
4. Within the creation process Veeam will inform via confirmation prompt that “Jobs and backups using this extent will be automatically updated to point to the scale-out backup repository.”
   
5. If any jobs are not mapped to the backup files now within the SOBR, map them per the standard process.

If you have a SOBR and need to introduce new backups:

1. Place the backup files to be imported in a temporary path. (e.g., if backup files are in D:\Backups, either copy or move them to D:\Backups-temp. A move is usually much faster.)
2. Create a new simple backup repository that references this path (in our example, D:\Backups-temp).
3. Re-scan the repository, and ensure all backups are imported.
4. You can map the pre-existing job to the backup files’ new location now, or at the end.
5. Edit your existing SOBR and add the new temporary repository to its list of extents.
6. Place the new temporary repository extent in “Maintenance” mode.
7. Evacuate the extent. Veeam will redistribute the backup files to other extents in the SOBR.
8. If you did not map the original job in step 4, do so now.

If redistribution of files is not desired or necessary, you can simply copy the folder containing VBM and backup files to an existing extent. Rename both path and VBM to ensure import, and re-scan.
 

If you need to move a backup from SOBR to a simple backup repository:

1. If you haven't done so yet, create a new simple backup repository.
2. In the root folder of the new simple backup repository, create a folder with the name of the job folder on SOBR.
3. (Optional) To avoid automatic rescans of SOBR finding the files during the move again, place the extents with the job files in "Maintenance" mode.
4. Remove the SOBR backup from Backups->Disk using the option "Remove from configuration" (not "delete from disk"!).
5. Move all VRB/VBK/VIB backup files from the folders of the job from all extents into the newly created folder on the simple backup repository.
6. Move one of VBM files from any job folder on SOBR to the newly created job folder on the simple backup repository.
7. Remove the leftover folders with the job name and VBM files from all extents of SOBR.
8. Rescan the simple backup repository. It will import the backup into configuration.
9. (Optional) Map the job which you want to use for this backup to the newly imported Backup.

More Information

Note that if the VBM or the path to it does not conform to naming standards, Veeam Backup & Replication will fail to import it.

• Allowed alphanumeric characters: a-z, A-Z, 0-9
• Allowed special characters: _ - . + = @ ^
• The path and .VBM file must not contain spaces. If the path or the .VBM file contain spaces, replace them with underscores.

 Moving backup files from one or multiple SOBR extents is viable as well. There are a few points to note:

• Make sure to copy files from the backup chain from all extents.
• SOBR backup chains are typically per-VM backup files. Simple repositories are typically per-job backup files. The chain will retain this method until an active full is run on the job to enforce the change.
• The VBM file will exist in all extents. All VBMs for a particular backup job within a single SOBR should be identical. As a result, the target simple backup repository needs only contain one VBM.

Challenge

Product Information:

Product Family: Fujitsu ETERNUS CS800 VTL
Status: Veeam Ready - Tape
Classification Description: Tape solution where available hardware features have been tested to work with Veeam.

Cause

Product Details:

Model number: S7
Library Firmware Version 3.5.0_S7
Drive firmware version: NA
Driver for tape drive: IBM Corporation, Driver version: 6.2.6.6
Driver for media changer: Microsoft, Driver version: 10.0.14393.0
Media type tested: LTO5
General product family overview:
FUJITSU Storage ETERNUS CS800 is a turnkey data protection appliance and provides a simple and affordable solution for customers which follow a disk backup strategy with deduplication.

Veeam Details:

Veeam Build Number: 9.5.0.1922
 

More Information

Company Information:

Company name: Fujitsu Limited
Company overview: Fujitsu is the leading Japanese information and communication technology (ICT) company, offering a full range of technology products, solutions and services. Approximately 156,000 Fujitsu people support customers in more than 100 countries. We use our experience and the power of ICT to shape the future of society with our customers.

Challenge

This article provides a method to change the repository where backup files are stored.

Solution

Important! If you have attempted to manually import the backup files using the Import button in the ribbon prior to performing the steps below you must first "Remove from configuration" any backups that were manually imported. These will identifiable in the Backups > Disk (Imported) section, they will be listed with the suffix _imported and will have no repository listed in the Repository column.

There are two primary situations and respective methods that this KB article documents.
Below is a summary of both methods.

Method A:
You have physically moved the backup files to new storage and want to map the old jobs to the backup chain in the new location.

Method B:
You are seeding a job, or you want to map a job to a backup chain in a new location. This method does not require that the job doing the mapping be the same as the job which created the restore points initially.

Method A: Same Job, New Backup location

1. In [Backup Infrastructure] > [Backup Repositories], create a new repository for the new location where backup files will be located.
2. Manually move the backup files to the new repository path. You must include the metadata file (.vbm), full backup files (.vbk), and any needed incremental files (.vib or .vrb).
   
   Notes:
   • It is recommended to move all backup files, but you can omit incremental files if needed. If you decide to not move/copy all backup files to the new storage, you will need to use the “Forget Missing Restore Points” function to clear any references to backup files that were not moved/copied.
   • Also keep in mind that there will be folders created inside the directory/path for job names.
     If your repository path is set as E:\Backups, Job A will go to E:\Backups\Job A.
3. Rescan the new repository.

4. If the backup files are not encrypted, skip this step.
   If the backup files are encrypted, the encrypted backup will appear under the Backups > Disk (encrypted) node in the inventory pane. In the working area, select the imported backup and click Specify Password on the ribbon or right-click the backup and select Specify password. More Information This is also relevant for encrypted Veeam Agent backups.
5. Edit the Backup\Backup Copy Job. Go to the Storage\Target tab, and from the drop-down menu, select the new repository.

6. Press Finish to finalize the setting. If you no error occurs, and the job now lists the new repository in its Repository column, the mapping has been completed.
   Note: If you encounter the following error: “Move all backup files to the new backup repository first”, some restore points the software was expecting to find were not found in the new repository. Cancel out of the job configuration and check both the old repository location and the new location to verify that all restore points have been moved. Then return to step 3 again.

If the steps above do not work, and you still get stopped at the "Move all backups files to the new backup repository first" error, please contact Veeam Support. You may also attempt Method B below.

Method B: New Job, New Backup location

To map the existing backup files to a new or different job, follow these steps:

1. Under Backups > Disk, right click the job you are changing repository for, and do either Remove From Backups (v8) or Remove from Configuration (v9).

2. If you are mapping the backup set from one job to another, but the backup location will stay the same, skip this step.
   If you are moving the backup files to a new location create a new repository for the new location where backup files are located.
3. Rescan the repository where the backup files are located.

4. If the backup files are not encrypted, skip this step.
   If the backup files are encrypted, the encrypted backup will appear under the Backups > Disk (encrypted) node in the inventory pane. In the working area, select the imported backup and click Specify Password on the ribbon or right-click the backup and select Specify password. More Information This is also relevant for encrypted Veeam Agent backups.
5. Edit the Backup\Backup Copy Job. Go to the Storage\Target tab, and from the drop-down menu, select the repository where the backup files you wish to map are located.

6. Click Map Backup and select the existing backup chain

If you are attempting to seed failover cluster Veeam Agent for Microsoft Windows job’s restore points please follow the actions below (it has a bit different workflow due to the product design):

1. Clone the source cluster job
2. Remove the source job (it will also remove from configuration its points; not from the disk but from Veeam config only)
3. Move the source backup folder to a new backup folder;
4. Rescan the new repository to import the moved files
5. Change the cloned backup job to the new repository and map the imported points there

More Information

Challenge

Cause

Solution

Challenge

There is a need to create a stable backup of your VCSA or restore it properly.

Solution

VCSA with Embedded Database:

Backup:

To backup the VCSA with Veeam, it's important to understand that Veeam does not directly support Postgres SQL (VMware's embedded DB). Instead, it's optimal to perform backup in 2 parts:

1. Image Level Backup with Veeam
2. Database backup via VMware Best Practice

Part 2 is not required, however, but please beware that restoring the image-level backup ensures the same state the Database was in at the point in time of the backup. VMware Best Practice shows to backup the database as regular maintenance. Then you would be able to restore the server from step 1, then restore the database to whichever point in time with the backup from step 2.

To backup the VCSA with Veeam (step 1):

1. Create a typical backup job
2. Enable VMware Tools Quiescence
3. Ensure Application-Aware Processing and Guest File System Indexing are either disabled or excluded for the VCSA VM.
4. Customize other settings to desired configuration.

To backup the VCSA Database (step 2):

1. See this VMware KB on how to backup the database.

Restore:

When restoring the VCSA, there are some Considerations and Limitations from VMware. Once you understand the considerations and limitations, it's important to understand how to restore your vCenter when there is no vCenter in which to point Veeam. Then you are ready to perform a Full VM Restore or Instant VM Restore.

Once the VCSA is fully restored, if database backups were created, you are now ready to restore the Embedded Database to the desired point in time using the steps mentioned in the above KB.

VCSA with External DB

Backup:

Backup is the same as above with the difference that you may also create an image-level backup of the database server if you so choose. The benefit here is that you may restore the entire VM to a specified state. This state will be of the time in which the image backup was created and without capability of point-in-time database restores. 

For Microsoft SQL and Oracle databases, Veeam can perform log backups to provide point-in-time restores. 

1. For requirements, details, and how to enable log processing for Microsoft SQL, click here.
2. For requirements, details, and how to enable log processing for Oracle, click here.

RESTORE

The restore process is yet the same as the previous steps with these exceptions:

1. VCSA requires the database to function. If needed, the database/server should be restored first.
   1. Server restore:
      1. Instant VM Restore
      2. Entire VM Restore
   2. Database restore, if Veeam was used to backup the database transaction logs you may restore with their corresponding tool:
      • Veeam Explorer for Microsoft SQL Server
      • Veeam Explorer for Oracle
2. Once the database is restored you can restore the VCSA via Full VM Restore or Instant VM Restore.

Challenge

Cause

Solution

More Information

Challenge

Cause

Processing of vSphere FT VMs is not supported in conjunction with vSphere 4.x or 5.x. With vSphere 6.x and Veeam Backup & Replication 8 u2, FT VMs are supported.

Please see the following article for more details: https://www.veeam.com/blog/veeam-availability-suite-update-2-vsphere-6-support-endpoint-and-more.html.

Solution

Update to both Veeam Backup & Replication 8 u2 and vSphere 6.x to enable support for FT VMs.

More Information

VMware Fault Tolerance & Snapshots: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016619

VMware vSphere 6.0 Platform White Paper: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/vsphere/vmw-white-paper-vsphr-whats-new-6-0-pltfrm.pdf

Challenge

VSS fails with the following error:
 

Starting guest agent.
Error while executing VIX command: [RPC function call failed. Function name: [IsSnapshotInProgress].
RPC error: There are no more endpoints available from the endpoint mapper.
Code: 1753].

Cause

The error is coming from the Windows guest. RPC is not function correctly.

Solution

Before running a job, make sure that the VeeamVssSupport service is not running on the guest VM(s); stop the service manually if it is running. 

Troubleshoot RPC Endpoint Mapper errors using Windows Server 2003 Support Tools from the product CD: http://support.microsoft.com/kb/839880

Sometimes this error is caused by a firewall disconnecting the TCP connection between the two machines. Make sure you have configured dynamic port allocation: http://support.microsoft.com/kb/154596

Challenge

Cause

Solution

More Information

Challenge

Cause

Solution

More Information

Challenge

A license file installed to your Veeam software replaces the information from the previous license. A merged license file allows for increased socket capacity by combining licenses from multiple Support IDs.

Please note that the merged license key will use the earliest support expiration date of all product keys.

Solution

NOTE! Licenses can be merged only when they have the same:

• Account Name
• Product Name and Edition
• Product Version
• Licensing Terms
• License Administrator
• They must all be Active on Support.

Your License Administrator may obtain a merged license file by following the steps below.

1. Log on to the Veeam My Account dashboard and go to License management >> Production Licenses (https://my.veeam.com/#/licenses/production)
2. In the Action column for the appropriate product, select Merge
   
3. From this page, select each of the boxes to the left of all the individual licenses you would like to merge
   
4. In the box that appears below, select the appropriate version of the key for your software and whether you would like to download the license directly or have a copy of the key emailed to your License Administrator email.
   

More Information

Please note that the license auto-update feature does NOT correctly update merged licenses created on the license management portal. If you have enabled auto-update, disable it before installing a merged license from the license management portal.

Challenge

Cause

Solution

Challenge

Processing <vmname> Error: The name '<vmname>_replica' already exists.

Cause

Solution

• Configuring Replica Mapping for the existing replica named in the error message. This will allow the Replication job to reuse the existing replica.
• Delete the existing replica VM named in the error. This will allow the Replication job to create a new replica VM.

More Information

Challenge

This article documents how change the temporary staging location where SQL transaction log backups are stored during a Veeam Agent for Windows backup operation when Transaction Log Backup is enabled.

For more information on the Transaction Log Backup process for Veeam Agent for Windows please click here.

Cause

When SQL Transaction Log Backup is enabled, Veeam Agent for Windows copies transaction log files from the log archive destination (set by the Microsoft SQL Server administrator) to a temporary folder on the server. By default the path is: C:\ProgramData\Veeam\Endpoint\SqlLogBackup.

Solution

To change the location where the SQL Transaction Logs are temporarily stored, create the following registry entry on the server.

Note: This registry change is to be made on the machine where Veeam Agent for Windows is installed, and is running the backup with SQL Transaction Log backup enabled.

Key: HKLM\SOFTWARE\Veeam\Veeam Endpoint Backup
Type: REG_SZ (String Value)
Name: SqlTempLogPath
Value: Path to desired location (without trailing backslash)

Example

More Information