Guest interaction proxy

[vikingtoby]

Is there a reason why the VBR Console selects a guest interaction proxy from "All registered Windows Servers" and not the backup proxies attached to the console?
Seems silly.

Our scenario, it chose one of the repositories, which can't connect to anything really, but all the attached proxies can.

[Egor Yakovlev]

Veeam Backup & Replication uses the following priority rules to select the guest interaction proxy:
1. A machine in the same network as the protected VM that does not perform the backup server role.
2. A machine in the same network as the protected VM that performs the backup server role.
3. A machine in another network that does not perform the backup server role.
4. A machine in another network that performs the backup server role.
If for some reason this logic is broken and selection goes otherwise, it is worth checking with support.
p.s. Guest Interaction Proxy can be set Manually if Automatic selection does not satisfy the need.
/Thanks!

[skrause]

I have been running into the same issue in my new environment and it is a bit maddening that the backup repository is being picked first on almost every job as an interaction proxy.

My repository server does not:
A - have the proxy role installed at all. It is just a repository.
B - have network access directly to/from VMs on port 445, per best practices.

Why doesn't it look at assigned roles in the VBR console at all as part of the logic?

There should be a way to exclude specific servers from ALL interaction tasks, not just on a per job basis.

[Mildur]

Guest interaction Proxy has not the same purpose as the Veeam Proxy Service.

The Guest interaction proxy Server is used in a backup Job for copying the „Application Aware Executables“ to the guest.

The Veeam Proxy is used to read the productive data and send it to the Veeam Backup Repo.

Copying the executables is a simple command which every windows server can perform:
1. connect to admin share
2. copy the exe files
3. start the application aware tool
There is no specific veeam proxy Services needed for that.

[skrause]

It doesn't matter what the technical process is that it uses.

There should be a way to say "these servers are allowed to be interaction proxies", just like every other role in the Veeam infrastructure.

[Mildur]

You can do that for each backup job, if you have Enterprise or Enterprise Plus.

https://helpcenter.veeam.com/docs/backu ... ml?ver=100

If you have added Microsoft Windows VMs to the job, specify which guest interaction proxy Veeam Backup & Replication can use to deploy the runtime process on the VM guest OS. On the right of the Guest interaction proxy field, click Choose.

- Leave Automatic selection to let Veeam Backup & Replication automatically select the guest interaction proxy.

- Select Use the selected guest interaction proxy servers only to explicitly define which servers will perform the guest interaction proxy role. The list of servers contains Microsoft Windows servers added to the backup infrastructure.

[skrause]

I know I can do it for each backup job.

That isn't my point at all.

[PetrM]

Hello,

There should be a way to say "these servers are allowed to be interaction proxies", just like every other role in the Veeam infrastructure.

@skrause it's an interesting idea but why do you think that this approach would more comfortable than the option to explicitly define which servers will perform the guest interaction proxy role in the specific job?

Thanks!

[skrause]

Petr,

The main reason is that the guest interaction proxy was pitched as a way to use different, more lightweight, machines to do the guest interaction while also allowing for the main backup components to be on isolated networks from the production VMs.

It seems to me that having the "guest interaction proxy" role (which as stated doesn't need a lot of components) as a flag to use as the first criteria in the selection policy makes the most sense. Then, any time you add or remove an application interaction proxy you would not have to change all of your jobs manually.

It just seems to make more sense from a scalability perspective to me.

[PetrM]

Thanks for the detailed feedback! Let's keep tracking the requests for this functionality prior to decide on it.

Thanks!