Hey all, hoping someone has run into this before opening a can of worms with support.

Setup:

• Fresh, first-time Session Recording install (no prior deployment, not an upgrade)
• Single Session Recording server, Windows Server 2022 Datacenter
• SQL Server 2022 (Enterprise), on a separate/remote server from the SR server
• Installing account has sysadmin on the SQL instance

What happens:

Tried installing Session Recording Administration via both the standalone MSI and the full CVAD metainstaller, across three different product versions:

• 25.7 (2507 Current Release)
• 24.2 LTSR CU4
• 25.7 LTSR CU1

All four attempts fail in the exact same custom action (SsRecDatabase.dll.install), with two distinct errors depending on which authentication method I use for the DB connection:

1. Windows Integrated Authentication (default, no explicit DB credentials):

   Error 1001. Database 'CitrixSessionRecording' already in use. MSI (s): Leaked MSIHANDLE (150) of type 790531 DEBUG: Error 2769: Custom Action SsRecDatabase.dll.install did not close 1 MSIHANDLEs. CustomAction SsRecDatabase.dll.install returned actual error code 1603

The DB and schema actually get created successfully (confirmed on the SQL side - table populated, no errors server-side), but the custom action then fails its own internal "is this DB in use" check - because it apparently never closed its own connection. Time-to-failure varies a lot between attempts (4 sec to 112 sec), which smells like a race condition, possibly only surfacing because SQL is on a separate host (network teardown latency) rather than co-located.

1. SQL Authentication (entering a SQL login in the credential prompt or metainstaller DB screen):

The installer silently sets an internal AZURESQLSERVICESUPPORT=1 flag (even though this is on-prem SQL Server, not Azure SQL at all), and fails with a completely different, genuine error:

Error 1001. Invalid column name 'id'.
CustomAction SsRecDatabase.dll.install returned actual error code 1603

Looks like that code path queries a column that doesn't exist in the schema being used.

What I've ruled out:

• Network/firewall (port 1433 reachable, clean TCP test)
• SQL permissions (sysadmin confirmed)
• Leftover DB artifacts (dropped/recreated DBs before every attempt, verified zero open sessions/locks via sys.dm_exec_sessions each time)
• SQL Server "Force Encryption" (confirmed off)
• TLS/.NET strong crypto registry settings (added them, rebooted, no change)
• AV/EDR interference (none installed on the box)
• System/user culture (tried both a Turkish culture and en-US, identical "Invalid column name 'id'" result in the SQL-auth path either way)
• SQL Server error log shows nothing during the failure window - no rejected logins, no errors

Given it reproduces identically across 3 separate product versions/builds and both possible auth paths, this doesn't look environment-specific to me anymore - looks like a genuine defect in the shared DB setup code that only shows up when SQL Server isn't co-located with the Session Recording server.

Has anyone seen this, or found a workaround (e.g. installing with DB temporarily local, then pointing to the real instance after)? Case is open with Citrix support, just curious if this is a known one in the wild.