My customer has the following context, a two nodes Always On active-active cluster with 4 instances where each instance owns between five and seven Availability Groups spread on the two cluster nodes.

The first step is to connect to the Qualys subscription of my customer:

And to navigate to the Patch Management application:

Once in the Patch Management, I go in the job menu to create the first job which will patch the first node of my Always On cluster.
As this job will be executed first it will have to execute the following tasks:

• Save the Availability group configuration for all instances in order to be able to re-dispatch the Availability Groups on both nodes once the patching will be finished
• Fail-over all Availability Groups from the node server1 to the node server2
• Patch the instances on node server1 with the available patches
• Reboot the server
• Fail-over all Availability Groups from the node server2 to the node server1

In terms of Qualys job I have to create a new job with the following information:

• A name to identify the job, here SQLServer_server1_M_3rd_Saturday_2200 as this job will be executed the third Saturday of each month at 10PM

• Select the asset (here the server) where the patches will be executed: server1

• Pre-actions: this step provides some actions which can be executed before to patch the assets. It can be: to run a script, install a software, change a registry key, uninstall a software or a system reboot.
  I will use it to execute my PowerShell script to:
  1. Save the Availability Groups configuration in a JSON file (you can find here an example of this file below)
  2. fail-over the Availability Groups which are primary on node server1 to server2. The PowerShell script is also logging in a file

###Logging functions
Function Out-Log() {
param(
[ValidateSet('INFO','WARNING','ERROR')]
[String] $Type = 'INFO',
[String] $Message
)

    '['+(Get-Date -f 'yyyy-MM-dd HH:mm:ss') +'] ' + ' - [' + $Type + '] - ' + $Message | Out-File -FilePath $LogFile -Append;
}

Function Add-Warning() {
param(
[String] $Warning
)
    If ($Warning) {
    Out-Log -Type WARNING -Message $Warning;
    }
}

Function Add-Error() {
param(
[String] $Message
)
    Out-Log -Type ERROR -Message $Message;
}

###AGs functions
#Function to save Availability Group configuration in a JSON file
Function AGsSaveConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    Out-Log -Type INFO "The following configurations have been saved:"
    $initialState = @()
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            $initialState += [PSCustomObject]@{
                Instance = $instance
                AGName   = $ag.Name
                Primary  = $ag.PrimaryReplica
            }
            $output = "Instance = $instance, AGName = $($ag.Name), Primary  = $($ag.PrimaryReplica)"
            Out-Log -Type INFO "$output" 
        }
    }
    #Add configuration to a JSON file
    $initialState | ConvertTo-Json | Out-File $ConfigFile
    $output = $initialState | Format-Table
}

#Function to save Availability Group configuration in a JSON file
Function AGsRestoreConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    if (!(Test-Path -Path $ConfigFile)) {
        Add-Error "Configuration file is missing"
        Add-Error "Exit without having restore the AG configurations"
        Return
    }

    $initialState = Get-Content $ConfigFile | ConvertFrom-Json

    foreach ($entry in $initialState) {
        write-host $entry
        $ag = Get-DbaAvailabilityGroup -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName
        if (($ag.PrimaryReplica -ne $entry.Primary) -and ($ag.LocalReplicaRole -eq "Secondary")) {
            Write-Host "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Out-Log -Type INFO "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Try {
                Invoke-DbaAgFailover -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName -Confirm:$false
            }
            Catch {
                Write-Host "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"
                Add-Error "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"                
            }
        }
    }
}

#Function to failover a list of instances to a specific host
Function AGsFailoverTo(){
param (
[Array] $instances,
[String] $TargetNode
)
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            if (($ag.ComputerName -eq $TargetNode) -and ($ag.LocalReplicaRole -eq "Secondary")) {
                Write-Host "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Out-Log -Type INFO "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Try {
                    Invoke-DbaAgFailover -SqlInstance $instance -AvailabilityGroup $ag.Name -Confirm:$false
                }
                Catch {
                    Write-Host "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                    Add-Error "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                }
            }
        }
    }
    Out-Log -Type INFO "All Availability Groups have been failover to node $TargetNode"

}

#LOG file path and name
$LogFileName = "AGsFailoverForPatching.txt"
$LogFilePath = "\\ShareFolder\LOG"
$LogFile = "$LogFilePath\$LogFileName"

#Configuration file path and name
$AGsConfigFileName = "initial_state.json"
$AGsConfigFilePath = "\\ShareFolder\LOG"
$AGsConfigFile = "$AGsConfigFilePath\$AGsConfigFileName"

###################################################################
#Save Availability Group configuration for all instances
Out-Log -Type INFO "******************** START PROCESS ********************"
Out-Log -Type INFO "START TO SAVE AVAILABILITY GROUPS CONFIGURATION"
Out-Log -Type INFO "Configuraton will be saved in file $AGsConfigFile"

#Find instances by list
$instances = @('server1\Instance1','server1\Instance2','server1\Instance3','server1\Instance4','server2\Instance1','server2\Instance2','server2\Instance3','server2\Instance4')
Out-Log -Type INFO "Instances available: $instances"

#Call the function AGsSaveConfiguration
AGsSaveConfiguration -instances $instances -ConfigFile $AGsConfigFile

Out-Log -Type INFO "Configurations saved successfully"

###################################################################
#Failover all Availability group to a specify node
Out-Log -Type INFO "START TO FAILOVER ALL AVAILABILITY GROUPS"
#Target node
$targetNode = "server2"
Out-Log -Type INFO "Target node: $targetNode"

#Call the function AGsFailoverTo
AGsFailoverTo -instances $instances -TargetNode $targetNode

• Select the patches to apply to the assets, here we will select then automatically based on the filter patch.appFamily: SQL Server

Qualys automatically detects that SQL Server 2019 instances are installed on this server as well as SQL Server Management Studio and provides the available patches.
Once patched have been applied, the server will automatically reboot.

• Post-actions: the possible post actions are: run a script, install a software, change a registry key or uninstall a software. As the instances have been patched and the server rebooted, we need to fail-over all Availability Groups which are primary on node server2 to server1, as the node server2 will be patched by the second job. A PowerShell script is then executed to do that:

###Logging functions
Function Out-Log() {
param(
[ValidateSet('INFO','WARNING','ERROR')]
[String] $Type = 'INFO',
[String] $Message
)
    '['+(Get-Date -f 'yyyy-MM-dd HH:mm:ss') +'] ' + ' - [' + $Type + '] - ' + $Message | Out-File -FilePath $LogFile -Append;
}

Function Add-Warning() {
param(
[String] $Warning
)
    If ($Warning) {
    Out-Log -Type WARNING -Message $Warning;
    }
}

Function Add-Error() {
param(
[String] $Message
)
    Out-Log -Type ERROR -Message $Message;
}

