SQL Restore Fails, TLS 1.2, custom port

[victor.bylin@atea.se]

Hi,

I'm having some trouble I can't figure out.

Case: 04010433

The SQL VM can be connected to the SQL explorer and the backup runs fine.

But the restore fails.
After using it as a staging server and trigger a restore of a VM it prompts after a while to provide the creds again because they are "wrong".
But they aren't of course because I am using it as a staging and can connect to it with the same creds from mgmt studio.
So connection works from the bkp mgr on the custom port but when the mounting from proxys gonna take effect something goes wrong.

In the logs I can see two things that might be the problem.

SQL Explorer LOG:

Code: Select all

2020-02-18 15:45:34   16 (22628) Error: Connection Timeout Expired.  The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement.  This could be because the pre-login handshake failed or the server was unable to respond back in time.  The duration spent while attempting to connect to this server was - [Pre-Login] initialization=14658; handshake=13469; 
2020-02-18 15:45:34   16 (22628) HelpLink.ProdName: Microsoft SQL Server
2020-02-18 15:45:34   16 (22628) HelpLink.EvtSrc: MSSQLServer
2020-02-18 15:45:34   16 (22628) HelpLink.EvtID: -2
2020-02-18 15:45:34   16 (22628) HelpLink.BaseHelpUrl: http://go.microsoft.com/fwlink
2020-02-18 15:45:34   16 (22628) HelpLink.LinkId: 20476
2020-02-18 15:45:34   16 (22628) Error: The wait operation timed out

Svc.VeeamMountlog:

Code: Select all

[18.02.2020 16:26:42] <128> Info     Using VSS options from job object [ id: a1fa3531-f0e2-4dbd-bd3e-b0a75511c19f ].
[18.02.2020 16:26:42] <128> Warning  Obtaining creds is not supported. CredsId: [0af9181d-98ef-4679-a140-13fd7dbfe188]

SQL VM:
Server is a WS 2019 core with enforced TLS 1.2



FW is open IP both Windows and central.

I have tried adding "UseSqlNativeClientProvider" DWORD 1 on the SQL VM veeam-backup-replication-f2/veeam-suppo ... 51878.html
And also https://www.veeam.com/kb2853 on the SQL VM.

Those 2 doesn't fix it.

Does anyone have any ideas on what can be wrong?

Thanks for the help!

Best regards!
Victor

[Andreas Neufert]

Question, what is your Backup Server and the Server/Client that you use for the SQL restore.
We had several issues in the past with operating systems not up to date that were not able to handle the TLS 1.2 handshake because of it.

[victor.bylin@atea.se]

@Andreas Neufert
Backup server is WS 2016.
SQL server/VM is a WS 2019 core.
Both are up to date regarding updates.

The issue seems to lie on the custom port, Veeam doesn't handle custom ports even if you stage on the target.
When the proxy/repo takes over the connect for the restore the MGR doesn't pass the custom port to the proxy.
So when the proxy connects it connects with default port which fails.
Correct me if I am wrong.

Best regards!
Victor

[Andreas Neufert]

Thanks for the explanation.Can you please share which port was changes and where?

[victor.bylin@atea.se]

We changed back to default port 1433 instead of using the custom port for SQL.
The MGR handles to connect to <ip/fqdn>,<customport>.
But when you then start the restore the proxy/repo which is a different server in this case can't connect to your <ip/fqdn>.
Because the proxy/repo doesn't get passed the <customport> as I see it.

As I understand after doing some searching, this might work:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo]
"[Server Name]"="DBMSSOCN,[Server Name],[Port#]"
And that you have to specify on all your Veeam servers or else it will fail.
But I haven't tried that so I can't confirm.

I would like to see some improvements on this part.
So could you please do a feature request regarding the handling of custom ports and TLS 1.2 which also seems a little bit shaky.

[Andreas Neufert]

OK I will ask the support team to esacalate to a specialist for SQL connections (maybe already done).
In some cases we use pass through authentication from the console, through the Backup Server to the SQL system. So it could be as well the situation that the authentication encrpytion can not be forwarded completely. Where did you start the console? On your client and is this client up to date?

[victor.bylin@atea.se]

Okay nice, started the console from the Veeam MGR and that of course is up to date with the mgr.

[Andreas Neufert]

OK, so it worked on the Veeam Server itself ?