Veeam Backup for M365 ProxyPool-Swapper

  

 

If you regularly onboard new tenants in Veeam Backup for Microsoft 365, chances are this scenario sounds very familiar.

A repository gets assigned to a proxy pool, and at some point you want to move it—quickly and without hassle. A common approach is to use a dedicated onboarding proxy pool for the initial full backups of new tenants, and a separate, permanently assigned pool for ongoing operations. Once those initial backups are complete, only incremental, day-to-day changes remain. These smaller, predictable workloads can then be handled by a proxy pool that’s specifically designed and sized for daily processing.

From an architectural perspective, this makes perfect sense. From an operational perspective… it can get a bit tedious.

Another use case I frequently run into is the need to quickly access logs for a specific job or repository. To do this, I assign the repository to a local Windows proxy, which gives me easy access to the proxy logs. This approach works best for me. Because of that, I need to be able to assign a specific proxy to a repository, rather than jumping between all the proxies in the pool just to figure out which one handled the job. 

Automating proxy pool reassignment

To streamline this process, I put together a simple PowerShell script that removes the manual steps from the equation.

Here’s how it works:

1. You provide the name of a repository.

2. The script determines which proxy pool the repository is currently assigned to.

3. It then presents a list of all available proxy pools.

4. By selecting the corresponding number, the repository is reassigned from its current proxy pool to the newly chosen one.

No digging through the console, no repetitive clicks—just a clean, script-driven workflow.

The technical core

At the heart of this solution is the following PowerShell cmdlet:

Start-VBORepositoryOwnerChangeSession

This cmdlet initiates the repository ownership change and makes it possible to move a repository between proxy pools in a controlled and supported way.

For a full breakdown of parameters, behavior, and limitations, I highly recommend checking the official documentation in the Veeam Help Center.

Why should I use this ?

In environments with frequent tenant onboarding, small optimizations like this add up quickly. Automating proxy pool reassignment reduces operational friction, minimizes human error, and helps ensure your proxy resources are always used as efficiently as possible.

The script in action

When launched, you'll be asked to enter your repo-name for which you want to change the proxy-pool.

The script will search for the ID of the repo, the current assigned proxypool and will list all available proxy pools.  

You select the desired pool by entering the corresponding number of the pool. To double-check you must confirm the change.

Finally you get the confirmation and all the detailed information of the change. When watched closely, you'll see this job popping up in the active job queue. Of course, never change the proxy when a job is still writing to the repository. 

 

The PowerShell script: 

Alternative version 

This is a small modified script that allows me to change a repo from a proxy pool to a dedicated proxy. A function I frequently use when troubleshooting:

 

Regkey of the month: February

Full proxy control: EnableSameHostHotaddMode

This setting is a useful tool that helps you optimize and control the Virtual Appliance or HotAdd transport mode. This can be particularly useful in complex or hyper-converged infrastructures (HCI) to take control of how data flows.

 

What is EnableSameHostHotaddMode?

When Veeam uses HotAdd mode, the virtual disks of a source VM are directly attached to a Veeam Backup Proxy that runs as a VM itself. By default, the Veeam scheduler will attempt to find the most suitable proxy based on load and connectivity. Logically this is a proxy on the same underlying host as the machine you're backing up.

The registry key EnableSameHostHotaddMode forces Veeam to preferentially use a proxy running on the same ESXi host as the VM being backed up. This localizes backup traffic within the host, reducing network load and increasing speed. So there's less room for the Veeam scheduler which proxy will take and perform the task.

Why would you use this?

There's logic performed by Veeam to assign the most optimal Proxy resource. Shouldn't we just leave it to that ? The main reason to use this key is to prevent the infamous “VM stun” or temporary unavailability of virtual machines.
 

NFS Datastores (HCI): In environments such as Nutanix or Cisco HyperFlex, which use the NFS protocol, a HotAdd operation where the proxy is on a different host than the VM can cause file locking (LCK files) issues. This can result in a VM becoming unresponsive for several minutes while removing a snapshot from the backup action.
 

Network Optimization: By sending data directly from the host's VMkernel to the local proxy, you avoid having backup data travel across the physical network between hosts.
 

Storage Bottlenecks: In environments with limited bandwidth between hosts, keeping traffic and be able to force this local, helps ensure overall cluster performance.

Creating the key and the different values

To make optimal use of this feature, the first requirement is to install a Veeam Backup Proxy on each ESXi host in the cluster where the VMs to be protected are located. This can be a Linux or Windows based proxy role.

Setting the Registry Key

Configure the following registry key on the Veeam Backup & Replication server:

•  Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
•  Name: EnableSameHostHotaddMode
•  Type: DWORD (32-bit) This key can have different values (0,1 or 2)

Depending on how strictly you want to enforce the rule,  you can set the value on 0,1 or 2
 

0 (Default): Disabled. Veeam uses any available proxy, regardless of whether it is local or remote.

1 (Preference): Veeam prefers the local proxy. If the local proxy is busy, Veeam waits for availability. However, if the local proxy is completely unavailable, Veeam falls back to a HotAdd proxy on another host. Important remak: this can still cause a stun with NFS.