###AGs functions
#Function to save Availability Group configuration in a JSON file
Function AGsSaveConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    Out-Log -Type INFO "The following configurations have been saved:"
    $initialState = @()
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            $initialState += [PSCustomObject]@{
                Instance = $instance
                AGName   = $ag.Name
                Primary  = $ag.PrimaryReplica
            }
            $output = "Instance = $instance, AGName = $($ag.Name), Primary  = $($ag.PrimaryReplica)"
            Out-Log -Type INFO "$output" 
        }
    }
    #Add configuration to a JSON file
    $initialState | ConvertTo-Json | Out-File $ConfigFile
    $output = $initialState | Format-Table
}

#Function to save Availability Group configuration in a JSON file
Function AGsRestoreConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    if (!(Test-Path -Path $ConfigFile)) {
        Add-Error "Configuration file is missing"
        Add-Error "Exit without having restore the AG configurations"
        Return
    }

    $initialState = Get-Content $ConfigFile | ConvertFrom-Json

    foreach ($entry in $initialState) {
        write-host $entry
        $ag = Get-DbaAvailabilityGroup -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName
        if (($ag.PrimaryReplica -ne $entry.Primary) -and ($ag.LocalReplicaRole -eq "Secondary")) {
            Write-Host "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Out-Log -Type INFO "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Try {
                Invoke-DbaAgFailover -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName -Confirm:$false
            }
            Catch {
                Write-Host "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"
                Add-Error "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"                
            }
        }
    }
}

#Function to failover a list of instances to a specific host
Function AGsFailoverTo(){
param (
[Array] $instances,
[String] $TargetNode
)
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            if (($ag.ComputerName -eq $TargetNode) -and ($ag.LocalReplicaRole -eq "Secondary")) {
                Write-Host "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Out-Log -Type INFO "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Try {
                    Invoke-DbaAgFailover -SqlInstance $instance -AvailabilityGroup $ag.Name -Confirm:$false
                }
                Catch {
                    Write-Host "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                    Add-Error "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                }
            }
        }
    }
    Out-Log -Type INFO "All Availability Groups have been failover to node $TargetNode"

}

#LOG file path and name
$LogFileName = "AGsFailoverForPatching.txt"
$LogFilePath = "\\ShareFolder\LOG"
$LogFile = "$LogFilePath\$LogFileName"

#Configuration file path and name
$AGsConfigFileName = "initial_state.json"
$AGsConfigFilePath = "\\ShareFolder\LOG"
$AGsConfigFile = "$AGsConfigFilePath\$AGsConfigFileName"

###################################################################
#Failover all Availability group to a specify node
Out-Log -Type INFO "START TO FAILOVER ALL AVAILABILITY GROUPS"
#Target node
$targetNode = "server1"
Out-Log -Type INFO "Target node: $targetNode"

#Find all instances
$instances = @('server1\Instance1','server1\Instance2','server1\Instance3','server1\Instance4','server2\Instance1','server2\Instance2','server2\Instance3','server2\Instance4')
Out-Log -Type INFO "Instances available: $instances"

#Call the function AGsFailoverTo
AGsFailoverTo -instances $instances -TargetNode $targetNode

• Schedule is the third Saturday of each month at 10PM with a duration of 2 hours

• There are also some possibles options that can be enabled or disabled for the job.
  I select the Reboot Countdown to send a message to the users of the server before the reboot, a message is also sent to a distribution list at the execution start and after completion and the patches will try to be downloaded by the Qualys agent before the job schedule.

It’s finish for my first job, I need to create now the second one.
Qualys gives the possibility to clone job, so I’m using this feacture and change the needed information for my second job.
This job will patch my second server and will have to:

• Failover all Availability Groups from the node server2 to the node server1 (already done in the first job as post-action, but I do it again)
• Patch the instances on node server2 with the available patches
• Reboot the server
• Redistribute the Availability Groups based on the JSON file created in the pre-action of the first job

In terms of Qualys, this job has the following information:

• A name to identify the job, here SQLServer_server2_M_3rd_Sunday_0001 as this job will be executed the third Sunday of each month at 00:01AM, after the completion of the first one
• Select the asset (here the server) where the patches will be executed: server2
• Pre-actions: it will be a PowerShell script which will:
  o Failover the Availability Groups from node server2 to server1 with the following PowerShell script (the script is also logging in a file)

###Logging functions
Function Out-Log() {
param(
[ValidateSet('INFO','WARNING','ERROR')]
[String] $Type = 'INFO',
[String] $Message
)
    '['+(Get-Date -f 'yyyy-MM-dd HH:mm:ss') +'] ' + ' - [' + $Type + '] - ' + $Message | Out-File -FilePath $LogFile -Append;
}

Function Add-Warning() {
param(
[String] $Warning
)
    If ($Warning) {
    Out-Log -Type WARNING -Message $Warning;
    }
}

Function Add-Error() {
param(
[String] $Message
)
    Out-Log -Type ERROR -Message $Message;
}

###AGs functions
#Function to save Availability Group configuration in a JSON file
Function AGsSaveConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    Out-Log -Type INFO "The following configurations have been saved:"
    $initialState = @()
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            $initialState += [PSCustomObject]@{
                Instance = $instance
                AGName   = $ag.Name
                Primary  = $ag.PrimaryReplica
            }
            $output = "Instance = $instance, AGName = $($ag.Name), Primary  = $($ag.PrimaryReplica)"
            Out-Log -Type INFO "$output" 
        }
    }
    #Add configuration to a JSON file
    $initialState | ConvertTo-Json | Out-File $ConfigFile
    $output = $initialState | Format-Table
}

#Function to save Availability Group configuration in a JSON file
Function AGsRestoreConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    if (!(Test-Path -Path $ConfigFile)) {
        Add-Error "Configuration file is missing"
        Add-Error "Exit without having restore the AG configurations"
        Return
    }

    $initialState = Get-Content $ConfigFile | ConvertFrom-Json

    foreach ($entry in $initialState) {
        write-host $entry
        $ag = Get-DbaAvailabilityGroup -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName
        if (($ag.PrimaryReplica -ne $entry.Primary) -and ($ag.LocalReplicaRole -eq "Secondary")) {
            Write-Host "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Out-Log -Type INFO "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Try {
                Invoke-DbaAgFailover -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName -Confirm:$false
            }
            Catch {
                Write-Host "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"
                Add-Error "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"                
            }
        }
    }
}

#Function to failover a list of instances to a specific host
Function AGsFailoverTo(){
param (
[Array] $instances,
[String] $TargetNode
)
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            if (($ag.ComputerName -eq $TargetNode) -and ($ag.LocalReplicaRole -eq "Secondary")) {
                Write-Host "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Out-Log -Type INFO "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Try {
                    Invoke-DbaAgFailover -SqlInstance $instance -AvailabilityGroup $ag.Name -Confirm:$false
                }
                Catch {
                    Write-Host "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                    Add-Error "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                }
            }
        }
    }
    Out-Log -Type INFO "All Availability Groups have been failover to node $TargetNode"
}

