I recently found myself writing a script using the Veeam Powershell Module. The use-case was fairly simple: accept VMs via CSV input and run a full VM restore to a new location with new settings using the last-created restore point for each VM.

All the other work aside, the command being run for each VM ended up looking like:

Start-VBRRestoreVM -RestorePoint $restorePoint -Server $server -Datastore $datastore -SourceNetwork $sourceNetwork -TargetNetwork $targetNetwork -VMName $VMName -Reason $reason -PowerUp:$true

This wasn’t the most difficult solution to arrive to. While working to reach this eventual solution, I attempted to use -TargetNetwork without specifying -SourceNetwork. This threw and error and eventually led me to read some docs. The Veeam Powershell Reference for Start-VBRRestoreVM shows that when referencing one of -SourceNetwork or -TargetNetwork the other needs to be supplied as well.

I began testing various restores on a simple VM and the restores were successful. While looking at some of the finer details, I found that the -TargetNetwork was not being honored for some of the restores. Instead, -TargetNetwork was being set to the original network assigned to the VM when it was backed up (for a given restore point, that is). I recognized this as problematic – this could effectively put a duplicate VM into production and cause issues.

A quick solution to this might be just to remove the -PowerUp:$true parameter and then make the necessary changes in vCenter before powering the system on. This requires some manual intervention (for how I’ve chosen to write the script, at least). I wanted to figure out exactly why Veeam was assigning the original network when restoring the VM. I attempted to set -SourceNetwork to any network available in vCenter but found the same error. Only when the VM was set to that network in the selected Restore Point was the -TargetNetwork parameter honored.

I did some digging in the Veeam log files. I found references to all of the inputs for the Start-VBRRestoreVM command and confirmed the reference to the desired -TargetNetwork. I found a NetworkMapping section where the original source network was being identified, but I still couldn’t determine why my specified -SourceNetwork wasn’t being honored – even though, only lines above it, the inputs were correct.

It eventually took me finding this article where someone was having the same problem. That article spelled out the problem. While I had reached the NetworkMapping section of the log file, I didn’t recognize that the NetworkMapping operation was verifying the Source and then mapping to the Target. If the -SourceNetwork parameter wasn’t correct, the NetworkMapping operation failed (without being noted in the logs – that I could find, at least) and the VM was restored with no changes to networking.

The solution I reached is very similar to what eventually is disclosed near the very end of the previously linked forum post. Here’s what I came up with:

$backupID = $restorePoint.backupId
$backup = Get-VBRBackup -Id $backupId
$oibs = $backup.getOibs() | ? {$_.VMName -eq "$($vm)"} |Sort -Descending |Select -first 1
$sourceNetwork = $oibs.auxdata.nics.network

This pulls info from the already selected $restorePoint to then pull information out of the backup job that contains the $restorePoint. $restorePoint already contains the Backup ID needed to find the Backup Job. After finding the Backup Job, let’s select the desired OIB that matches VMName which should be the first object listed (where there are multiple objects due to multiple restore points in that backup job). With the selected OIB, we can now set $sourceNetwork to the value of $oibs.auxdata.nics.network.

Interesting note: OIB stands for Object in Backup – took me forever to find that!

After this, I was able to successfully restore VMs over multiple iterations with different Source and Target networks, all of which successfully had the desired -TargetNetwork applied. Problem solved!