initial commit of Get-DbaAvailabilityGroup

[wsmelton]

Initial commit

[potatoqualitee]

@ClaudioESSilva do you have an environment to support testing for this command? If so, would you be available to do so this week?

Here is the QA checklist

• Working/useful help content, including link to command on dbatools web site
• All examples work as advertised
• Does not contain template content
• Does not contain excessive/unnecessary amounts of comments
• Works remotely
• Works locally
• Works on lower versions or throws error specifying version not supported
• Works with named instances
• Works with clustered instances
• Handles offline/read only databases
• Supports multiple servers (at the command line or piped from Get-SqlRegisteredServerName)
• No un-handled errors which stop the command working with multiple servers

[ClaudioESSilva]

@ctrlbold I have and I am.

[ClaudioESSilva]

The main decision is if we go and use multi server or not and dynamic parameters

[ClaudioESSilva]

Shouldn't this command supports mutiple servers?
I vote yes. I want be able to do something like @('server1', 'server2') | Get-SqlAvailabilityGroup.

If yes this should be an array [object[]]$SqlServer and we have to add foreach loop on process moving the code inside begin block to there.

[ClaudioESSilva]

Need help with this?

Change to:
DynamicParam { if ($sqlserver) { return Get-ParamSqlAvailabilityGroups -SqlServer $sqlserver -SqlCredential $SqlCredential } }

And add this block code to DynamicParams.ps1 files

Function Get-ParamSqlAvailabilityGroups
{
<#
 .SYNOPSIS
 Internal function. Returns System.Management.Automation.RuntimeDefinedParameterDictionary
 filled with ProxyAccounts from specified SQL Server Job Server (SQL Agent).
#>
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Alias("ServerInstance","SqlInstance")]
        [object]$SqlServer,
        [System.Management.Automation.PSCredential]$SqlCredential
    )

    try { $server = Connect-SqlServer -SqlServer $SqlServer -SqlCredential $SqlCredential -ParameterConnection }
    catch { return }

    $list = @()

    # Populate arrays
    $list = $server.AvailabilityGroups.Name

    # Reusable parameter setup
    $newparams = New-Object System.Management.Automation.RuntimeDefinedParameterDictionary
    $attributes = New-Object System.Management.Automation.ParameterAttribute

    $attributes.ParameterSetName = "__AllParameterSets"
    $attributes.Mandatory = $false
    $attributes.Position = 3

    # Database list parameter setup
    if ($list) { $validationset = New-Object System.Management.Automation.ValidateSetAttribute -ArgumentList $list }
    $attributeCollection = New-Object -Type System.Collections.ObjectModel.Collection[System.Attribute]
    $attributeCollection.Add($attributes)
    if ($list) { $attributeCollection.Add($validationset) }

    $AvailabilityGroups = New-Object -Type System.Management.Automation.RuntimeDefinedParameter("AvailabilityGroups", [String[]], $attributeCollection)

    $newparams.Add("AvailabilityGroups", $AvailabilityGroups)
    $server.ConnectionContext.Disconnect()

    return $newparams
}

[ClaudioESSilva]

If we will support dynamic param, this one should be removed

[wsmelton]

Until fix is in place where dynamic parameters actually show up in help, I don't use them. Considering this would likely be a parameter that will/should get used I don't care to have it hidden.

[potatoqualitee]

Fix is coming this month, but I would prefer that we try to be as standardized as possible and always try to support DynamicParams when possible.

[wsmelton]

What is the measure or test that passes to say dynamic parameters should be used?

I would also wonder where will dynamic parameters work? Examples I see folks using is in ISE, which I don't use. So do they work on the command line (support tab completion)?

[ClaudioESSilva]

Runned against SQL Server lower than 2012 (when AG feature appears) and the message is "Availability Group is not configured."

I suggest to validate server major version and if lower than 11 then say something like "Availability Groups is available only on SQL Server 2012 (v11) or higher versions. Server '$server' has version $($server.Major). Skipping."

We can validate the edition, too. AG is only available on Enterprise Edition so if running on, for example, Standard Edition should say "Availability Groups feature is only available on Entrepise edition. Server '$Server' is running '$server.Edition'. Skipping."

[wsmelton]

Yeah, being that Connect-SqlServer was going to be updated to have the version flags, figured wait until that is done. Instead of duplicating code.

[potatoqualitee]

Would like this to be standard as well. It helps because I can do mass finds and replaces. In addition, it's part of the QA checks that we gotta check.

[ClaudioESSilva]

If this parameter needs the $AvailabilityGroupName and if we don't use dynamic parameters, we should set a PARAMETERSET which enforce the mandatory of both parameters.
If we will use dynamic parameter maybe we should validate this on the beginning of the Process instead after get all the info.

[wsmelton]

Already tried that and it does not work correctly but also IsPrimary should not be a required parameter if someone wants to pull back specific AG info.

[potatoqualitee]

Sorry for the delay @wsmelton, gotta build a new AG cluster to test. But at least I'll finally have AGs in the lab again 💃

addressed