#LOG file path and name
$LogFileName = "AGsFailoverForPatching.txt"
$LogFilePath = "\\ShareFolder\LOG"
$LogFile = "$LogFilePath\$LogFileName"

#Configuration file path and name
$AGsConfigFileName = "initial_state.json"
$AGsConfigFilePath = "\\ShareFolder\LOG"
$AGsConfigFile = "$AGsConfigFilePath\$AGsConfigFileName"

###################################################################
#Failover all Availability group to a specify node
Out-Log -Type INFO "START TO FAILOVER ALL AVAILABILITY GROUPS"
#Target node
$targetNode = "server1"
Out-Log -Type INFO "Target node: $targetNode"

#Find all instances
$instances = @('server1\Instance1','server1\Instance2','server1\Instance3','server1\Instance4','server2\Instance1','server2\Instance2','server2\Instance3','server2\Instance4')
Out-Log -Type INFO "Instances available: $instances"

#Call the function AGsFailoverTo
AGsFailoverTo -instances $instances -TargetNode $targetNode

• Select the patches to apply to the assets, here we will select then automatically based on the filter patch.appFamily: SQL Server (like for the first job)
• Post-actions: once the instances have been patched and the server rebooted, we need to redistribute the Availability Groups over the 2 nodes based on the JSON file created at the beginning of this patch process. For that we execute the following PowerShell script:

###Logging functions
Function Out-Log() {
param(
[ValidateSet('INFO','WARNING','ERROR')]
[String] $Type = 'INFO',
[String] $Message
)
    '['+(Get-Date -f 'yyyy-MM-dd HH:mm:ss') +'] ' + ' - [' + $Type + '] - ' + $Message | Out-File -FilePath $LogFile -Append;
}

Function Add-Warning() {
param(
[String] $Warning
)
    If ($Warning) {
    Out-Log -Type WARNING -Message $Warning;
    }
}

Function Add-Error() {
param(
[String] $Message
)
    Out-Log -Type ERROR -Message $Message;
}

###AGs functions
#Function to save Availability Group configuration in a JSON file
Function AGsSaveConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    Out-Log -Type INFO "The following configurations have been saved:"
    $initialState = @()
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            $initialState += [PSCustomObject]@{
                Instance = $instance
                AGName   = $ag.Name
                Primary  = $ag.PrimaryReplica
            }
            $output = "Instance = $instance, AGName = $($ag.Name), Primary  = $($ag.PrimaryReplica)"
            Out-Log -Type INFO "$output" 
        }
    }
    #Add configuration to a JSON file
    $initialState | ConvertTo-Json | Out-File $ConfigFile
    $output = $initialState | Format-Table
}

#Function to save Availability Group configuration in a JSON file
Function AGsRestoreConfiguration(){
param (
[Array] $instances,
[String] $ConfigFile
)
    if (!(Test-Path -Path $ConfigFile)) {
        Add-Error "Configuration file is missing"
        Add-Error "Exit without having restore the AG configurations"
        Return
    }

    $initialState = Get-Content $ConfigFile | ConvertFrom-Json

    foreach ($entry in $initialState) {
        write-host $entry
        $ag = Get-DbaAvailabilityGroup -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName
        if (($ag.PrimaryReplica -ne $entry.Primary) -and ($ag.LocalReplicaRole -eq "Secondary")) {
            Write-Host "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Out-Log -Type INFO "Failover of Availability Group $($entry.AGName) to $($entry.Primary)"
            Try {
                Invoke-DbaAgFailover -SqlInstance $entry.Instance -AvailabilityGroup $entry.AGName -Confirm:$false
            }
            Catch {
                Write-Host "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"
                Add-Error "Error during failover of Availability Group $($entry.AGName) to $($entry.Primary)"                
            }
        }
    }
}

#Function to failover a list of instances to a specific host
Function AGsFailoverTo(){
param (
[Array] $instances,
[String] $TargetNode
)
    foreach ($instance in $instances) {
        $ags = Get-DbaAvailabilityGroup -SqlInstance $instance
        foreach ($ag in $ags) {
            if (($ag.ComputerName -eq $TargetNode) -and ($ag.LocalReplicaRole -eq "Secondary")) {
                Write-Host "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Out-Log -Type INFO "Failover of $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                Try {
                    Invoke-DbaAgFailover -SqlInstance $instance -AvailabilityGroup $ag.Name -Confirm:$false
                }
                Catch {
                    Write-Host "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                    Add-Error "Error during failover of Availability Group $($ag.Name) to $TargetNode from $($ag.PrimaryReplica)"
                }
            }
        }
    }
    Out-Log -Type INFO "All Availability Groups have been failover to node $TargetNode"

}

#LOG file path and name
$LogFileName = "AGsFailoverForPatching.txt"
$LogFilePath = "\\ShareFolderLOG"
$LogFile = "$LogFilePath\$LogFileName"

#Configuration file path and name
$AGsConfigFileName = "initial_state.json"
$AGsConfigFilePath = "\\ShareFolder\LOG"
$AGsConfigFile = "$AGsConfigFilePath\$AGsConfigFileName"

###################################################################
#Restore Availability Group configuration for all instances
Out-Log -Type INFO "START TO RESTORE AVAILABILITY GROUPS CONFIGURATION"

#Call the function AGsRestoreConfiguration
$instances = @('server1\Instance1','server1\Instance2','server1\Instance3','server1\Instance4','server2\Instance1','server2\Instance2','server2\Instance3','server2\Instance4')
AGsRestoreConfiguration -instances $instances -ConfigFile $AGsConfigFile

Out-Log -Type INFO "Availability Group configuratons restored successfully"
Out-Log -Type INFO "******************** END PROCESS ********************"

• Schedule is the third Sunday of each month at 00:01AM with a duration of 2 hours. With this schedule this job will be executed after the end of the first one. In Qualys there is for the moment no possibility to start a job when another one is completed…
• For options, I select the Reboot Countdown to send a message to the users of the server before the reboot, a message is also sent to a distribution list at the execution start and after completion to admin and the patches will try to be downloaded by the Qualys agent before the job schedule.

Both jobs are now created. After their execution the two Always On cluster nodes will have been patched and the Availability Groups redistributed as it was before to start.

Qualys Patch Management is relatively easy to use. All patches based on your selection are availables and can be applied easily.
The pre and post actions give the possibility to prepare the patching: here fail-over, save the inital configuration, redistribute the AGs at the end.
It was a good experience and I hope it can help

L’article How to patch SQL Server instances with Qualys Patch Management est apparu en premier sur dbi Blog.

The source of the issue is coming from a PowerShell script executing some dbatools cmdlets. This script is executed inside an agent job so by the SQL Server service account which is sysadmin of all instances.
I will reproduce the issue on my lab environment.

This script sniffs instances for a multiple instance server with the cmdlet Find-DbaInstance, it returns a list of instances:

The instance list received will then be used to gather some information, for example with the cmdlet Get-DbaDatabase:

