AZURE SQL LOGIN FAILED

[abel.laime]

Hi,
perform all steps to create backup policy for azure sql server.
At the time of performing the connection test, it fails.
Attached message

"Worker could not connect to the SQL server due to an error: Cannot open server "sqlservername" requested by the login. The login failed."

This user is correct because I can connect using sql managent from another computer without problems.
Any solution?
Thank you.

[nielsengelen]

To be 100% sure, you've added the account under the accounts tab and use this one in the policy? The logs may give a bit more information on where it goes wrong however it may be easier to contact support for insight as these forums won't replace our support team to that level .

[abel.laime]

Yes, I have added from the accounts tab.
Where are the records?
In session logs?
Thanks

[nielsengelen]

You can download logs via the support information section and analyse them yourself or utilise our support if that is easier for you.

[abel.laime]

I already made the ticket 05095880.
Awaiting reply

[agrob]

Hello

I have a similar issue. Any news here?

Maybe it has something to do with Firewall Settings on the SQL Server? As the Worker can not connect, maybe we should have an option to have a worker with static ip to allow this IP on the Azure SQL Server...?

Beste Regards

[nielsengelen]

Hi @agrob,

There was no outcome yet of the case. Can you open a case and let me know the ID so we can look into this?

[agrob]

Hi Niels

Case ID is #05124721
I guess it is not exactely the same error, sorry. The error i have is: "Worker can not connect to SQL Server due to an Error: Timeout Expired"

I guess it could be the Problem that VBA and the VBA Worker are in a dedicated Subscription. AZURE SQL is in another subscription. As Worker does not have a public IP, i guess it can not connect to the SQL Server....But lets wait for an answe from support

[agrob]

So in my case (Error: Timeout Expired) the solution was to modify the NSG for the VNET in which the VBA Appliance is. Had to open the following ports:

Direction: Outgoing
Source: Vnet (or Subnet)
Source Ports: *
Destination Ports (TCP): 1433,11000-11999,14000-14999
Destination: sql.westeurope

I thought that the Worker VM is connecting to the SQL Server/DB and does processing it. But that seems not to be the case as the Worker VM does not have a public IP address. Only the VBA has public IP and it seems that this vm is doing the connection to the sql instanz... (as we do not have any vnet peering between VBA VNET and SQL VNET).

[nielsengelen]

Thanks for updating us with the outcome. We’ll look into enhancing this part in the user guide to clarify it.