Veeam BR server hosted in Site A
Domain-added Hyper V server in Site B
Sites connected by VeeamPN. Connections and routes verified
Initial attempted to add Hyper V host seems to suggest the host is seen and accessed from Site A, but I recieve this error as it attempts to install services:
Ive tried Domain and Local Admin creds. Nothing seems to work.
So the only thing in that list that doesn't apply is that the guest os is not in the same network. The sites are connected over VeeamPN. The connection is stable, and each site can see each other's assets, but the connection is SLOW. So slow I can't transfer a 1MB file between sites. Very odd.
Firewalls are open. The WAN connection for both locations is Fiber.
Can you please clarify if you see network performance issues while backup job is running or the same problem appears when you are copying files between two sites via regal file explorer? Cheers!
Just one more idea is to try a copy of some small file via file explorer from Veeam server to admin share of the Hyper-V host: \\ServerName\Admin$.
I assume that the attempt to copy binaries of our Installer service to the Hyper-V host is failed because of some networking problem.
The error "The specified network name is no longer available" is a common error which is passed directly from Microsoft Windows,
and indicate that some unknown problem led to a sudden failure of the existing connection between 2 nodes.
By the way, can you tell us more about the deployment?
Why do you install backup server on a different site than Hyper-V host, are you going to run replicas to the remote site?
I can transfer files, but speed seems slow, like around 1MB/s. Not indicative of the transfer capabilities of either network.
My plan was to run the backup server in a centralized location, with proxies and local repositories in the each remote site. I'm not even sure that's "allowed", but with VeeamPN connecting the remotes back to the hub site, I figured this was possible.
The use case seems to be valid, please continue working with our support team to find the root cause.
By the way, you may take a look at this article (TcpMaxDataRetransmissions), increasing TCP retransmits number probably would help to workaround the issue however I'd recommend to check it with Microsoft support team before testing the workaround, the latest officially supported OS listed in the KB is Windows Server 2008 R2.
I ask that my case be reopened and reassigned into a paid product queue. I am an MSP looking to implement this as our DR offering and the case has been closed due to it be filed in the VeeamPN category (my error when submitting the initial ticket).
I am aware of the memo release a few days ago regarding support on free products. I would not classify this as free, but in a trial state, and right now that's not looking great.
PetrM wrote: ↑Jan 06, 2020 1:39 pm
The use case seems to be valid, please continue working with our support team to find the root cause.
By the way, you may take a look at this article (TcpMaxDataRetransmissions), increasing TCP retransmits number probably would help to workaround the issue however I'd recommend to check it with Microsoft support team before testing the workaround, the latest officially supported OS listed in the KB is Windows Server 2008 R2.
Thanks!
No change was seen after this adjustment was made.