The login failed is visible here but, of course, when it’s part of a job you don’t have it so obviously but you can see it on the SQL Server logs or in the logs of the job:

The question is more why do we have a failed login for the service account which is sysadmin of all instances.
As we have SQL Server 2019 and SQL Server 2022 with Always Availability Group on this server, we put in place contained availability group for our SQL Server 2022 instances.
A the creation of the contained availability groups we used an active directory service account which was sysadmin of all instances which has been replaced a bit later by a group managed service account. This new gmsa is also sysadmin of all instances.
The problem is coming from the creation of the contained availability group and how this contained AG manages logins, users…
Logins part of the instance are local to the instance and won’t be copied to the system database of the contained AG when you create it. What does it means? It means that if you have created a database with logins and users before the creation of the contained AG, when you move your database in the contained AG, logins and users won’t be part of this contained AG. Users won’t be able to connect to the database until you connect in the context of your contained AG through the listener and recreate those logins.
There is one exception, all logins mapped with the sysadmin server role will be copied automatically to the master system database of a created contained AG.
It was the case of our old service account which has been copied to all our contained AG, but when we changed it to a new group managed service account, this new login, even with sysadmin server role has not been copied automatically to the master database of the contained AG. This conduct to our failed login when the gmsa tries to connect to databases part of a contained AG.

This problem seems to be evident but contained AG has been introduced with SQL Server 2022 while AwaysOn Availability Groups with SQL Server 2012. As DBA, we took some habits with availability groups which cannot be reproduced with contained AG. So take care if you or one of your customer use them to change your way of thinking and remember the contained AG specificities

L’article Contained Availability Group and login failed est apparu en premier sur dbi Blog.

• Full backup with copy_only
• Transaction log backup

So we cannot perform:

• Normal Full backup
• Differential backup
• Transaction Log backup with copy_only

Those limitations may cause some problems during point-in-time restore as with copy_only backup point-in-time restore is not possible. This can lead to point-in-time restore taking lots of time because the last Full backup without copy-only is far away on time and we need to apply thousands of transaction log backups or in worst inability to execute point-in-time restore…

With SQL Server 2025, not just Full backups with copy_only are available on secondary replicas, it introduces normal Full backups as well as Differential backups.
To perform those new backups on secondary replicas we need to enable specific trace flags:

• Trace flag 3261 will enable differential backups on secondary replicas
• Trace flag 3262 will enable full backups on secondary replicas

First of all we need to install the new SQL Server Management Studio 21, two SQL Server 2025 CTP2 instances and configure an Always On Availability Group with backup Preferences set to Prefer Secondary.

Before to try the new Full and Differential backups on a secondary replica with the trace flags, lets try to run a Full backup without copy_only on a secondary:

As expected it fails.

Lets try to configure those new backups and enable the new trace flags, here globally, but we will do it with -T in the startup parameters of the SQL Service to persist them later on:

Once done on my two cluster nodes, I will try to execute a Full backup of the AdventureWorks database on a secondary replica:

My Full backup succeeds and it’s not a Full backup with copy_only but a normal one:

We can also execute a Differential backup and as we can see my Incremental backup has been executed successfully:

Removing the backup workload from the primary replica and relocate it on the secondary is a great benefit. Before SQL Server 2025, this configuration was not robust as it should be due to the copy_only restriction and the inability to execute Differential backup.
With this new version no doubt that more and more customers will move to this configuration. Of course backup jobs need to be tuned to just execute the backup when the database is on its preferred backup replica but most of the backup jobs already check that

L’article SQL Server 2025 – Backups to secondary replicas of an availability group est apparu en premier sur dbi Blog.

Introduction

For reminder, PowerShell 7 is an open-source and cross-platform edition of PowerShell. It means that it can be used on Windows platforms but also on MacOS or Linux.
The good point is that you can install it without removing Windows PowerShell 5.1. Both version can cohabit because of:

• Separate installation path and executable name
  • path with 5.1 like $env:WINDIR\System32\WindowsPowerShell\v1.0
  • path with 7 like $env:ProgramFiles\PowerShell\7
  • executable with PowerShell 5.1 is powershell.exe and with PowerShell 7 is pwsh.exe
• Separate PSModulePath
• Separate profiles for each version
  • path with 5.1 is $HOME\Documents\WindowsPowerShell
  • path with 7 is $HOME\Documents\PowerShell
• Improved module compatibility
• New remoting endpoints
• Group policy support
• Separate Event logs

Installation

To install PowerShell 7 on Windows Servers the easiest way is to use a MSI package. The last version to download is the 7.5.0. Once downloaded, double click the msi file and follow the installation:

By default and as mentioned previously, PowerShell 7 will be installed on C:\Program Files\PowerShell\ :

Some customization are possible, we will keep the default selections:

Starting with PowerShell 7.2, it is possible to update PowerShell 7 with traditional Microsoft Update:

After some seconds installation is done:

We can start the PowerShell 7 with the cmd pwsh.exe. As we can see below both versions coexist on my Windows Server:

New features

PowerShell 7 introduces some interesting new features compare to PowerShell 5.

• ForEach-Object with parallel execution
  Execute the script block in parallel for each object. A parameter ThrottleLimit limits the number of script blocks running at the same time, default value is 5.
  Here we search the instance properties by server and limit the parallelization to 2 server at the same time.
  $computers = ‘thor90′,’thor91′,’thor10′,’thor11’
  $InstanceProperties = $computers | ForEach-Object -Parallel {
  $instances = (Find-DbaInstance -ComputerName $_).SqlInstance;
  Get-DbaInstanceProperty -SqlInstance $instances
  } -ThrottleLimit 2
  
• Ternary operator
  A simplified if-else statement with <condition> ? <condition true> : <condition false>
  
• Pipeline chain operators
  The && operator executes the right-hand pipeline, if the left-hand pipeline succeeded. Reverse, the || operator executes the right-hand pipeline if the left-hand pipeline failed.
  
• coalescence, assignment and conditional operators
  PowerShell 7 includes Null coalescing operator ??, Null conditional assignment ??=, and Null conditional member access operators ?. and ?[]
  
• New management of error message and new cmdlet Get-Error
  This new cmdlet Get-Error displays the full detailed of the last error with inner exceptions.
  A parameter Newest allows to select the number of error you would like to display

On this blog, post I would to concentrate to the parallelization with the ForEach-Object -Parallel

PowerShell 7 parallelization

This new feature comes with the know ForEach-Object cmdlet which performs an operation on each item in a collection of input objects.
Starting with PowerShell 7.0 a new parameter set, called “Parallel”, gives the possibility to run each script block in parallel instead of sequentially. The “ThrottleLimit” parameter, if used, limits the number of script blocks which will run at the same time, if it is not specified the default value is 5.

ForEach-Object -Parallel <scriptblock> -ThrottleLimit

We can test this new feature with a small example.
If we execute the following script as before, the script block is executed sequentially:

