[Feature Request] Disabling role Guest Interaction Proxy

[Ollo]

Hello,

by adding a new Proxy, it gets the 2 roles "Backup Proxy" and "Guest Interaction Proxy".
When you like to disable the proxy under BACKUP INFRASTRUCTURE only the role "Backup Proxy" would be disabled.
The proxies are still used for SQL Log processing p.e.

The GUI has to be changed, that you also can disable the role "Guest Interaction proxy" globally.

Regards Ollo

[foggy]

Hi Ollo, thanks for the request, noted. But could you share a couple of words regarding the scenario - when you would like to disable the guest interaction proxy? Thanks.

[Ollo]

We added 2 hardware proxies to our configuration. We found out, that the configuration was incorrect respectively not finished . Before we have to delete them from configuration, we set them to disabled.
We restarted the OS and the SQL log processing aborts.

Other situation. sometimes you like to patch the OS of your Proxy and don't want to stop all your schedules because of one proxy. So it would be nice if the can set them to maintenance.

[foggy]

Got it, thanks.

[spiritie]

+1 for this.

Seeing the same behaviour, currently we have disabled a proxy and Veeam still uses it as guest interaction proxy.

Would be nice when adding a Windows server to choose whenever it should be acting as a guest interaction proxy or not, as the network doesn't always allow the ports needed.
Instead we have to edit all of our backup jobs, and choose the specific servers we want to use as guest interaction proxies, which is not ideal since we'd prefer to use automatic selection.

[signal]

Is this on the roadmap somewhere?

When adding a Windows server there should be an option to choose it it may be used as a guest interaction proxy. This is very important in secure environments.

[Gostev]

@signal can you clarify this a little more please? If a managed server does not have a direct network connection to guest, it will not be used as guest interaction proxy. But in cases when it does - why not use it? How leveraging such servers is going to make your environment less secure?

[signal]

My point of a secure environment is some of the candidates for being a GIP do not have the needed access in the network. In the specific environment I have in mind there is a windows server acting as backup proxy and repository, but it does not have access to the guest systems to perform backup.
The setup is as follows:
Backup server: 10.1.12.20 (/24)
Backup Proxy/repo: 10.1.60.20 (/24)
Guest: 10.1.0.30 (/24)

Every run the proxy (60.20) is chosen to perform backup with the message "different subnet", and then fails back to the backup server, which has the firewall openings required. I know I can choose a specific server as GIP for the job, but this is not a viable option since there may be other VMs to back op where there are different Windows VMs to use as GIP.

[Jay Die]

Hello,

+1 for this feature.

In my case, I am currently installing a Veeam backup infrastructure for a customer. This infrastructure is simply a Veeam Backup Server + Veeam Windows Repository.
These 2 servers are physicals, the Veeam server have embedded disks, but my customer want to secure some backups to the windows repository (other room / other building).

But when I registered the windows host, he also registered automatically as a guest interaction proxy. But this server is only a backup repository, and not a Veeam Proxy.

So I need to configure each job to use one specific guest interaction proxy.

[t481]

+1 for this feature. It's terrible. It took me a while to figure out what was going on. Had to change the job itself to specifically exclude one particular server. Please improve this.

[skrause]

I support this suggestion.

Maybe create a separate set of roles with "backup proxy" and "interaction proxy" so that you can set a machine to just be an interaction proxy since it needs less resources and then your "fat" proxies would just be for processing the heavy lifting tasks.

[Seve CH]

Hello,

In my case, we want our Veeam server to do only Veeam server and repo roles. Everything else will be blocked at network level and raise questions by the IT security guy. I know we can specify the interaction proxies at job level, but as a failback, it would be great to have one of these:

- Possibility to disable each proxy role independently
- Disable both roles when disabling a proxy.

Having a disabled proxy still executing tasks is IMHO unexpected behavior.

Regards

[FrancWest]

Hi,

case #04816122.

Our lab is an exact clone of our production environment down to ip-address level. The lab is in a different VLAN so completely isolated from production. The lab has it's own guest interaction proxy only reachable by the VBR server.

Some machines in the lab need to be backupped. So in the backup job I've explicitly told Veeam to use the guest interaction proxy in the lab for application aware processing. However, if for some reason the guest interaction proxy is not reachable, Veeam automatically falls back to the VBR server itself to act as the guest interaction proxy. The problem with this is that Veeam is then processing the wrong VMs, the production vms, to do the application processing and then backups the lab vms. This causes the wrong transaction logs to be flushed and wrong freeze of the filesystem. Also, the backups of the labs are now crash consistent instead of application consistent.

