connect-dbainstance doesn't return clustername for failover clusters

[paranoidDBA]

Description as follows:

`PS C:\Users\xxx> $PSVersionTable

Name Value

---

PSVersion 7.3.3 PSEdition Core GitCommitId 7.3.3 OS Microsoft Windows 10.0.14393 Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0

PS C:\Users\xxx> import-Module -Name dbatools PS C:\Users\xxx> get-module -Name dbatools

ModuleType Version PreRelease Name ExportedCommands

---

Script 2.1.6 dbatools {Select-DbaObject, Set-DbatoolsConfig, Add-DbaAgDatabase, Add-DbaAgListener…}

PS C:\Users\xxx> $test=Connect-DbaInstance -sqlinstance xxx\xxx PS C:\Users\xxx> $test.IsClustered True PS C:\Users\xxx> $test.ClusterName

PS C:\Users\xxx>`

[niphlod]

hi, not sure dbatools can help, as it's the same thing SMO's extracts .... maybe an update of the library can fix the issue ?

[paranoidDBA]

hi, not sure dbatools can help, as it's the same thing SMO's extracts .... maybe an update of the library can fix the issue ?

Thanks for your reply niphlod. But please can you elaborate on how I could do this?

[niphlod]

updating the library is something dbatools may do and it's not so easy to do on your side. Point is that dbatools base itself on SMO's logic for Clustername and doesn't modify it's behaviour.

do you mind sharing where you'd get from DMVs the cluster name for your instance ? master.sys.dm_hadr_cluster ?

edit: (also, not sure it's a bug on SMO per se, it may be intended for FCIs )

[niphlod]

BTW, I don't have an FCI at hand but ... did you try by any chance to connect to the underlying server rather than the cluster name ?

[paranoidDBA]

did you try by any chance to connect to the underlying server rather than the cluster name ?

• no i connected to the "client access name".

do you mind sharing where you'd get from DMVs the cluster name for your instance ? master.sys.dm_hadr_cluster ?

yes master.sys.dm_hadr_cluster. Think this might be the issue, it doesn't return the clustername. The MS documentation here link. Suggests it should, unless I've misunderstood the wording.

[niphlod]

@paranoidDBA : try connecting to the underlying server and see what the properties like ClusterName are filled with, please.

[paranoidDBA]

thanks again for your continued help with this.

I have tried connected to the owner node directly, but the command doesn't seem to work with that.

Connect-DbaInstance -sqlinstance mynode1\myinst ConnectionError: Line | 97904 | throw $records[0] | ~~~~~ | Error connecting to [mynode1\myinst]: The system cannot find the file specified.

[niphlod]

mmmh, can you connect to it via SSMS ? If yes, try passing it with quotes, as in 'mynode1\myinst' rather than mynode1\myinst

[paranoidDBA]

no can't connect to the node using ssms. I didn't think that was possible, I thought connections had to go through the clustername.

[niphlod]

so, maaaaybe, now you know why "clustername" doesn't make sense at all with failover instances ? :D that's to confirm that is by design, it makes sense with alwayson when you can connect also to the underlying servers, but not on FCI.

[paranoidDBA]

ok, obviously something ,missing in my understanding here,back to the drawing board, thanks for your help.

[niphlod]

recap: for FCI there's no clustername because you can only connect to the clustername (it'd always be the same) . for alwayson there's clustername because you can connect also to the underlying server (so they might be not the same).