PS C:\Users\administrator.ADSTS> 1..16 | ForEach-Object { Get-Date; sleep 10 }

Friday, February 14, 2025 9:00:02 AM
Friday, February 14, 2025 9:00:12 AM
Friday, February 14, 2025 9:00:22 AM
Friday, February 14, 2025 9:00:32 AM
Friday, February 14, 2025 9:00:42 AM
Friday, February 14, 2025 9:00:52 AM
Friday, February 14, 2025 9:01:02 AM
Friday, February 14, 2025 9:01:12 AM
Friday, February 14, 2025 9:01:22 AM
Friday, February 14, 2025 9:01:32 AM
Friday, February 14, 2025 9:01:42 AM
Friday, February 14, 2025 9:01:52 AM
Friday, February 14, 2025 9:02:02 AM
Friday, February 14, 2025 9:02:12 AM
Friday, February 14, 2025 9:02:22 AM
Friday, February 14, 2025 9:02:32 AM

Each line as 10 seconds more than the previous one.
But, if we execute this script with the new parameter Parallel and use a throttle limit of 4 we have:

PS C:\Users\administrator.ADSTS> 1..16 | ForEach-Object -Parallel { Get-Date; sleep 10 } -ThrottleLimit 4

Friday, February 14, 2025 8:59:01 AM
Friday, February 14, 2025 8:59:01 AM
Friday, February 14, 2025 8:59:01 AM
Friday, February 14, 2025 8:59:01 AM
Friday, February 14, 2025 8:59:11 AM
Friday, February 14, 2025 8:59:11 AM
Friday, February 14, 2025 8:59:11 AM
Friday, February 14, 2025 8:59:11 AM
Friday, February 14, 2025 8:59:21 AM
Friday, February 14, 2025 8:59:21 AM
Friday, February 14, 2025 8:59:21 AM
Friday, February 14, 2025 8:59:21 AM
Friday, February 14, 2025 8:59:31 AM
Friday, February 14, 2025 8:59:31 AM
Friday, February 14, 2025 8:59:31 AM
Friday, February 14, 2025 8:59:31 AM

Here we have 4 groups of 4 lines with the same time as we executed the script block in parallel with limitation of the parallelization to 4.
Of course, the different commands included in the script block are executed sequentially.

This feature uses the PowerShell runspaces to execute script blocks in parallel.
Variables can be passed into the script block with the $using: keyword, the only variable automatically passed is the pipe object.
Each runspace will execute a script block in a thread, so the ThrottleLimit parameter needs to be set according to the number of core of the server where you are running. If you VM has 2 cores, it makes no sense to put the limit to 4…

This new script will execute a maintenance job on different instances of the same server, passing the job name in the block script with the $using: keyword:

PS C:\Users\administrator.ADSTS> $ThrottleLimit = 2
PS C:\Users\administrator.ADSTS> $JobName = 'DBI_MAINTENANCE_MAINTENANCE_USER_DATABASES'
PS C:\Users\administrator.ADSTS> $computers = 'thor90'
PS C:\Users\administrator.ADSTS> $SqlInstances = Find-DbaInstance -ComputerName $computers -EnableException
PS C:\Users\administrator.ADSTS> $SqlInstances

ComputerName InstanceName SqlInstance    Port  Availability Confidence ScanTypes
------------ ------------ -----------    ----  ------------ ---------- ---------
thor90       CMS          thor90\CMS     50074 Available    High       Default
thor90       SQL16_1      thor90\SQL16_1 62919 Available    High       Default
thor90       SQL19_1      thor90\SQL19_1 1433  Available    High       Default
thor90       SQL22_1      thor90\SQL22_1 50210 Available    High       Default
thor90       MSSQLSERVER  thor90         1434  Available    High       Default

PS C:\Users\administrator.ADSTS> $SqlInstances | ForEach-Object -Parallel {
>>     $Out = "Starting Job on $using:JobName [" + $_.SqlInstance + "]"
>>     Write-Host $Out
>>     $res = Start-DbaAgentJob -SqlInstance $_.SqlInstance -Job $using:JobName -Wait
>> } -ThrottleLimit $ThrottleLimit
Starting Job on DBI_MAINTENANCE_MAINTENANCE_USER_DATABASES [thor90\CMS]
Starting Job on DBI_MAINTENANCE_MAINTENANCE_USER_DATABASES [thor90\SQL16_1]
Starting Job on DBI_MAINTENANCE_MAINTENANCE_USER_DATABASES [thor90\SQL19_1]
Starting Job on DBI_MAINTENANCE_MAINTENANCE_USER_DATABASES [thor90\SQL22_1]
Starting Job on DBI_MAINTENANCE_MAINTENANCE_USER_DATABASES [thor90]
PS C:\Users\administrator.ADSTS>

We use this kind of script at a customer place to execute SQL Server Agent Jobs in parallel on instances of a big physical servers with more than 10 instances.

Conclusion

This PowerShell 7 parallelization feature can improve performance in lots of different scenarios. But test it and don’t think that because of parallelization all your scripts will be executed quickly as running a script in parallel adds some overhead which will decrease execution of trivial script.

L’article Starting with PowerShell 7 and parallelization est apparu en premier sur dbi Blog.

To find out which queries are running against your instance or a specific database you have multiples solutions going from the “old school” SQL Server Profiler to a more recent one the Extended Event sessions and even the Query Store which can help. In my case the Query Store was not enable, my customer is running SQL Server 2016 Enterprise Edition, so I started it.
I created an Extended Event session where I selected the rpc_completed event and started it during the load process.
I quickly found out the guilty query which was a classical parameterized Dynamic SQL executed with sp_executesql.

The script is looking as follow:

exec sp_executesql N'SELECT ...... FROM ..... WHERE ..... GROUP BY ..... ORDER BY .....' ,N'@P0 date,@P1 date,@P2 date','2023-10-20','1900-01-01','2023-10-27'

When I ran it on my Management studio with the same parameters the duration was around 35 minutes to retrieve 6200 rows (another query runs after this one to load the 240’000 based on those ones but this query is fast enough):

If I check in my Query Store for the Top Resource Consumers for my database, I can find my query:

Now the question is: “How can I boost this query?”.
By chance I followed last year a SQL Bits session from Erik Darling about Performance Tuning and Parameter Sniffing.
During its session Erik spoke about the possibility to use the hint OPTIMIZE FOR.
Here as I have three parameters I will use the hint OPTIMIZE FOR UNKNOWN which will tell SQL Server to make a blind assumption to completely kill parameter sniffing for my three parameters.
My new script will look like:

exec sp_executesql N'SELECT ...... FROM ..... WHERE ..... GROUP BY ..... ORDER BY ..... OPTION (OPTIMIZE FOR UNKNOWN)' ,N'@P0 date,@P1 date,@P2 date','2023-10-20','1900-01-01','2023-10-27'

When I execute my script now, the magic happens, the time to execute the query is now less than 5 seconds:

