Veeam automatic proxy selection problems

[YoMarK]

Hello,

First of all, this is not a big deal to us. We had this problem since version 5(that we noticed) and still have it in version 8. But it is of some annoyance to people who have to do VM restore, and don't now Veeam all that well(so then hey call me).
We have an environment that consists of ESX servers of different subnets(sites), with different kind of storage connected to them. On smaller sites they use local storage, on lager sites they have SAN's connected to them.
Not sure if it is of significance to the issue, but our Veeam environment is completely virtual, so our veeam backup repositories are virtual servers with VMDK's on SAN. Backup server and procy's are all virtual too. Of course all the backups are done to offsite locations.
Also we use daily replica's a lot for the smaller sites where we make sure all the VM's on the "first" ESX host are replicated to the "second" ESX host(in case of emergency operators could power on those replica's without having to do a restore) and vice versa.

Now the issue: sometimes when doing a restore(from backup mostly) Veeam selects the wrong backup proxy. A backup proxy that is on the wrong subnet, and more annoyingly does not have access to the local storage on the site/ESX server that we want to restore to. So what happens is that it restores the .vmx, vmxf and .vram files(using network), and then wants to restore the .vmdk files. Off course that won't work(I wants to use SAN mode sometimes too - it should never do that), and then after a few minutes it throws the error "failed to open VDDK file ...." . When I do it again, an manually select the right proxy, it works fine.
The veeam proxy's are up until now all on "automatic"(so selection of datastores and transport mode), but I probably will change that and see if it helps. Local storage datastores all have unique names on the ESX hosts across the network.

I don't think there is any kind of configuration error. Veeam should know that proxy A(on ESX A with local datastore A) does not have access to ESX B(with local datastore B). But it selects it anyway, and therefore the job fails. When I edit proxy A, and see which datastores I can manually configure, datastore B is not one of them(I see the correct datastores there).

Any ideas on why this is happening?
I know that it's probably fixed by manually configure all proxy's(datastores and transport mode), but should work on automatic too right?

Thanks in advance!

[foggy]

Mark, have you ever contacted support with any of the particular wrong proxy selections? There are most likely reasons for this or that proxy selection in each case (depends on too many factors like transport mode, proxy availability, amount of tasks it is currently running, etc.), but we need to look at each occurrence individually to be able to define them.

[YoMarK]

Sorry for the late response. No, I did not contact support, had no real need and time for it(disabled automatic).
Added some new proxy's today, and saw very weird choices by Veeam again(selecting SAN mode for an obvious virtual appliance), and selecting a source proxy in a completely different subnet(and different datastore names).

[foggy]

So once again I encourage you to involve support for more effective troubleshooting of this behavior.