Odd Experience when using Connect-DbaInstance

[david-garcia-garcia]

Verified issue does not already exist?

I have searched and found no existing issue

What error did you receive?

WARNING: [08:33:23][Test-DbaConnection] Unable to resolve server information | No such host is known.

Steps to Reproduce

I am port forwarding a MSSQL SQL Server running on a Windows node in kubernetes cluster on local port 1455.

$server = "127.0.0.1,1455"
$username = "sa"
$password = "xxx"
$securePassword = ConvertTo-SecureString -String $password -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $securePassword
$connection = Connect-DbaInstance -SqlInstance $server -TrustServerCertificate -SqlCredential $credential
Test-DbaConnection $connection

With the above code I get:

WARNING: [08:33:23][Test-DbaConnection] Unable to resolve server information | No such host is known.

Looking at Debug Info:

DEBUG: 3356 | [08:35:15][Connect-DbaInstance] We have a connected server object
DEBUG: 3411 | [08:35:16][Connect-DbaInstance] We will set server.ComputerName to server.NetName
DEBUG: 3417 | [08:35:16][Connect-DbaInstance] ComputerName will be set to sqlserver-0

ComputerName will be set to sqlserver-0 -> Why? I don't really understand the purpose of this, and how confusing it can be. In this case the target SQL is on a remote container so the hostname is meaningless unless you are a pod in the namespace itself.

But that is not the point, If I explicitly specified an IP address in the server name, why not honor my initial intention when writing the connection string?¿

I was able to workaround the issue looking at the implementation and adding this before creating the connection:

Set-DbatoolsConfig -FullName commands.connect-dbainstance.smo.computername.source -Value 'instance.ComputerName'

But this was truly a WTF experience with this command. Not sure if this is a bug or by design, or what the purpose of auto-calculating the ComputerName is.

Please confirm that you are running the most recent version of dbatools

?

Other details or mentions

No response

What PowerShell host was used when producing this error

Windows PowerShell (powershell.exe)

PowerShell Host Version

Name                           Value
----                           -----
PSVersion                      7.4.2
PSEdition                      Core
GitCommitId                    7.4.2
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

SQL Server Edition and Build number

Microsoft SQL Server 2022 (RTM-CU13) (KB5036432) - 16.0.4125.3 (X64) May 1 2024 15:05:56 Copyright (C) 2022 Microsoft Corporation Developer Edition (64-bit) on Windows Server 2022 Datacenter 10.0 (Build 20348: ) (Hypervisor)

.NET Framework Version

.NET 8.0.4

[niphlod]

hi @david-garcia-garcia , Test-DbaConnection doesn't just see if the connection can be made, but returns some informations on the host running the instance itself. If you want to know if you can just "open the connection" and you're not interested in the capabilities of the underlying host, just use Connect-DbaInstance plainly.

[andreasjordan]

I can give a little bit of background why Connect-DbaInstance works this way: Using "server.NetName" is very old and was long time the only option. This way, if you use an IP address or a DNS alias to connect, you get the actual name of that server (or in case of a cluster: the name of the virtual server) back. This is what most users need. When we started to use docker, this changed - as you have experienced it. Because of that, I included the new configuration option and the code to use it. So the workaround is there for you, nice that you have found it. It will be a workaround and not the default, because only some users use docker.

So there is no bug, everything works as designed.

[potatoqualitee]

Thank you everyone, for your questions/follow ups and clarifications.