The tricky part is that the query is generated automatically by the application which is not developed in house, so how can I add my hint to the query?
With SQL Server 2022 and the possibility to add hints via the Query Store the task would have been easy but with SQL Server 2016 it’s not an option.

The solution here is the Plan Guides.
Plan guides give the possibility to optimize the performance of queries when there is no possibility to directly change the text of the actual query in SQL Server. Plan Guides force the optimization of queries by adding query hints or a fixed query plan to them. They can be used when queries coming from applications provided by a third-party vendor are not performing as expected.
In the Plan Guide, you need to mention the T-SQL statement that you need to optimize and add an OPTION clause where you define the query hints you want to use or a specific query plan you want to use to optimize the query. During execution of the query, SQL Server will match the T-SQL statement of the query to the Plan Guide and will attach the OPTION clause to the query at run time or will use the specified query plan.

When we create the Plan Guide, the used T-SQL must exactly match the one provided by the third party application. This query has to be the same as the SQL Server compiler receives. Microsoft advises to use the SQL Server Profiler to capture the actual batch and parameter text. If there are some difference the Plan Guide won’t be used.
Before to know this point, I tried to use the T-SQL text coming from the Query Store or coming from the DMVs sys.dm_exec_sql_text but created Plan Guides were never used during the execution of the query from the application. To avoid to waste time please follow this Microsoft guide.

Once you have your T-SQL statement you can create your Plan Guide with the sp_create_plan_guide Stored Procedure.
My one looks like that:

EXEC sp_create_plan_guide 
@name = N'<database_name> plan guide with hint SQL coming from profiler', 
@stmt = N'the T-SQL catches with my SQL Server Profiler',
@type = N'SQL',
@params = N'@P0 date,@P1 date,@P2 date',
@hints = N'OPTION (OPTIMIZE FOR UNKNOWN)'
GO

Once created you can see your new Plan Guides on SSMS:

When the application will execute again the T-SQL, the Plan Guide will be used and the hint will boost the execution as expected:

We can see that the script duration is much faster with around 5 second instead of 30 minutes and the plan uses the new Plan Guide with the hint we passed.

Plan Guides are very powerful and can help to provide better performance for scripts where direct modifications are not an option. A second option would be to migrate to SQL Server 2022, we are also looking on this direction at my customer place but as it will take some times, Plan Guides will be used in the meantime

L’article Boost dynamic SQL with Plan Guides est apparu en premier sur dbi Blog.

This new feature is based on Distributed Availability Groups. There is no prerequisite to already have an Availability Group or multiple nodes, a single node is working but multiple ones with multiples AGs are also working.

The link can be kept ever or remove after a transition period for a migration with near to zero downtime.

Before to configure a Manage Instance Link as I’m working with SQL Server 2019 we need:

• SQL Server 2019 Enterprise or Developer Edition with CU15 or above
• An Azure SQL Manage Instance

And also prepare our SQL Server instance with some prerequisites:

• Check CU15
• Create a database master key in the master database
• Enable Availability group feature
• Enable trace flags to optimize performance (not required):
  • -T1800: This trace flag optimizes performance when the log files for the primary and secondary replicas in an availability group are hosted on disks with different sector sizes, such as 512 bytes and 4K otherwise it’s not required
  • -T9567: This trace flag enables compression of the data stream for availability groups during automatic seeding. The compression increases the load on the processor but can significantly reduce transfer time during seeding.

Don’t forget to restart the SQL engine if you have just enable Always On Availability Groups feature for your SQL service.

Let’s start to replicate the AdventureWorks database from our on-premise instance to an Azure SQL Managed Instance. The source database must be in Full recovery model and have at least one full backup.
Go to the source database, right click on it and select “Azure SQL Managed Instance link” and “Replicate database”:

An introduction slide explains us the goal, some scenarios and the requirements of this new feature:

Requirements are now checked and they are all met here, for the server but also for Availability Group where the database master key is available:

We can now select one or more databases to replicate to the Azure SQL Managed instance via the link feature. We select here the AdventureWorks2019 database which meets the requirements, it’s means Full recovery model and a Full backup executed:

It’s time to sign in to our Azure Subscription:

Once done we need to select the Managed Instance information which will be our target:

On the following screen we have lots of information:

• The name and the port of the endpoint which will be created for the database mirroring
• the certificate which will be created with an expiry date
• the names for the Availability group and for the Distributed Availability group

A last check to the choices made and click Finish to start the process:

All steps succeeded:

I have now my AdventureWorks database replicated on my Managed instance and ready for read-only workload.
If I check my Distributed Availability group dashboard, I can see that my first replica is my Availability group and my second is the Managed Instance. My AdventureWorks database is synchronized and the last hardened time occurs during my first synchronization.

If I update the column JobTitle on my Employee table on my Source instance, the update will be replicated asynchronously to my secondary database.
My replica database before the update:

I run my script on my primary database:

After some seconds my secondary is again synchronized:

And if I look on my Distributed Availability group, I can see the details with my last hardened time:

We cannot see that the database on the Managed Instance is not a “Standard” one, there is no information written after the database name like Synchronized as it is the case with a secondary database in an Availability group. Nevertheless if we try to run an update statement again this database we receive an error message:

This new Azure Managed Instance link feature is really interesting to off-load analytics and reporting to Azure but can also be used in a migration scenario with near to zero downtime.
It’s also a good way to create a first hybrid scenario before moving to the Cloud.

L’article Azure SQL Managed Instance link feature overview est apparu en premier sur dbi Blog.

Before to create your own checks you can read this wiki which is dedicated to dbachecks development and available on the dbachecks main page. It will give you some advice and standard development guidelines.

To create my new checks I will first create a new file which will contain those checks, lets name it SelfChecks.Tests.ps1.
I would like to add two checks:

• The first one will check the health of my Availability Groups which have to be synchronized and healthy.
  I will tag this check DBinAG.

• The second one will check that all the user databases of my instance are part of an Availability Group with exception of some specifics ones like our dbi_tools database for example.
  I will tag this one DBHealthyInAG.

The PowerShell script will be the following:

$filename = $MyInvocation.MyCommand.Name.Replace(".Tests.ps1", "")

