Issue Plesk Migrator Fails to Detect Subscription Databases — DB-Lib error 20002

[Rabah]

Server operating system version

Windows Server 2022

Plesk version and microupdate number

Plesk Obsidian 18.0.70 Update #3 Web Host Edition

Migration Scenario:

I'm running a migration using Plesk Migrator:

• Source Server: Windows Server 2012
• Target Server: Windows Server 2022
• Remote Database Host: Microsoft SQL Server 2012 (standalone host)

The migration fails when attempting to retrieve MSSQL database information for subscriptions that rely on the remote SQL Server.

Plesk Migrator Error:

Failed to detect databases of subscription.
Failed to execute SQL query: b'DB-Lib error message 20002, severity 9:\nAdaptive Server connection failed (IP)\nDB-Lib error message 20002, severity 9:\nAdaptive Server connection failed (IP)\n'
Query: SELECT COUNT(*) AS cnt FROM master.dbo.sysdatabases WHERE name = %(database_name)s
Arguments: {'database_name': 'plesk_migrator_11375729326611153771'}
Server: IP
User: sa
Tried to connect from: the local server

Validation and Diagnostics:

Network Layer

• SQL Server is reachable from the target Windows Server 2022.
• TcpTestSucceeded : True Using Test-NetConnection -ComputerName IP -Port 1433 -InformationLevel "Detailed"
• No intermediate firewall is blocking the connection.

SQL Server Configuration

• SQL Server 2012 instance is up.
• TCP/IP protocol is enabled.
• Mixed authentication (SQL + Windows) is enabled.
• SQL Server Browser service is running even though the instance is default (MSSQLSERVER), using standard port 1433.

Manual Connection Successful

From the target Plesk server, I can connect directly using:

sqlcmd -S IP -U sa -P [REDACTED]

Observed Behavior:

Despite successful manual connectivity, Plesk Migrator fails with DB-Lib error 20002! Could it be that Migrator uses a Python-based driver like pymssql under the hood and relies on DB-LIB potentially implemented via FreeTDS to iniate communication ? If so, might this error point to a lower-level TDS handshake or protocol compatibility issue - especially given that the standard client tools connect without issue ?

Thanks in advance for any input.
Let me know if logs or additional diagnostics would help.

 

[Sebahat.hadzhi]

Hello, @Rabah . Can you please try applying the solution from the following article:

• https://support.plesk.com/hc/en-us/...to-execute-SQL-query-Login-failed-for-user-sa

 

[Rabah]

Hello, @Sebahat.hadzhi. Thank you for your response. I attempted the solution provided in the article, but unfortunately, it didn’t resolve the issue.

One important detail to highlight: I’m unable to perform a Re-sync because the migration fails outright. It doesn’t just complete with errors—the process itself doesn’t finish, which prevents any further re-synchronization attempts.

To work around this, I restarted the migration for the subscription. This time, I only selected Migrate external IDs from the available options as suggested in the article:

• Migrate mail messages
• Migrate website files
• Migrate database data (tables, rows, etc.)
• Migrate external IDs

Despite this narrowed focus, I still encountered the same exact error during migration.

Any insights or suggestions you can provide would be appreciated.

 

[Rabah]

Note: plesk_migrator_11375729326611153771 database does not exist on the remote MSSQL server. I assume it’s intended as a temporary database that should be created—or is meant to be created—by the migrator during the migration process.

 

[Sebahat.hadzhi]

Thank you for the update. I am not quite sure what is causing the issue in this particular case. I would suggest opening a ticket with Plesk support for further investigation on your server. To sign-in and open a ticket please go to:

• https://support.plesk.com

If you got your license from a reseller, your reseller is in charge of providing you with support. You can raise the inquiry with them and they can forward it to our team for further processing.
If the reseller does not provide support, here is an alternative to get support directly from Plesk:

• https://support.plesk.com/hc/en-us/articles/12388090147095-How-to-get-support-directly-from-Plesk

 

[Rabah]

Hey @Sebahat.hadzhi , sorry for the late reply — didn’t get a chance to get back to this last week.

Quick update

After digging into it, turns out Plesk Migrator is using pymssql, which wraps FreeTDS under the hood. So yeah, it’s all running over the TDS protocol via DB-LIB.

Reproduced the Failure Manually

• Ran a direct test from Plesk’s embedded Python:

cd "C:\Program Files (x86)\Plesk\var\modules\panel-migrator\python"
$env:TDSDUMP = 'stdout'
.\python.exe

• Then:

import pymssql
print(pymssql.__version__) # 2.3.0
conn = pymssql.connect(server='[IP]', user='sa', password='[REDACTED]', database='master')

• Same crash reproduced. The TDS dump made clear, it was dying during TLS negotiation:

net.c:318:Connecting to [IP] port 1433
net.c:528:tds_open_socket() succeeded
packet.c:852:Sending packet
...
tls.c:1036:handshake failed with -1 3 1
tls.c:1080:handshake failed
login.c:644:login packet rejected
query.c:3804:tds_disconnect()
util.c:179:Changed query state from IDLE to DEAD

So the issue wasn’t network, creds, or server availability — Just FreeTDS trying to negotiate encryption with SQL Server 2012 and failing hard.

Workaround: Override with Custom FreeTDS Config

Didn’t have access to tweak the SQL Server side, so I went client-side.

• Dropped a minimal freetds.conf:

[global]
tds version = 7.4
encryption = off

• Then pointed FreeTDS to that config via env var.

Once that was in place, the pymssql.connect() call succeeded and Migrator stopped throwing DB-Lib 20002. Plesk Migrator successfully connected to the remote MSSQL 2012 instance and the subscription database info was retrieved without further errors.

Just thinking out loud — maybe this is something that could be improved in the Plesk Migrator logic? Like if the first connection attempt fails with a known TLS-related error (handshake failed, tds_disconnect()), fallback to retry without encryption — especially for older SQL Server versions like 2012. Even just an optional flag in the UI or CLI to disable encryption for legacy targets would go a long way. Could you maybe pass this to your devs? Might be worth considering as a future enhancement.