Did you check that DNS is fine, at least when you use a hostname which solves to an ip address? Any firewall issues, e.g. ports not opened (outgoing on your site, incoming at Azure)? Perhaps any permission settings on the target (ADMIN$)?
Thank you karl, I have disabled the win firewall on both side and I can reach (login with rdp) the sp virtual machine from the on premises veeam b&r....therefore the name/ip are correct! The only doubt I have is about the ports: indeed this is the port configuration on the sp cloud connect:
and on the azure portal
Since i did an installation at a customer with replication over WAN (with all the necessary ports etc.) i assume you have to open also the two other ports for outgoing and incoming direction, meaning on-prem and in azure (Installer, TCP 6160 and Transport, TCP 6162).
I had to do this at my customer, because without these ports the remote installation of all needed Veeam components wasn't possible.
kawiMTF wrote:Since i did an installation at a customer with replication over WAN (with all the necessary ports etc.) i assume you have to open also the two other ports for outgoing and incoming direction, meaning on-prem and in azure (Installer, TCP 6160 and Transport, TCP 6162).
However this is the setup for a remote repository, not for cloud connect, as cloud connect components only need to expose port tcp/6180 of the cloud gateway role. I suspect you are talking about two different setup, and Luca ended up configuring a remote repository, not cloud connect...
Luca
Luca Dell'Oca Principal EMEA Cloud Architect @ Veeam Software
It seems that you were trying to add SP as an ordinary windows server, not as a Service Provider.
Also, I'm wondering why you need to have a CC machine deployed at Azure, are you willing to become a service provider, or it's more about satisfying your own offsite needs? In the latter case, it'd be easier just to configure Azure VM as a repository server, as it's been suggested here.
dellock6 wrote:
However this is the setup for a remote repository, not for cloud connect, as cloud connect components only need to expose port tcp/6180 of the cloud gateway role. I suspect you are talking about two different setup, and Luca ended up configuring a remote repository, not cloud connect...
Luca
Indeed Luca, the problem was about the port 6180.....not 6160/6162...
I've installed the cloud connect in order to test it using a trial license.
Now I'm doing another test and I wanted to figure out which are the real benefits of using cloud connect. It is almost clear the advantages of having a multi-tenant solution if I am a SP....but from the end-user's perspective, why does he have to choose the cloud connect instead having a proxy (or a veeam server) hosted in Azure (or wherever)?
One of the main reasons for using Cloud Connect is an ability to transfer data over secure channel without any VPN connection and customer does need anything to be deployed in the cloud.
I'd also mention that we have a dedicated private forum for service providers, where this topic will be moved soon. So please apply to Veeam Cloud Providers group using User Control Panel to be able to follow it and participate in other related discussions.