$DBinAG = "IF (SERVERPROPERTY ('IsHadrEnabled') = 1)
BEGIN
	SELECT  name, state_desc
	FROM    sys.databases
	WHERE    name    NOT IN
		(   SELECT  DISTINCT
					drcs.database_name              AS name
			FROM                master.sys.availability_groups                      AS ag
				LEFT OUTER JOIN master.sys.dm_hadr_availability_group_states        AS ags
							ON    ag.group_id       = ags.group_id
				INNER JOIN      master.sys.availability_replicas                    AS ar
							ON   ag.group_id        = ar.group_id
				INNER JOIN      master.sys.dm_hadr_availability_replica_states      AS ars
							ON     ar.replica_id    = ars.replica_id
							AND    ars.is_local     = 1
				INNER JOIN      master.sys.dm_hadr_database_replica_cluster_states  AS drcs
							ON     ars.replica_id   = drcs.replica_id
				LEFT OUTER JOIN master.sys.dm_hadr_database_replica_states          AS dbrs
							ON      drcs.replica_id         = dbrs.replica_id
							AND     drcs.group_database_id  = dbrs.group_database_id
			WHERE   ISNULL(ars.role, 3)                 = 1
			OR      ISNULL(drcs.is_database_joined, 0)  = 1
		)
	--AND     dbid  
	AND     name    NOT IN  ('master'
							,'tempdb'
							,'model'
							,'msdb'
							-- add below your exceptions
							,'dbi_tools'
							)
	AND     state_desc  != 'OFFLINE'
	ORDER BY
			name    ASC
END";

(Get-Instance).ForEach{

    Describe –Name "All databases should be in an AG" -Tags DBinAG, $filename {
        Context –Name "All databases should be in an AG on $psitem" {
            It "should have 0 database outide of an AG" {
                Invoke-DbaQuery -SqlInstance $psitem -Query $DBinAG |  
                Measure-Object |
                    Select-Object –ExpandProperty Count |
                    Should -Be 0 –Because "All databases should be in an AG"
            }
        }
    }
}

$DBHealthyInAG = "IF (SERVERPROPERTY ('IsHadrEnabled') = 1)
BEGIN
SELECT  ag.name                             AS [AGName]
        ,adc.[database_name]                AS [DBName]
        ,ar.replica_server_name             AS [ReplicaServerName]
        ,drs.synchronization_state_desc     AS [SynchronizationState]
        ,drs.synchronization_health_desc    AS [SynchronizationHealth]
        ,drs.is_local                       AS [IsLocal]
        ,ar.availability_mode_desc          AS [AvailabilityMode]
FROM    sys.dm_hadr_database_replica_states                 AS drs WITH (NOLOCK)
        INNER JOIN sys.availability_databases_cluster       AS adc WITH (NOLOCK)
            ON  drs.group_id            = adc.group_id
            AND drs.group_database_id   = adc.group_database_id
        INNER JOIN sys.availability_groups                  AS ag WITH (NOLOCK)
            ON  ag.group_id             = drs.group_id
        INNER JOIN sys.availability_replicas                AS ar WITH (NOLOCK)
            ON  drs.group_id            = ar.group_id
            AND drs.replica_id          = ar.replica_id
WHERE   1=1
AND NOT (   drs.synchronization_state_desc  = 'SYNCHRONIZED'
        AND drs.synchronization_health_desc = 'HEALTHY'
        )
ORDER BY
        ag.name
        ,ar.replica_server_name
        ,adc.[database_name]        OPTION (RECOMPILE)
END";

(Get-Instance).ForEach{

    Describe –Name "All databases should be synchronized and healthy in an AG" –Tags DBHealthyInAG, $filename {
        Context –Name "All databases should be synchronized and healthy in an AG on $psitem" {
            It "should have 0 unsynchronized and unhealthy databases" {
                Invoke-DbaQuery -SqlInstance $psitem -Query $DBHealthyInAG |  
                Measure-Object |
                    Select-Object –ExpandProperty Count |
                    Should -Be 0 –Because "All databases need to be synchronized and healthy"
            }
        }
    }
}

When we install the dbachecks, Pester tests & checks are stored in a particular folder and to find where we can run the cmdlet:

Get-DbcConfig -Name app.checkrepos

Result is:

To add my checks to the list of the available checks I need to add the location of my file to this configuration value.
I can do it with the cmdlet:

Set-DbcConfig -Name app.checkrepos -Value 'C:\dbachecks\OwnChecks\' -Append

Now, my folder has been added to the check repo:

I’m able to call my two new tags as I would do for “existing” ones and the result is:

All my databases are part of an Always On Availability Group and my AG are healthy & synchronized

I was able to add my two new checks and if I need another ones, I can add them to my file.

Quite easy no?

L’article dbachecks: how to add your own checks est apparu en premier sur dbi Blog.

First we need a SQL Credential to be able to remotely connect to the server where we will patch our instances:

$OScred = Get-Credential;

Once done we will have to find the instances located on the server. Here multiple possibilities:

• you can create just a list with your instances $InstanceList = @(‘Thor90\SQL19_1′,’Thor91\SQL19_1’);
• you can search the instance on your server with $InstanceList = Get-DbaService | where-object { $_.ServiceType -eq ‘Engine’ -and $_.State -eq ‘Running’ };
• you can also select your instance in your CMS with $InstanceList = Get-DbaRegServer -SqlInstance ‘Thor90\CMS’ -Group “Prod\SQL2019”; (my case)

Now that we have our list of instances, we will loop on those instances, run a quick connection test and if it succeeds patch our instance.
To patch the instance, I will use 2 dbatools cmdlets which are:

• Get-DbaBuildReference: will return information about the instance like the SP, CU and used with the -Update switch will update the local reference with the most up to date one
• Update_DbaInstance: will start a process which will update a SQL Server instance to a specified version
  This cmdlet is really powerful with lots of parameter, possible options and also risks, I let you go through its definition.
  I will use it in my example with the -version parameter which is the target version I want to reach, with the switch -Restart to automatically restart my server after the installation, the parameter -Path to specif the location where my patches have been downloaded, the -Credential to have permission to log remotely to my server and -Confirm to false to run without confirmation.

I’ll use also some logging cmdlets wrote by myself which are Out-Log, Add-Warning and Add-Error.

The loop on all my instance list will look like:

ForEach ($Instance in $InstanceList){
     Out-Log -Message "Patching instance $($Instance.InstanceName)" -LogFile $LogFile
        
    $connection = Test-DBAConnection -SqlInstance $instance.InstanceName -WarningVariable warningvar;
    Add-Warning -Warning $Warningvar;
    If ($connection -and $connection.ConnectSuccess) {
        Out-Log -Message "Connection to instance $($Instance.InstanceName) succeeded" -LogFile $LogFile

        #Update the instance build which is used by the cmdlet Update-DbaInstance
        Out-Log -Message "Update the build of the instance $($Instance.InstanceName)" -LogFile $LogFile
        Get-DbaBuildReference -SqlInstance $instance.InstanceName -Update -WarningVariable warningvar;
        Add-Warning -Warning $Warningvar;

        Out-Log -Message "Start patching of the instance $Instance.InstanceName" -LogFile $LogFile
        try {
            $res = Update-DbaInstance -ComputerName $Instance.ComputerName -InstanceName $Instance.InstanceName -credential $OScred -Version CU16 -Path \\Thor90\sources\SQL2019 -Restart -Confirm:$false -WarningVariable warningvar;
            Add-Warning -Warning $Warningvar;
        }
        catch {
            Add-Error -Message "Patching of the instance $instance$Instance.InstanceName not possible, Exception: $($error[0].Exception.Message)";
        }

    }
    Else {
        Add-Error -Message "Impossible to connect to the instance $instance$Instance.InstanceName.";
    }
}

