Add FQDN to Connect-DbaInstance output

[johnmart82]

While using Set-DbaStartupParameter recently to set some traceflags I hit an issue where the cmdlet was failing. I tracked this back to the way that the Computer Name is passed into the Resolve-DbaNetworkName as part of the Invoke-ManagedComputerCommand function call.

The root cause is that in a complex environment where there are multiple forests etc, if there are any issues with DNS forwarders that prevent the resolution of the name then the cmdlet will fail. However, if it were to use the FQDN which was supplied into Set-DbaStartupParameter cmdlet then it would work.

I would make a suggestion that adding the FQDN as a property for the output from Connect-DbaInstance would then allow the use of that as opposed to the hostname to be passed into other commands around the DbaTools ecosystem.

I have a workaround which is to manually add the DNS suffixes to the local NIC properties (ultimately getting DNS to work properly is the plan) but it would be good to try and avoid a reliance on environmental configurations wherever possible.

What are people's thoughts on this?

JQ

[niphlod]

Whenever a function needs to operate on the underlying server starting from the SQL instance, it should use resolve-dbanetworkname and use its fullcomputername property . This Is usually the way other functions do their work. Il mer 2 dic 2020, 13:24 John Q. Martin <[email protected]> ha scritto:

…

While using Set-DbaStartupParameter recently to set some traceflags I hit an issue where the cmdlet was failing. I tracked this back to the way that the Computer Name is passed into the Resolve-DbaNetworkName as part of the Invoke-ManagedComputerCommand function call. The root cause is that in a complex environment where there are multiple forests etc, if there are any issues with DNS forwarders that prevent the resolution of the name then the cmdlet will fail. However, if it were to use the FQDN which was supplied into Set-DbaStartupParameter cmdlet then it would work. I would make a suggestion that adding the FQDN as a property for the output from Connect-DbaInstance would then allow the use of that as opposed to the hostname to be passed into other commands around the DbaTools ecosystem. I have a workaround which is to manually add the DNS suffixes to the local NIC properties (ultimately getting DNS to work properly is the plan) but it would be good to try and avoid a reliance on environmental configurations wherever possible. What are people's thoughts on this? JQ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7008>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA52B6FRCHINNB7HUNHKWDSSYWXVANCNFSM4UKNM7DA> .

[johnmart82]

I understand that, but when the DNS system in an environment does not work then the Resolve-DbaNetworkName function cannot resolve the server to get any data back.

When you look at the process here the original command is being passed a FQDN which through the various processes has the domain name removed and then tries to re-resolve the server details again. If there is an environmental issue then that will break the process and means that the command will fail.

[niphlod]

Yeah, okay. Lemme rephrase...We do have multiple functions that need to do this kind of translation between instance and server and resolve-dbanetworkname is the way to go. The resolution imho is going in and fix the place where the suffix get lost and preserve it in the "chain"...I believe resolve-dbanetworkname is not the problem here, but rather the function that calls it. Il mer 2 dic 2020, 13:45 John Q. Martin <[email protected]> ha scritto:

…

I understand that, but when the DNS system in an environment does not work then the Resolve-DbaNetworkName function cannot resolve the server to get any data back. When you look at the process here the original command is being passed a FQDN which through the various processes has the domain name removed and then tries to re-resolve the server details again. If there is an environmental issue then that will break the process and means that the command will fail. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7008 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA52B5UKCYIE6EJGTOKUWDSSYZH3ANCNFSM4UKNM7DA> .

[niphlod]

I mean, that being said and assuming instead the function is doing its best to avoid truncating the suffix, you can't really expect dbatools to work swiftly in an environment where DNS resolution is not working ... it's unfortunate that the SQL instance does not provide any information on the suffix and we try the best we can with Resolve-DbaNetworkName which is a "taxing" function... but it exists to support several WORKING setups (and I feel you, I work in an environment where AD and DNS are disjoint).

[niphlod]

PS : prolly https://github.com/sqlcollaborative/dbatools/blob/05fbf9898caf3922d1c9bf8017465bd57e5d387a/functions/Get-DbaStartupParameter.ps1#L67 needs to pass $instance rather than $instance.ComputerName

[andreasjordan]

I think that does not matter, as Resolve-DbaNetworkName uses only $cName = $computer.ComputerName.

[potatoqualitee]

I believe we have a config setting that skips resolution entirely that can help

Try this:
Set-DbatoolsConfig -FullName commands.resolve-dbanetworkname.bypass -Value $true

If that works, set it permanently instead of just in that session:
Set-DbatoolsConfig -FullName commands.resolve-dbanetworkname.bypass -Value $true -Register

If that doesn't work, we can explore @niphlod's solution

[wsmelton]

This setting/config was primarily added for folks needing to pass in the IP address so it basically never resolves it to a name. I'm not sure if this one applies to the FQDN being passed in.

[niphlod]

Sure, but still the full passed "string" should be piped down to resolve-dbanetworkname. Skipping the resolution via that configuration just makes all properties of the call returning the input object untouched. Here I believe get-dbastartupparameter is dropping the suffix in all cases, so skipping resolution logic isn't going to solve anything regarding the fact that you pass an fqdn to set-dbastartupparameter and It passes to resolve-dbanetworkname the computername property of the instance object, which doesn't have the suffix part. Il mer 2 dic 2020, 21:25 Chrissy LeMaire <[email protected]> ha scritto:

…

I believe we have a config setting that skips resolution entirely that can help Try this: Set-DbatoolsConfig -FullName commands.resolve-dbanetworkname.bypass -Value $true If that works, set it permanently instead of just in that session: Set-DbatoolsConfig -FullName commands.resolve-dbanetworkname.bypass -Value $true -Register — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7008 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA52B74NOGMDVDNORIXZMLSS2PFLANCNFSM4UKNM7DA> .

[andreasjordan]

Hi @johnmart82 , can you do me a favor?

Try using the new codepath in Connect-DbaInstance and see if this helps you a bit. The big difference is, that when you pass a computername with domain as -SqlInstance, the .ComputerName property is set with the domain.
But Resolve-DbaNetworkName will still only return the computername without domain - but maybe we can change that behavior as well in this configuration.

$server = Connect-DbaInstance -SqlInstance SRV1.Company.Pri
$server.ComputerName
Resolve-DbaNetworkName -ComputerName $server
Set-DbatoolsConfig -FullName sql.connection.experimental -Value $true
$server = Connect-DbaInstance -SqlInstance SRV1.Company.Pri
$server.ComputerName
Resolve-DbaNetworkName -ComputerName $server

[niphlod]

ahum...

But Resolve-DbaNetworkName will still only return the computername

nope, see FullComputerName.

sorry for the confusion before, the point is that resolve-dbanetworkname takes everything you launch at, a full instance included... functions using it should just pass what has been passed to them as a parameter, so they're sure nothing gets truncated in the way.
And they should use FullComputerName to target the server, e.g. via Invoke-ManagedComputerCommand
I believe Set-DbaStartupParameter is the only one using $instance.ComputerName (via Get-DbaStartupParameter, and using it unfortunately in some cases drops the suffix part).