Why does veeam fall back to a different guest interaction proxy, even if I tell it to only use a specific guest interaction proxy? In my opinion the job should fail if it's not able to contact the specified guest interaction proxy to avoid the kind of issues we are having now.

[foggy]

Hi Franc, the failover behavior is by design. I'm merging your post to the thread discussing the feature request to disable the guest interaction proxy role since it would also help in your case.

[skrause]

Any updates on if this feature is in the works?

I am deploying a new infrastructure and because the Automatic Selection mechanism looks at "network configuration and current load", it keeps trying to use my repository servers for Interaction proxies because they have a lot of resources. This, of course, fails because my repositories are on isolated networks per best practices from Veeam.

It seems silly that I need to go into EVERY JOB and manually select a list of interaction proxies to use when there should be an Interaction Proxy role (maybe even with groups) to make selection easier to manage when you have more than a handful of jobs.

[shearingc]

another +1 for this feature from me, this is the most recent thread I could find on this issue and I couldn't see any mention on the kb article for guest interaction proxy as an update to this.

Was struggling to find out why some vms would fail, then work on a retry, turns out it was auto selecting a server which should only be a backup repository to do the guest interaction.

I've now changed all jobs to only include the backup proxy servers we want as guest interaction proxies, but if we make any infrastructure changes, add/remove backup proxies then we need to go into every job and make changes individually to the list of allowed guest interaction proxies.

Would make things much easier if we could disable the role on individual servers, even if it's just a registry key we have to add once to a server.

Thanks.

[J.Leeflang]

+100 for this feature for me, with a twist.

I would like to be able to disable the role for server I don't want participating in the Guest Interaction process and one of them is the backup server itself.
Due to the ransomware thread we are separating various Veeam roles and placing them in secured networks.
By moving the Guest Interaction role and the Mount Server role I can limit the number of ports I need to open from the backup server itself.

The other opties I would like to see is that a preferred Guest Interaction Proxy or multiple Proxies can be assigned to a specific subnet or group of subnets.
This way I can assign a GIP to a remote or secured network without the risk that a GIP without the required network rules in place gets assigned for the job.

At this moment this is somewhat possible by creating backup tasks on a per location base and assign a dedicated GIP to the task.
It would be better to let Veeam pick a GIP so I can be more free to create backup tasks based on server roles instead of location.

[PetrM]

Hello Jeroen,

Many thanks for the detailed description of your request but why the existing functionality for GIP selection does not suit you?

Thanks!

[J.Leeflang]

It does in most cases.
But now I have to manually edit each and every job to exclude a certain GIP from participation.

In the case of a remote location I want the GIP or GIPs on that location to act as the GIP. Only when that "preferred" GIP isn't functioning, should it revert to a second GIP and after that to the backup server. I want this proces to be 100% predictable so we can plan firewall rules arround things.
If this than A, if A fails then B, if B fails then C, if C fails, its too bad.
Now if I let Veeam deside, it will first use all "non-backupserver" GIP servers in a random order and fall back to the backup server if it doesn't work.
I I have 5 remote locations. It might select a GIP server in location B, C, D to try to connect to servers in location A. This fails. While this was no problem a few years ago when Ransomware attacks were rare. Today we seperate as much as we can. Only what is absolutely necessary is applied, everything else is blocked. When the first attempt fails, it switches over to the backup server that connects over the WAN link. All this while there is an active GIP in the remote location, but Veeam isn't aware of this.
To work arrount this I create a backup job PER location and only allow the GIP in that location to act as the GIP together with the backup server itself.
I there are 10 remote locations or seperated networks with own GIBs I have to create a backup job for each network of we have to use some sort of perimeter network that contains a GIP and open firewall rules to allow this GIP to access multiple networks. Some security/network administrators see this as a bypass possibility for there security solutions because port 445 is used and won't allow this. We can use persistent agents to work arround this issue, but this is a real pain in the @ss when things need an update.

I am designing and implementing dataprotection solutions and most of my time nowadays goes to dermining what ports are used between different servers and what firewall rules are required. So if I get more control over how Veeam is using roles, I can create more robust and safer solutions by steering traffic accross networks instead of opening too many ports or having to spend lots of time manually editting lots of jobs, sometimes accros multiple servers if replication is also in place.

[PetrM]

Hi Jeroen,

I really appreciate your detailed response with all the necessary clarifications. It certainly provided food for thought!

I cannot say now what the expected ETA is but your feature request is noted.

Thanks!