This script will patch my production SQL Server 2019 instances to CU16 with the KB located on my share drive \\Thor90\sources\SQL2019 and restart the server once succeeded.
Lots of scenario can be covered by using this cmdlet, I let you playing with it, but on your test environment first

L’article Patch a SQL Server instance automatically with PowerShell est apparu en premier sur dbi Blog.

As usual, each time I have to deal with SQL Server and PowerShell I have a look to the famous dbatools pages to check if I can find useful cmdlets. Jackpot, somes attired my attention, I will present you those later on.

I want to download the last Cumulative Update and Service pack for the SQL Server versions 2014 to 2019. I create a list with the RTM build of each version:

#List of build for the RTM version from 2014 to 2019
$RTMBuilds = @('12.0.2000','13.0.1601','14.0.1000','15.0.2000');

I need also a share path to save my SP and CU:

#Path where files will be downloaded
$Path = "\\THOR90\Sources";

I will loop on each build and use the dbatool cmdlet Test-DbaBuild to find the last Cumulative Update for the RTM version in the loop. This cmdlet used with the parameters -Build with my RTM build number and -MaxBehind “0CU” provides me the target build number of the last Cumulative Update for my SQL Server version. There is just a small exception for the moment with SQL Server 2016 where the last patch is a Service Pack and there is no CU for the moment for this Service Pack. In this case, I need to check for the version -1 of the last SP and find the last CU for this SP, it means change the parameter -MaxBehind to “1SP 0CU”. Here is the code:

#Download last CU
$res = Test-DbaBuild -Build $RTMBuild -MaxBehind "0CU";
#$test special case where the last build is a SP, to download the last CU before this SP
if ($res.CUTarget -eq $null) {
    $res = Test-DbaBuild -Build $RTMBuild -MaxBehind "1SP 0CU"; 
}

This code applied to the RTM build of SQL Server 2016 returns:

Build : 13.0.1601
BuildLevel : 13.0.1601
BuildTarget : 13.0.5888
Compliant : False
CULevel :
CUTarget : CU17
KBLevel :
MatchType : Exact
MaxBehind : 1SP 0CU
NameLevel : 2016
SPLevel : RTM
SPTarget : SP2
SupportedUntil : 1/9/2018 12:00:00 AM

It means that the last CU available for SQL Server 2016 is the CU17.
Now, I need to find the KB number corresponding to the build number of my CU17. I will use the dbatools cmdlet Get-DbaBuildReference to retrieve it.
Once I have my KB, I will use another dbatools cmdlet named Get-DbaKbUpdate which will parse the catalog.update.microsoft.com and grab details for KB files.
I can have multiple links to download my KB such as a link for the 32 bits version and another one for the 64 bits. I will use the 64 bits and select just the file name to download it with the last dbatools cmdlet used in this blog.

$BuildTarget = $res.BuildTarget;
$kb = (Get-DbaBuildReference $BuildTarget).KBLevel;
$resKB = Get-DbaKbUpdate $kb;
    
#Find the file name and check that it is the x64
$file = ($resKB.Link | Select-Object -Last 1) -split ('/') | Select-Object -last 1;
if ($file.IndexOf("x64") -eq -1)
    { $file = ($resKB.Link | Select-Object -First 1) -split ('/') | Select-Object -last 1; }

As I have now my file name, I will download this file from Microsoft and save it on my share with the dbatools cmdlet Save-DbaKbUpdate. If the file already exists on my share I will not download it.

#Download the file if it is not already done
if (!(Test-Path "$Path\$file" -PathType Leaf)) {
    Write-Output "downloading $file"
    Save-DbaKbUpdate $kb -Path $Path
    } 
    else {write-output "File $file already exists" }

This first part of the script download the last CUs, to download the last SPs I will use exactly the same script when the major build version is lower or equal to 13 (SQL Server 2016) and save them also to my share:

################################### SP
#Download the last SP if version <=2016
if ($res.BuildTarget.Major -le 13) {
    $res = Test-DbaBuild -Build $RTMBuild -MaxBehind "0SP";
    $BuildTarget = $res.BuildTarget;
    $kb = (Get-DbaBuildReference $BuildTarget).KBLevel;
    $resKB = Get-DbaKbUpdate $kb;
        
    #Find the file name and check that it is the x64
    $file = ($resKB.Link | Select-Object -Last 1) -split ('/') | Select-Object -last 1;
    if ($file.IndexOf("x64") -eq -1)
        { $file = ($resKB.Link | Select-Object -First 1) -split ('/') | Select-Object -last 1; }
        
    #Download the file if it is not already done
    if (!(Test-Path "$Path\$file" -PathType Leaf)) {
        Write-Output "downloading $file"
        Save-DbaKbUpdate $kb -Path $Path
        } 
        else {write-output "File $file already exists" }
}

Finally, I have all my Cumulative Updates and Service Packs available on my share. I can schedule the complete script every month to have always on my share the last available CU and SP for the SQL Server versions I have on my environment.
The next step will be to apply those patches to my SQL Server instances.
It will be the subject of my next blog post.

L’article How to automatically download last SQL Server SP and CU with PowerShell est apparu en premier sur dbi Blog.

I used the wizard to create a new Contained Availability Group and chose the Full database and lo backup synchronization method to restore database on my secondary instance.
I generated the script and ran it.

I was a bit confused to receive an error message.
It looks like that the master database has to be joined and recovered before the user databases in a Contained Availability group:

Msg 47148, Level 16, State 13, Line 180
Cannot join database ‘AdventureWorks’ to contained availability group ‘AAG_Thor9091_C01’. Before joining other databases to contained availability group, contained availability group master database has to be joined and recovered. Make sure contained availability group master database has been joined and recovered, then retry the operation.

If I check on my primary, my Contained Availability Group looks good with my master & msdb system databases and my AdventureWorks database are marked as Synchronized:

But if I check the dashboard of my Availability Group or even my secondary instance I can see that my AdventureWorks database is on Restoring mode, as pointed out by the previous error, and I have no master nor msdb databases:

If I check the SQL logs on the primary instance I can see that my master and msdb database have been backed up but I have no trace of the restore on my secondary instance compare to the AdventureWorks database for which I can find a restore operation.

I dropped my Contained Availability Group and recreate the exactly same one but with the seeding synchronization method, I generate the scripts and run it:

No all is working perfectly, my master and msdb databases have been restored after some seconds to my secondary, the DMV dm_hadr_physical_seeding_stats shows that the success of the seeding method and my Contained Availability Group is synchronized on my 2 nodes.

I did those test with SQL Server 2022 CTP2.0 so no doubt that this issue will be fixed for the RTM version
You can also read the blog of my colleague Steven on Contained Availability Group to have an overview of this feature.

L’article Contained Availability Groups error est apparu en premier sur dbi Blog.