Open Matteo-T opened 1 year ago
We handle this through a config system. Seems like that'd be a more maintainable solution for you all.
What's the definition of "config system"?
In our module, we use Get-DbatoolsConfig and Set-DbatoolsConfig and Register-DbatoolsConfig which saves to a JSON file or the registry. @FriedrichWeinmann created it for us and it's now included in his PSFramework module and is all in C#
We allow users to save the config in their current session (Set) or for all sessions (Register)
Set-DbatoolsConfig -Name Import.EncryptionMessageCheck -Value $false -PassThru | Register-DbatoolsConfig
Oh, looks like we have way more commands than that, like import and export 😅
https://dbatools.io/configuration/
HTH
omg where can i report this bot
Edit: reported as malware
This is how we handle it @Matteo-T
# Set defaults just for this session
Set-DbatoolsConfig -FullName sql.connection.trustcert -Value $true
Set-DbatoolsConfig -FullName sql.connection.encrypt -Value $false
# Set these defaults for all future sessions on this machine
Set-DbatoolsConfig -FullName sql.connection.trustcert -Value $true -Register
Set-DbatoolsConfig -FullName sql.connection.encrypt -Value $false -Register
Yeah - I was thinking about having something like that while talking to the go-sqcmd
folks. Maybe I'll revisit and add it.
bravo GH and Microsoft, that bot is gone 🙌🏼
feel free to take our design, @Matteo-T. We also include the things found in the SSMS connection panel.
bravo GH and Microsoft, that bot is gone 🙌🏼
Actually, I just deleted those bot-things myself. :-)
feel free to take our design, @Matteo-T. We also include the things found in the SSMS connection panel.
I'm pretty sure that this goes for any dbatools/dbachecks code @Matteo-T - No need to reinvent the wheel.
This would be glorious. Being able to register "okay, for this database, use these connection settings going forwards" would be wonderful.
I just updated my team's internal devops infrastructure powershell module that we use for all our standard devops operations. Properly exposing the new -TrustServerCertificate
param required a change that's -170 +270. Being able to just say "okay, these are internal development machines and failovers and don't have public certs, they have to be trusted" vs "this is the public prod server, you should verify the cert chain before connecting" in a single config site would be ideal.
In v22.0.57, I may have missed a few (e.g. Enable-SqlAlwaysOn and Disable-SqlAlwaysOn).
It would be nice to complete the list in some v22 update.