2 (Strict mode): Veeam enforces the use of the local proxy. If the local proxy is busy, Veeam waits. If the proxy is unavailable, Veeam switches to Network Mode (NBD) instead of using a HotAdd proxy on another host. This completely minimizes the risk of snapshot stuns.

Gerneral remark: After modifying or adding the key, the Veeam Backup Service must be restarted, or you must wait 15 minutes for the automatic scan to pick up the change.
 

Real-world examples

Must have for Cisco HyperFlex optimization

In a Cisco HyperFlex environment, it is recommended to set the value to 2. Because HyperFlex datastores operate via NFS, this strict setting prevents Veeam from choosing a proxy on another host that would temporarily take ownership of the VM files via the LCK file, which can cause application interruptions.

Getting maximum performance in a 1GbE cluster

An administrator notices that backups are slow because the 1GbE management network between hosts is becoming overloaded by HotAdd traffic. By placing a proxy on each host and setting the value to 1, most data remains within the host. Only in cases of extreme necessity (if a local proxy fails) does the data still travel over the network, drastically reducing the daily load.

Stability preferred over speed

In an environment with highly sensitive SQL servers on NFS storage, the administrator should choose value 2. When an ESXi host undergoes maintenance and the local proxy is down, the administrator prefers that the backup runs slower via Network Mode (NBD) than to risk the SQL server “freezing” during snapshot removal.

To conclude

The EnableSameHostHotaddMode registry key is an interesting setting for any backup administrator working with NFS-based storage or HCI solutions. Although implementing a proxy on each host requires more management, the benefits of a more stable infrastructure and faster backups. From my perspective more advantages than drawbacks.

 

Regkey of the month: January

Optimizing Veeam SQL Transaction Log Backups with SqlTempLogPath

First of all, happy new year !! Also in 2026 we continue with our regkey of the month series. 

Veeam Backup & Replication performs SQL Server transaction log backups by temporarily staging log data on disk before transferring it to the backup repository. In many environments, this staging location becomes a hidden bottleneck—causing failed jobs, disk-space exhaustion on system drives, or unnecessary performance degradation.

 

In this episode of "regkey of the month", I'll provide you with some more information of the hidden gem: SqlTempLogPath

We will cover internal behavior, real-world use cases, performance considerations, cluster implications, failure modes, and best-practice deployment guidance. 

For Veeam Backup & Replication v12 and later, the configuration of the SQL temp log path is managed using the following specific registry key:

• Path: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
• Name: SqlTempLogPath (REG_SZ (string))
• Default Value: Not set

SqlTempLogPath controls the temporary disk location where Veeam stores SQL Server transaction log backup files during log backup operations.

These files are staging artifacts—they exist only briefly:

1. SQL Server writes the transaction log backup
2. Veeam processes and transfers it to the backup repository
3. The temporary file is removed

By default, Veeam automatically chooses a location. In many environments, that default behavior is sub-optimal.

Default Behavior, when the key is not set

When SqlTempLogPath is not present, Veeam follows this logic:

1. Enumerates all local volumes on the SQL Server

2. Selects the volume with the largest amount of free space

3. Uses that volume as the staging location

4. Writes the selected path back into the registry

This means the registry value may appear even if you never created it manually.

Implication

If your SQL Server has a large but slow data volume or a system drive that temporarily has the most free space, Veeam may choose a non-optimal staging location that persists indefinitely.

Reasons why you should check this:

C: Drive Exhaustion

Many SQL servers are deployed with:

• Small system partitions
• Strict OS disk usage limits

Transaction log backups can spike unexpectedly and fill the drive, especially on environments with:

• High-write Online Transaction Processing (OLTP) systems
• Systems with delayed log truncation
• Long backup intervals (large build-up of logs)

Check it when you see performance Bottlenecks

SQL log backups are write-intensive and latency-sensitive.

If Veeam stages logs on:

• Slow HDD volumes
• Shared data LUNs
• Heavily contended disks

You may see:

• More time needed for the log backup
• Increased SQL I/O wait times
• Backup jobs overlapping production timeframe

Supported deployments

Know that this regkey can be used in:

Veeam Backup & Replication (VM-level SQL backups), Veeam Agent for Windows (SQL log backups)
Cluster-Aware SQL backups, AlwaysOn Availability Groups

Some personal guidelines:

Choose your path that is:

• Local (not a network share)
• Fast (SSD or high-performance SAN)
• Large enough to absorb log spikes
• Consistent across reboots (no random driveletter assignmentsn typical on USB drives)

Do not use: UNC paths, temporary removable storage (USB drives,...), volumes managed by external cleanup tools. I personal alway try to avoid the C-drive, when full the OS will hang and the whole machine will become unresponsive. 

Interesting to know: 

When the path becomes unavailable or read-only, Veeam will detect this and 'fallback' ont the new most suitable volume. The value of the registry will then be overwritten. To find out which location is used, you can check the logfiles of the job. These logfile is typical located at: