To address this issue, it is possible to automate the solution with PowerShell. The idea is to automate the different operations involved in the snapshot backup and restore process.

We will use two scripts:

• One script to perform the backups and create the snapshots.
• One script to perform the restores.

Backup process

Here is how the backup process works:

• We connect to the corresponding SQL Server instance.
• We change the state of the database using ALTER DATABASE … SET SUSPEND_FOR_SNAPSHOT_BACKUP = ON. At this point, the I/Os are frozen.
• We connect to the hypervisor through SSH.
• We create the snapshot.
• We back up the database using BACKUP DATABASE … WITH METADATA_ONLY.
• We change the state of the database using ALTER DATABASE … SET SUSPEND_FOR_SNAPSHOT_BACKUP = OFF. At this point, the I/Os are unfrozen.

Powershell implementation (backup)

Here is the code used to perform the backup:

param(
    [string]$SqlInstance = "VM-WS25-SQL2",
    [string]$Database    = "StackOverflow",
    [string]$BackupDir   = "D:\Backups",
    [string]$PveHost     = "192.168.1.110",
    [string]$PveUser     = "MyUser",
    [string[]]$Zvols     = @("sqlpool/pve/vm-302-disk-0")
)

$Timestamp = Get-Date -Format "yyyyMMddTHHmmss"
$SnapName  = "sql_${Database}_${Timestamp}"

$DbSafe = $Database.Replace("]", "]]")
$BackupFile = Join-Path $BackupDir "${Database}_${Timestamp}.bkm"

$ZfsSnapshots = $Zvols | ForEach-Object { "$_@$SnapName" }
$ZfsSnapshotArgs = $ZfsSnapshots -join " "

$MediaDescription = "zfs|$PveHost|$ZfsSnapshotArgs"

$BackupFileSql = $BackupFile.Replace("'", "''")
$MediaSql = $MediaDescription.Replace("'", "''")

$connString = "Server=$SqlInstance;Database=master;Integrated Security=True;TrustServerCertificate=True;Application Name=ZFS-TSQL-Snapshot;"
$conn = New-Object System.Data.SqlClient.SqlConnection $connString

function Invoke-SqlNonQuery {
    param([string]$Sql)

    $cmd = $conn.CreateCommand()
    $cmd.CommandTimeout = 0
    $cmd.CommandText = $Sql
    [void]$cmd.ExecuteNonQuery()
}

try {
    $conn.Open()

    Write-Host "Freezing SQL database writes..."
    Invoke-SqlNonQuery "ALTER DATABASE [$DbSafe] SET SUSPEND_FOR_SNAPSHOT_BACKUP = ON;"

    Write-Host "Taking ZFS snapshot on Proxmox..."
    ssh "$PveUser@$PveHost" "zfs snapshot $ZfsSnapshotArgs && zfs hold sqlsnap $ZfsSnapshotArgs"

    if ($LASTEXITCODE -ne 0) {
        throw "ZFS snapshot failed on $PveHost"
    }

    Write-Host "Writing SQL metadata backup..."

    Invoke-SqlNonQuery @"
BACKUP DATABASE [$DbSafe]
TO DISK = N'$BackupFileSql'
WITH METADATA_ONLY,
     MEDIADESCRIPTION = N'$MediaSql',
     NAME = N'$SnapName';
"@

    Write-Host "Snapshot backup completed:"
    Write-Host "  Snapshot: $ZfsSnapshotArgs"
    Write-Host "  Metadata: $BackupFile"
}
catch {
    Write-Warning $_

    try {
        Write-Warning "Attempting to unfreeze SQL database..."
        Invoke-SqlNonQuery "ALTER DATABASE [$DbSafe] SET SUSPEND_FOR_SNAPSHOT_BACKUP = OFF;"
    }
    catch {
        Write-Warning "Could not unfreeze cleanly. Check SQL Server error log."
    }

    throw
}
finally {
    $conn.Close()
}

Restore process

Here is how the restore process works:

• We connect to the corresponding SQL Server instance.
• We take the database offline.
• The volume dedicated to the StackOverflow database is taken offline.
• We connect to the hypervisor through SSH.
• We roll back the corresponding snapshot.
• We restore the database using the corresponding backup, which was created at the same time as the snapshot.

Powershell implementation (restore)

Here is the code used to perform the restore:

param(
    [string]$SqlInstance = "VM-WS25-SQL2",
    [string]$Database    = "StackOverflow",
    [string]$BackupFile  = "D:\Backups\StackOverflow_20260514T122642.bkm",
    [string]$SnapName    = "sql_StackOverflow_20260514T122642",
    [string]$PveHost     = "192.168.1.110",
    [string]$PveUser     = "MyUser",
    [string[]]$Zvols     = @("sqlpool/pve/vm-302-disk-0"),
    [string[]]$DatabaseDriveLetters = @("T"),
    [switch]$NoRecovery
)

$ErrorActionPreference = "Stop"

function Assert-SafeName {
    param(
        [string]$Value,
        [string]$Name,
        [string]$Pattern
    )

    if ($Value -notmatch $Pattern) {
        throw "$Name contained not allowed characters : $Value"
    }
}

function Normalize-DriveLetter {
    param([string]$DriveLetter)

    $letter = $DriveLetter.Trim().TrimEnd(":").ToUpperInvariant()

    if ($letter -notmatch '^[A-Z]$') {
        throw "Drive letter invalid : $DriveLetter"
    }

    return $letter
}

function Get-DiskForDriveLetter {
    param([string]$DriveLetter)

    $letter = Normalize-DriveLetter $DriveLetter

    $partition = Get-Partition -DriveLetter $letter -ErrorAction Stop
    $disk = $partition | Get-Disk -ErrorAction Stop

    return [pscustomobject]@{
        DriveLetter = $letter
        DiskNumber  = [int]$disk.Number
        IsOffline   = [bool]$disk.IsOffline
        FriendlyName = $disk.FriendlyName
        Size        = $disk.Size
    }
}

function Invoke-SshChecked {
    param([string]$Command)

    Write-Host "SSH $PveUser@$PveHost :: $Command"

    & ssh "$PveUser@$PveHost" "$Command"

    if ($LASTEXITCODE -ne 0) {
        throw "SSH command failed with code $LASTEXITCODE : $Command"
    }
}

function New-SqlConnection {
    $connString = "Server=$SqlInstance;Database=master;Integrated Security=True;TrustServerCertificate=True;Application Name=ZFS-TSQL-Restore-NoVmRestart;"
    return New-Object System.Data.SqlClient.SqlConnection $connString
}

function Invoke-SqlNonQuery {
    param([string]$Sql)

    $conn = New-SqlConnection

    try {
        $conn.Open()
        $cmd = $conn.CreateCommand()
        $cmd.CommandTimeout = 0
        $cmd.CommandText = $Sql
        [void]$cmd.ExecuteNonQuery()
    }
    finally {
        $conn.Close()
    }
}

function Invoke-SqlScalar {
    param([string]$Sql)

    $conn = New-SqlConnection

    try {
        $conn.Open()
        $cmd = $conn.CreateCommand()
        $cmd.CommandTimeout = 0
        $cmd.CommandText = $Sql
        return $cmd.ExecuteScalar()
    }
    finally {
        $conn.Close()
    }
}

function Set-DatabaseDisksOffline {
    param([object[]]$DiskInfos)

    $offlinedByScript = @()

    foreach ($diskInfo in ($DiskInfos | Sort-Object DiskNumber -Unique)) {
        if ($diskInfo.IsOffline) {
            Write-Host "Disque $($diskInfo.DiskNumber) déjà offline. Lecteur $($diskInfo.DriveLetter):"
            continue
        }

        Write-Host "Taking the Windows disk offline $($diskInfo.DiskNumber), drive $($diskInfo.DriveLetter):"
        Set-Disk -Number $diskInfo.DiskNumber -IsOffline $true

        $offlinedByScript += $diskInfo
    }

    return $offlinedByScript
}

function Set-DatabaseDisksOnline {
    param([object[]]$DiskInfos)

    foreach ($diskInfo in ($DiskInfos | Sort-Object DiskNumber -Unique)) {
        Write-Host "Bringing the Windows disk back online. $($diskInfo.DiskNumber), drive $($diskInfo.DriveLetter):"
        Set-Disk -Number $diskInfo.DiskNumber -IsOffline $false
    }

    Write-Host "Update-HostStorageCache..."
    Update-HostStorageCache
}

Assert-SafeName -Value $SnapName -Name "SnapName" -Pattern '^[A-Za-z0-9_.:-]{1,160}$'

foreach ($zvol in $Zvols) {
    Assert-SafeName -Value $zvol -Name "Zvol" -Pattern '^[A-Za-z0-9_.:/-]{1,240}$'
}

$DbQuoted = "[" + $Database.Replace("]", "]]") + "]"
$DbLiteral = $Database.Replace("'", "''")
$BackupFileSql = $BackupFile.Replace("'", "''")

$ZfsSnapshots = $Zvols | ForEach-Object { "$_@$SnapName" }
$ZfsSnapshotArgs = ($ZfsSnapshots | ForEach-Object { "'$_'" }) -join " "

$RecoveryOption = if ($NoRecovery) { "NORECOVERY" } else { "RECOVERY" }

$DatabaseDiskInfos = @()
$DisksOfflinedByScript = @()

Write-Host ""
Write-Host "Restore SQL Server from a ZFS snapshot, without restarting the VM"
Write-Host "SQL Instance : $SqlInstance"
Write-Host "Database     : $Database"
Write-Host "BackupFile   : $BackupFile"
Write-Host "DB volumes   : $($DatabaseDriveLetters -join ', ')"
Write-Host "Snapshots    :"
$ZfsSnapshots | ForEach-Object { Write-Host "  $_" }
Write-Host ""

try {
    Write-Host "Checking ZFS snapshots..."
    Invoke-SshChecked "zfs list -H -t snapshot -o name $ZfsSnapshotArgs >/dev/null"

    Write-Host "Identifying Windows disks containing SQL Server files..."
    foreach ($driveLetter in $DatabaseDriveLetters) {
        $diskInfo = Get-DiskForDriveLetter $driveLetter
        $DatabaseDiskInfos += $diskInfo

        Write-Host "Drive $($diskInfo.DriveLetter): -> Windows disk $($diskInfo.DiskNumber) [$($diskInfo.FriendlyName)]"
    }

    $backupDrive = $null
    if ($BackupFile -match '^([A-Za-z]):\\') {
        $backupDrive = Normalize-DriveLetter $Matches[1]

        try {
            $backupDiskInfo = Get-DiskForDriveLetter $backupDrive
            $targetDiskNumbers = @($DatabaseDiskInfos | ForEach-Object { $_.DiskNumber } | Select-Object -Unique)

            if ($targetDiskNumbers -contains $backupDiskInfo.DiskNumber) {
                throw @"
The backup file $BackupFile is located on drive $backupDrive, which is on the same Windows disk as the SQL Server data volume.
Taking the data disk offline would make the .bkm file inaccessible, and a rollback could also make the .bkm file disappear.
Move the .bkm file to C:, a network share, or another disk that is not rolled back.
"@
            }
        }
        catch {
            throw
        }
    }

    Write-Host "Checking whether the SQL Server database exists..."
    $DbExists = Invoke-SqlScalar "SELECT CASE WHEN DB_ID(N'$DbLiteral') IS NULL THEN 0 ELSE 1 END;"

    if ($DbExists -eq 1) {
        Write-Host "Taking database $Database OFFLINE..."
        Invoke-SqlNonQuery @"
ALTER DATABASE $DbQuoted SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE $DbQuoted SET OFFLINE WITH ROLLBACK IMMEDIATE;
"@
    }
    else {
        Write-Host "Database $Database does not exist in SQL Server. Continuing with disk offline and ZFS rollback."
    }

    Write-Host "Taking Windows disks containing MDF/LDF files offline..."
    $DisksOfflinedByScript = Set-DatabaseDisksOffline -DiskInfos $DatabaseDiskInfos

    Write-Host "Rolling back ZFS snapshot..."
    $RollbackCommands = ($ZfsSnapshots | ForEach-Object { "zfs rollback -r '$_'" }) -join "; "
    Invoke-SshChecked "set -e; $RollbackCommands"

    Write-Host "Bringing Windows disks back online..."
    Set-DatabaseDisksOnline -DiskInfos $DisksOfflinedByScript
    $DisksOfflinedByScript = @()

    Write-Host "Short pause to let Windows and SQL Server detect the restored disk state..."
    Start-Sleep -Seconds 5

    Write-Host "Restoring SQL Server metadata-only backup..."

    $RestoreSql = @"
RESTORE DATABASE $DbQuoted
FROM DISK = N'$BackupFileSql'
WITH METADATA_ONLY,
     REPLACE,
     $RecoveryOption;
"@

    Invoke-SqlNonQuery $RestoreSql

    if (-not $NoRecovery) {
        Write-Host "Setting database back to MULTI_USER..."
        Invoke-SqlNonQuery @"
ALTER DATABASE $DbQuoted SET MULTI_USER;
"@
    }

    Write-Host ""
    Write-Host "Restore completed."
    Write-Host "Database : $Database"
    Write-Host "Snapshot : $SnapName"
    Write-Host "Backup   : $BackupFile"
}
catch {
    Write-Warning "Restore failed: $_"

    if ($DisksOfflinedByScript.Count -gt 0) {
        try {
            Write-Warning "Attempting to bring disks offlined by the script back online..."
            Set-DatabaseDisksOnline -DiskInfos $DisksOfflinedByScript
            $DisksOfflinedByScript = @()
        }
        catch {
            Write-Warning "Unable to automatically bring the disks back online. Check with Get-Disk."
        }
    }

    try {
        $DbExistsAfterError = Invoke-SqlScalar "SELECT CASE WHEN DB_ID(N'$DbLiteral') IS NULL THEN 0 ELSE 1 END;"

        if ($DbExistsAfterError -eq 1 -and -not $NoRecovery) {
            Write-Warning "Attempting to set the database back ONLINE/MULTI_USER..."
            Invoke-SqlNonQuery @"
ALTER DATABASE $DbQuoted SET ONLINE;
ALTER DATABASE $DbQuoted SET MULTI_USER;
"@
        }
    }
    catch {
        Write-Warning "Unable to automatically set the database back ONLINE/MULTI_USER."
    }

    throw
}

What does it look like?

We start the backup process:

We verify that the snapshot is present:

We verify that the backup is present:

We drop the StackOverflow database:

We start the restore process:

The database is available again. The restore took only a few seconds for a database of approximately 200 GB.

Major drawbacks

In my case, the solution is executed from the SQL Server itself. Ideally, it should rather be hosted on another server or client machine. We could also imagine running these scripts from a scheduler such as RedDeck, for example.

During the database restore, the database is switched to SINGLE_USER mode. This could be an issue if the applications using the database reconnect very frequently. A better approach would probably be to explicitly terminate the active sessions using the KILL command.

We have also not yet covered the use of a REST API.

Thank you. Amine Haloui

L’article SQL Server Snapshot Backup and Restore with Proxmox ZFS – Powershell implementation (2/4) est apparu en premier sur dbi Blog.

As my colleague Amine Haloui explained in a recent blog post, several strategies exist for migrating an instance. The “Lift and Shift” method (restoring the ReportServer database onto a new instance) is often the most attractive on paper. However, the reality on the ground can be more temperamental.

In some production environments, the target PBIRS instance already exists, hosts its own content, or follows specific configurations that prohibit simply overwriting its underlying ReportServer database. Therefore, we are proceeding here on the premise of a selective and granular migration: we must inject the SSRS catalog into an active PBIRS environment without burning everything to the ground in the process.

When faced with inventories exceeding hundreds or even thousands of reports (RDL), folders, and datasources, a manual approach via the web interface is not an option and automation becomes a necessity.

This article analyzes a systematic approach based on the ReportingServicesTools PowerShell module. The objective is to provide a robust methodology to extract your catalog and redeploy it intelligently, while managing the necessary reconfigurations along the way.

Phase 1: Smart Dumping – Building the Local Staging Area

To migrate cleanly, objects must first be isolated. The idea is not to blindly vacuum everything, but to target the critical folders of your SSRS instance and transform them into flat files (.rdl and .rds) within a local staging area. If your SSRS instance contains specific object types, the scripts can easily be adapted to include them as well.

This is where the power of the SOAP Proxy comes into play. Rather than multiplying slow HTTP calls, we use the native service interface to list and extract our components:

$sourceUrl  = "http://your-ssrs-server/ReportServer"
$exportRoot = "H:\Migration_Dump"

$proxySource = New-RsWebServiceProxy -ReportServerUri $sourceUrl

In a production environment, SSRS folders are often a messy mix of reports, data sources, images, and sometimes obsolete semantic models. To maintain total control over what we export, we isolate the filtering logic.

This Get-AllItemsByType function allows us to retrieve only what truly matters to us, based on the TypeName and file extension returned by the API.

function Get-AllItemsByType {
    param(
        [string]$CurrentPath,
        $Proxy,
        [string]$TypeName 
    )
    try {
        return $Proxy.ListChildren($CurrentPath, $true) | Where-Object { $_.TypeName -eq $TypeName }
    } catch {
        Write-Host "  [!] Error on $CurrentPath : $($_.Exception.Message)" -ForegroundColor Red
        return $null
    }
}

This mapping between the file type and its extension must be defined upfront in a dictionary:

$extensionMap = @{
    "Report" = ".rdl"
    "DataSource" = ".rds"
}

A crucial point in extracting SSRS objects is preserving their context. To ensure a seamless import into PBIRS 2025, we must recreate the exact folder hierarchy of the source server locally.

The trick lies in transforming the SSRS path (formatted as /Folder/SubFolder/Report) into a valid Windows path, while simultaneously handling the extension mapping (.rdl for reports, .rds for DataSources).

function Export-SsrsItems {
    param(
        [string]$RootPath,
        $Proxy,
        [string]$TypeName,
        [string]$ExportRoot
    )

    $items = Get-AllItemsByType -CurrentPath $RootPath -Proxy $Proxy -TypeName $TypeName

    foreach ($item in $items) {
        $relativeItemPath = $item.Path.TrimStart('/').Replace("/", "\")
        $localFilePath    = Join-Path $ExportRoot $relativeItemPath
        $localDirectory   = Split-Path -Path $localFilePath -Parent

        if (-not (Test-Path $localDirectory)) {
            New-Item -ItemType Directory -Path $localDirectory -Force | Out-Null
        }

        Out-RsCatalogItem -Path $item.Path -Destination $localDirectory -Proxy $Proxy
    }
}

By doing this, your H:\Migration_Dump becomes the exact mirror of your SSRS portal. This structural rigor is what will allow us, in the next step, to remap our data sources without having to hunt down which report belongs to which department.

Finally, we define the folders we wish to export along with the document types they contain (since a migration is often the perfect time for a bit of spring cleaning):

$exportTasks = @(
    @{ Path = "/Migration_Source_2"; Types = @("Report") },
    @{ Path = "/Data Sources";  Types = @("DataSource") }
)

Write-Host "--- Selective Export Started ---" -ForegroundColor Cyan

foreach ($task in $exportTasks) {
    foreach ($typeName in $task.Types) {
        $ext = $extensionMap[$typeName]
        Export-SsrsItems `
            -RootPath   $task.Path `
            -Proxy      $proxySource `
            -TypeName   $typeName `
            -Extension  $ext `
            -ExportRoot $exportRoot
    }
}

Phase 2: Data Source Patching – Mass XML Transformation

Once the extraction is complete, you have a local mirror of your source instance, but the data sources still point to the legacy infrastructure.

Instead of manually fixing each connection after the import (the best way to miss half of them), we will apply an automated transformation directly to our local XML files. This allows us to update connection strings in bulk before a single report even hits the target server.

The idea is simple: use PowerShell to inject the new SQL instance wherever necessary, ensuring a functional deployment from the very first second:

$allDataSources = Get-ChildItem -Path $exportRoot -Filter "*.rds" -Recurse

Write-Host "[>] Datasources updated in : $exportRoot" -ForegroundColor Yellow

foreach ($dsFile in $allDataSources) {
    [xml]$xmlContent = Get-Content $dsFile.FullName
 
    $node = $xmlContent.SelectSingleNode("//ConnectString")
    
    if ($null -ne $node) {
        $oldValue = $node."#text" 
        if ($null -eq $oldValue) { $oldValue = $node.InnerText }

        $newValue = $oldValue -replace "OLD_REPORTING_INSTANCE", "NEW_REPORTING_INSTANCE"
        
        if ($oldValue -ne $newValue) {
            $node.InnerText = $newValue
            $xmlContent.Save($dsFile.FullName)
            Write-Host "  [v] ConnectString updated in : $($dsFile.Name)" -ForegroundColor Green
        }
    } else {
        Write-Host "  [!] ConnectString not found in file $($dsFile.Name)" -ForegroundColor Red
    }
}

Moreover, since we are interacting directly with the file’s XML structure, this logic isn’t limited to connection strings: you can apply the same principle to automate changes for any XML property, from timeouts to provider names.

Phase 3: Mass Deployment – Rebuilding the Reporting Portal

At this stage, the operation is purely mechanical. We once again leverage the ReportingServicesTools module to recreate the folder structure and upload the .rds and .rdl files. By following this specific order, PBIRS will automatically restore the links between your reports and their newly patched data sources.

It is worth noting that the script allows for importing into a specific root folder (defined by the $destroot variable). This is particularly useful if you want to isolate the migrated assets into a dedicated directory, such as SSRS_Folder to keep them distinct from the existing hierarchy. Furthermore, this script is designed with safety in mind: it cannot overwrite or delete anything. If a report with the same name already exists in the same location, the -Overwrite:$false argument prevents replacement, ensuring that the import process never destroys existing content.

Here is the final block to complete your migration:

$destUrl   = "http://your-pbirs-server/ReportServer" 
$localDump = "H:\Migration_Dump"
$destRoot  = "/" #Start import in the root folder
$proxyDest = New-RsWebServiceProxy -ReportServerUri $destUrl

$extensionMap = @{
    "Report"     = ".rdl"
    "DataSource" = ".rds"
}

function Ensure-RsFolderBruteForce {
    param($fullFolderPath, $Proxy)
    $parts = $fullFolderPath.Split('/') | Where-Object { $_ -ne '' }
    $currentPath = ''
    
    foreach ($part in $parts) {
        $parent = if ($currentPath -eq '') { "/" } else { $currentPath }
        $target = if ($currentPath -eq '') { "/$part" } else { "$currentPath/$part" }
        
        try {
            $Proxy.CreateFolder($part, $parent, $null) | Out-Null
            Write-Host "  [DIR] Created : $target" -ForegroundColor Cyan
        } catch {
            if ($_.Exception.Message -match "AlreadyExists") {
                # Folder already exists but we continue
            } else {
                Write-Host "  [!] Error for folder $target : $($_.Exception.Message)" -ForegroundColor Red
            }
        }
        $currentPath = $target
    }
}

function Import-SsrsItem {
    param(
        [System.IO.FileInfo]$File,
        [string]$LocalDump,
        [string]$DestRoot,
        $Proxy
    )

    $relativeDir       = $File.DirectoryName.Replace($LocalDump, '').Replace("\", "/")
    $targetFolderPath  = ($DestRoot + $relativeDir).Replace("//", "/")
    $fullItemPath      = ($targetFolderPath + "/" + $File.BaseName).Replace("//", "/")

    Ensure-RsFolderBruteForce -fullFolderPath $targetFolderPath -Proxy $Proxy

    try {
        Write-RsCatalogItem -Path $File.FullName -Destination $targetFolderPath -Proxy $Proxy -Overwrite:$false
        Write-Host "  [DONE] Imported: $fullItemPath" -ForegroundColor Green
    }
    catch {
        if ($_.Exception.Message -match "already exists") {
            Write-Host "  [SKIP] Already created : $fullItemPath" -ForegroundColor Gray
        } else {
            Write-Host "  [FAIL] Error $fullItemPath : $($_.Exception.Message)" -ForegroundColor Red
        }
    }
}

$importOrder = @("DataSource", "Report")

foreach ($typeName in $importOrder) {
    $extension = $extensionMap[$typeName]
    Write-Host "`n[PASS] Import of object with type : $typeName ($extension)" -ForegroundColor Magenta
    
    $filesToImport = Get-ChildItem -Path $localDump -Filter "*$extension" -Recurse

    if ($filesToImport.Count -eq 0) {
        Write-Host "  [i] No file with $extension found." -ForegroundColor Gray
        continue
    }

    foreach ($file in $filesToImport) {
        Import-SsrsItem -File $file -LocalDump $localDump -DestRoot $destRoot -Proxy $proxyDest
    }
}

Write-Host "`nImport done!" -ForegroundColor Green

Importing via SOAP is more resource-intensive than extraction, as the server must validate every piece of metadata and physically recreate the path for each report. On large volumes, this stage can become a bottleneck (averaging ~1 second per report).

To overcome this, we can parallelize the import by folder, creating multiple background jobs running on separate threads. Here is the general skeleton to implement this multi-threaded approach:

$maxJobs = 5 

foreach ($file in $filesToImport) {
    while ((Get-Job -State Running).Count -ge $maxJobs) {
        Start-Sleep -Milliseconds 500
    }

    Start-Job -Name "Import_$($file.Name)" -ScriptBlock {
        param($f, $url, $targetPath)

        $Proxy = New-RsWebServiceProxy -ReportServerUri $url
        
        try {
            Write-RsCatalogItem -Path $f.FullName -Destination $targetPath -Proxy $Proxy -Overwrite:$false
            return "SUCCESS: $($f.Name)"
        } catch {
            return "ERROR: $($f.Name) -> $($_.Exception.Message)"
        }
    } -ArgumentList $file, $destUrl, $targetFolderPath
}

Note : The -Parallel parameter is a feature of the ForEach-Object cmdlet introduced in PowerShell 7 to enable native multi-threading. While it allows for processing multiple objects simultaneously, it is not reliably supported by the ReportingServicesTools library as the underlying API is not thread-safe. To ensure stability and avoid session collisions, it is recommended to use the Start-Job method instead, as it provides better process isolation for each task.

Key Takeaways for a Seamless Cutover

Migrating to Power BI Report Server shouldn’t be a manual challenge. By adopting this PowerShell-driven ETL approach, you replace the uncertainty of manual intervention with industrial-grade rigor.

The primary advantage lies in consistency: regardless of the report volume or folder complexity, the script guarantees an identical and predictable result every single time. By isolating extraction, XML transformation, and ordered importation, you maintain total control over your data integrity.

Ultimately, automation is about securing your delivery and freeing up time for what truly matters: leveraging your data on your brand-new PBIRS 2025 platform.

Happy migrating!

L’article Scaling SSRS Migrations: Multi-Threaded Automation for PBIRS 2025 est apparu en premier sur dbi Blog.

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.

To ensure persistence across restarts, trace flags need to be set as startup parameters. Traditionally, this can be done manually through two main avenues: using the SQL Server Configuration Manager or editing the Windows Registry directly. However, both of these approaches require manual interaction and are not ideal for automated deployments, large-scale environments or automated deployments.

Unfortunately, SQL Server doesn’t provide a built-in command-line tool or T-SQL syntax to set trace flags as startup parameters programmatically. This gap leaves many DBAs and system engineers either scripting complex registry edits themselves or relying on manual configurations.

That’s exactly the problem I set out to solve. I developed a PowerShell function that allows you to set SQL Server trace flags as startup parameters in a programmatical way and I’m using this function already at one of my customers to set Trace flags within an automated deployment process. This function not only configures the registry settings required for each SQL Server instance on a server, but it also offers optional functionality to restart the SQL Server service—ensuring that your changes take effect immediately. Even better, it includes logic to detect which trace flags are already in place and avoids redundant updates.

In this blog post, I’ll walk you through how the function works, how to use it in your own environment, and how it can fit into your broader infrastructure automation strategy. Whether you manage a single SQL Server or dozens across a large environment, this solution aims to simplify your workflow and reduce the risk of human error.

Let’s take a look at how to set the Trace flag programmatically with the PowerShell Function:

I have the function stored in a ps1 file within my visual studio project directory.

To execute the function and pass the appropriate input parameters to the function, I create a second .ps1 file in the same directory.

In this file I add the following values in variables:

$Trace flags – The trace flags I would like to set for the particular instances

$Restart – This defines if the SQL-Server Service should be restarted after setting the trace flags (Y = restart, N = no restart)

$ServerName – This defines the Server on which the trace flags should be set as a startup parameter for every instance running on it

$Cred –This is the credential which is used to access the remote Server

Then I import the function as a module and execute the function with the values stored in the variables as input parameters.

After saving the file I execute it from the terminal. You can see that the Trace flags have been successfully set.

When we take a look in the registry on the particular server we can see, that the Trace flags have been added.

We can see the same result when taking a look on the startup parameters from the SQL Server Configuration Manager.

Let’s take a look from the SQL Server Management Studio. With the DBCC TRACESTATUS() function. You can see, that no trace flags are currently active.

This is because the trace flags are set as startup parameters and will become active on the next service start.

After restarting the SQL Server service, we can see that the trace flags are now active.

In a running production environment, you can also enable the trace flags using the DBCC TRACEON() command with a global scope (-1) to avoid service interruption. This allows the trace flags to take effect immediately without restarting the SQL Server instance. Since the script also adds them as startup parameters in the registry, the trace flags will persist after the next restart.

DBCC TRACEON (2371, -1);
GO
DBCC TRACEON (3226, -1);
GO

The function is as well “intelligent” enough to see which trace flags are already in place and only sets the trace flags which are missing.

When I execute the function again with the same trace flags, you can see, that the functions tells you that the trace flags are already in place.

The function can also trigger a restart of the SQL-Server service to ensure that the trace flags become active immediately. Let consider therefore, that we want to set additionally the trace flag 1211. I change as well the $Restart variable to ‘Y’ to trigger a service restart.

After saving the file and executing it again from the terminal you can see that the trace flag 1211 has been set and that the instance has been restarted.

As the function triggered a restart of the instance, you can now see from the SQL Server Management Studio that the trace flag has become already active.

I hope this post was interesting for you Let me know your thoughts in the comment section below.

I’ve uploaded the PowerShell function to GitHub. You can access it under this link: https://github.com/HocineMechara/SetSQLServerTrace flags.git

L’article Set SQL Server Trace Flags Automatically and Smoothly 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.

II. Implementation / Configuration of MSA/gMSA

II.2 Create a MSA:

New-ADServiceAccount -Name NAME -Enabled $true -Description “Managed Service Account for xxxx” -DisplayName “MSA 1 – xxxx” -RestrictToSingleComputer

Once the account got created, it will be added in Active Directory under Managed Service Accounts:

II.3 Create a gMSA:

gMSA creation is slightful different as there’s a need to create the Account and grant the defined computer Objects to use it. Fortunately, this can als easily be done with a single PS Query:

New-ADServiceAccount -Name msa_exhib2 -DNSHostName DNS Server -PrincipalsAllowedToRetrieveManagedPassword Server1$, Server2$

Here it is important to add the $ sign at the end of the device name as the query gives the permissions to the Computer Object.

III. Installation and Usage of the MSA / gMSA:

III.1 Installation of the created Account

Once the Account got created it will need to be installed on the target server (Requires the RSAT AD Tools to be installed as mentioned previously):

Install-ADServiceAccount -Identity ServiceName

Be Aware that the MSA is restricted only to one server. Therefore, it can only be installed once. Trying to install it on another server will end with the error:

Once the Account got created it will need to be installed on the target server (Requires the RSAT AD Tools to be installed as mentioned previously):

Install-ADServiceAccount -Identity ServiceName

Be Aware that the MSA is restricted only to one server. Therefore, it can only be installed once. Trying to install it on another server will end with the error:

If the action gets confirmed, the MSA will be removed from it’s original server and the services relying on it will be stopped.

The issue will not exist with gMSA as it can be installed on all Server / Computer which have been granted the access to it.

# Variables used - change as required
$TempLocation = "C:\Service"
$SQLServiceAccount = $ServiceName #Account used for the SQL Service

## This lines are required to change in the cfg file
$ChangeFrom = "SeManageVolumePrivilege = "
$ChangeFrom2 = "SeLockMemoryPrivilege = "
$ChangeFrom3 = "SeBatchLogonRight = "
$ChangeFrom4 = "SeServiceLogonRight = "
$ChangeFrom5 = "SeAuditPrivilege = "

## Build the new lines 
$ChangeTo = "SeManageVolumePrivilege = $SQLServiceAccount,"
$ChangeTo2 = "SeLockMemoryPrivilege = $SQLServiceAccount,"
$ChangeTo3 = "SeBatchLogonRight = $SQLServiceAccount,"
$ChangeTo4 = "SeServiceLogonRight = $SQLServiceAccount,"
$ChangeTo5 = "SeAuditPrivilege = $SQLServiceAccount,"


## Set a name for the Security Policy cfg file.
$fileName = "$TempLocation\SecPolExport.cfg"

## export currect Security Policy config
Write-Host "Exporting Security Policy to file: $filename"
secedit /export /cfg $filename
Copy-Item $filename -Destination "$filename.save_before"
Write-Host "make a copy of initial Security policy export: $filename.save_before"
Write-Host "start to modify Security Policy Export file"

## delete the last 4 lines in the export file; this is needed if some attrubutes are not yet set and they are added at the end of the file; after this end-section (last 4 lines) the secpol is not importing it, so delete these values and add them at the end of the script
$content = get-content $filename
$content[0..($content.length-4)] | out-file $filename


# Use Get-Content to change the text in the cfg file and then save it

# As the line for the option only exists if there is something already in the group
# this will check for it and add your $SQLServiceAccount or use Add-Contect to append option and your $SQLServiceAccount

#Option SeManageVolumePrivilege (Perform maintenance volumne tasks)
IF ((Get-Content $fileName) | where { $_.Contains("SeManageVolumePrivilege") })
{
Write-Host "Appending line containing SeManageVolumePrivilege with $SQLServiceAccount"
(Get-Content $fileName) -replace $ChangeFrom, $ChangeTo | Set-Content $fileName
}
else
{
Write-Host "Adding new line containing SeManageVolumePrivilege"
Add-Content $filename "`nSeManageVolumePrivilege = $SQLServiceAccount"
}

## Option SeLockMemoryPrivilege (Lock Pages in Memory)
## This is optinal depending on the requirements
## IF ((Get-Content $fileName) | where { $_.Contains("SeLockMemoryPrivilege") })
## {
## Write-Host "Appending line containing SeLockMemoryPrivilege with $SQLServiceAccount"
## (Get-Content $fileName) -replace $ChangeFrom2, $ChangeTo2 | Set-Content $fileName
## }
## else
## {
## Write-Host "Adding new line containing SeLockMemoryPrivilege"
## Add-Content $filename "`nSeLockMemoryPrivilege = $SQLServiceAccount"
## }

#Option SeBatchLogonRight (Log on as Batch job)
IF ((Get-Content $fileName) | where { $_.Contains("SeBatchLogonRight") })
{
Write-Host "Appending line containing SeBatchLogonRight with $SQLServiceAccount"
(Get-Content $fileName) -replace $ChangeFrom3, $ChangeTo3 | Set-Content $fileName
}
else
{
Write-Host "Adding new line containing SeBatchLogonRight"
Add-Content $filename "`nSeBatchLogonRight = $SQLServiceAccount"
}


#Option SeServiceLogonRight (log on as a service)
IF ((Get-Content $fileName) | where { $_.Contains("SeServiceLogonRight") })
{
Write-Host "Appending line containing SeServiceLogonRight with $SQLServiceAccount"
(Get-Content $fileName) -replace $ChangeFrom4, $ChangeTo4 | Set-Content $fileName
}
else
{
Write-Host "Adding new line containing SeServiceLogonRight"
Add-Content $filename "`nSeServiceLogonRight = $SQLServiceAccount"
}

Update-DbaServiceAccount -ServiceName 'MSSQLSERVER','SQLSERVERAGENT' -UserName 'Domain\MSAName$'

## Install DbaTools (Requires the Server to have an Internet Connection

Write-Host "Now let's install DBATools"
Install-Module DBATools -Scope AllUsers
read-host "If no error occured, press any key to continue"
## Create Service Folder

Write-Host "Creation of the Service Folder"
if (Test-Path "C:\Service") {
    # Folder exists - Do something here
    Write-host "Folder Exists!" -f Green
}
else {
    # Folder does not exist - Do something else here
    New-Item -ItemType Directory -Path C:\Service
}

## Install AD Powershell Tools

Write-Host "First we install the AD Powershell Tools"
Install-WindowsFeature RSAT-AD-PowerShell
read-host "RSAT Tools installed - press enter to continue"

## Define Variables

$ServerName = hostname
$ServiceName = 'sv'+ $ServerName ## Here you can define your own naming convention for the MSA
#Create MSA for SQL Server

Write-Host "Creation of the Managed Service Account for this Server"
if (!(Get-ADServiceAccount -Filter "Name -like '$ServiceName'")) {
New-ADServiceAccount -Name $ServiceName -Enabled $true -Description "Managed Service Account for SQL Server $ServerName" -DisplayName "MSA - $ServerName" -RestrictToSingleComputer
Write-Host "Service Account has been created"
}
else {
Write-host "Service Account already exists"
}

read-host "Service Account created - please press enter to continue"

#Install MSA on Local Server

Write-Host "Installation of the MSA on this Server"
Install-ADServiceAccount -Identity $ServiceName
read-host "Service Account installed - Press Enter to continue"

## Adding sql service account to local policy
write-host "Local Security Policies will be applied according to the default SQL settings"
#read-host "this is only for debug purporsed - please press enter to proceed"

# Variables used - change as required
$TempLocation = "C:\Service"

## This lines are required to change in the cfg file
$ChangeFrom = "SeManageVolumePrivilege = "
$ChangeFrom2 = "SeLockMemoryPrivilege = "
$ChangeFrom3 = "SeBatchLogonRight = "
$ChangeFrom4 = "SeServiceLogonRight = "
$ChangeFrom5 = "SeAuditPrivilege = "

## Build the new lines 
$ChangeTo = "SeManageVolumePrivilege = $ServiceName,"
$ChangeTo2 = "SeLockMemoryPrivilege = $ServiceName,"
$ChangeTo3 = "SeBatchLogonRight = $ServiceName,"
$ChangeTo4 = "SeServiceLogonRight = $ServiceName,"
$ChangeTo5 = "SeAuditPrivilege = $ServiceName,"


## Set a name for the Security Policy cfg file.
$fileName = "$TempLocation\SecPolExport.cfg"

## export currect Security Policy config
Write-Host "Exporting Security Policy to file: $filename"
secedit /export /cfg $filename
Copy-Item $filename -Destination "$filename.save_before"
Write-Host "make a copy of initial Security policy export: $filename.save_before"
Write-Host "start to modify Security Policy Export file"

## delete the last 4 lines in the export file; this is needed if some attrubutes are not yet set and they are added at the end of the file; after this end-section (last 4 lines) the secpol is not importing it, so delete these values and add them at the end of the script
$content = get-content $filename
$content[0..($content.length-4)] | out-file $filename


# Use Get-Content to change the text in the cfg file and then save it

# As the line for the option only exists if there is something already in the group
# this will check for it and add your $ServiceName or use Add-Contect to append option and your $ServiceName

#Option SeManageVolumePrivilege (Perform maintenance volumne tasks)
IF ((Get-Content $fileName) | where { $_.Contains("SeManageVolumePrivilege") })
{
Write-Host "Appending line containing SeManageVolumePrivilege with $ServiceName"
(Get-Content $fileName) -replace $ChangeFrom, $ChangeTo | Set-Content $fileName
}
else
{
Write-Host "Adding new line containing SeManageVolumePrivilege"
Add-Content $filename "`nSeManageVolumePrivilege = $ServiceName"
}

## Option SeLockMemoryPrivilege (Lock Pages in Memory)
## This is optinal depending on the requirements
## IF ((Get-Content $fileName) | where { $_.Contains("SeLockMemoryPrivilege") })
## {
## Write-Host "Appending line containing SeLockMemoryPrivilege with $ServiceName"
## (Get-Content $fileName) -replace $ChangeFrom2, $ChangeTo2 | Set-Content $fileName
## }
## else
## {
## Write-Host "Adding new line containing SeLockMemoryPrivilege"
## Add-Content $filename "`nSeLockMemoryPrivilege = $ServiceName"
## }

#Option SeBatchLogonRight (Log on as Batch job)
IF ((Get-Content $fileName) | where { $_.Contains("SeBatchLogonRight") })
{
Write-Host "Appending line containing SeBatchLogonRight with $ServiceName"
(Get-Content $fileName) -replace $ChangeFrom3, $ChangeTo3 | Set-Content $fileName
}
else
{
Write-Host "Adding new line containing SeBatchLogonRight"
Add-Content $filename "`nSeBatchLogonRight = $ServiceName"
}


#Option SeServiceLogonRight (log on as a service)
IF ((Get-Content $fileName) | where { $_.Contains("SeServiceLogonRight") })
{
Write-Host "Appending line containing SeServiceLogonRight with $ServiceName"
(Get-Content $fileName) -replace $ChangeFrom4, $ChangeTo4 | Set-Content $fileName
}
else
{
Write-Host "Adding new line containing SeServiceLogonRight"
Add-Content $filename "`nSeServiceLogonRight = $ServiceName"
}


#Option SeAuditPrivilege (Generate security audits)
## Optional: Only required if a Log Management Server is configured and you want to generate Audit Files 
## IF ((Get-Content $fileName) | where { $_.Contains("SeAuditPrivilege") })
## {
## Write-Host "Appending line containing SeAuditPrivilege with $ServiceName"
## (Get-Content $fileName) -replace $ChangeFrom5, $ChangeTo5 | Set-Content $fileName
## }
## else
## {
## Write-Host "Adding new line containing SeAuditPrivilege"
## Add-Content $filename "`nSeAuditPrivilege = $ServiceName"
## }


# Import new Security Policy cfg (using '1> $null' to keep the output quiet)
Write-Host "Importing Security Policy..."
secedit /configure /db secedit.sdb /cfg $fileName 1> $null
Write-Host "done: local security policies changed according to SQL Standards"

## Set the SQL Services to run with the new Managed Service account
Update-DbaServiceAccount -ServiceName 'MSSQLSERVER','SQLSERVERAGENT' -UserName $ServiceName

L’article Make SQL Server services more secure with Managed Service Accounts est apparu en premier sur dbi Blog.

In this blog, I will again use dbatools module in my PowerShell script. For automation in SQL Server, this is now a must-have language.

In the following script, it needs to be run on the Primary server because I am using local paths to move database files.
For a remote approach, you can either use PowerShell remote sessions or remote paths to achieve this goal.

The script will also remove the database from AG during the detach/attach operation, and will add back the database in the AG with the synchronization.

# IMPORTANT: this script has to be run on the Primary only
# dbatools module is required

$Primary = '<MyPrimary>';
$Secondary = '<MySecondary>';

$Database = '<MyDatabase>';
$AvailabilityGroup = '<MyAG>';

$NewDataFolder = '<MyNewDataFolder>';
$NewLogsFolder = '<MyNewLogFolder>';


Try
{
	Import-Module -Name dbatools;
	
	$dbFiles = Get-DbaDbFile -SqlInstance $Primary -Database $Database;
	$dbFiles | Format-Table ComputerName, InstanceName, Database, PhysicalName, LogicalName, TypeDescription, Size;
	
	$title   = 'Moving database to another folder (Offline)'
	$msg     = "Do you want to Move data file(s) to $NewDataFolder and logs file to $NewLogsFolder ?"
	$options = '&Yes', '&No'
	$default = 1  # 0=Yes, 1=No

	$Continue = $False;
	
	do {
		$response = $Host.UI.PromptForChoice($title, $msg, $options, $default)
		if ($response -eq 0) {
			$Continue = $True;
			$response = 1;
		}
	} until ($response -eq 1)
	
	If (-not $Continue){
		Write-Warning -Message "Aborted by user...";
		Return;
	}
	
	# Test path New data folder
	Write-Output -Message "Testing New Data folder $NewDataFolder";
	If (-not (Test-Path -Path $NewDataFolder)){
		Write-Warning -Message "Target data folder $NewDataFolder does not exist. Aborting...";
		Return;
	};
    Write-Output '...ok';
	
	# Test path New logs folder
	Write-Output -Message "Testing New Logs folder $NewLogsFolder";
	If (-not (Test-Path -Path $NewLogsFolder)){
		Write-Warning -Message "Target logs folder $NewLogsFolder does not exist. Aborting...";
		Return;
	};
    Write-Output '...ok';
	
	# Check if AG is configured
	If ($AvailabilityGroup){
		# Remove database from AG
		Write-Output "Start removing database $Database from AG $AvailabilityGroup on instance $Primary";
		Remove-DbaAgDatabase -SqlInstance $Primary -Database $Database -AvailabilityGroup $AvailabilityGroup -EnableException;
        Write-Output '...ok';
	}

	# Detach database on Primary
	Write-Output "Detaching database $Database on instance $Primary";
	Dismount-DbaDatabase -SqlInstance $Primary -Database $Database -EnableException;
    Write-Output '...ok';

	
	# Move data files
	Write-Output "Moving data file(s) of $Database on instance $Primary";
	($dbFiles | Where-Object Type -eq 0).PhysicalName | ForEach-Object -Process {Move-Item -Path $_ -Destination $NewDataFolder;}
    Write-Output '...ok';
	
	# Move logs files
    Write-Output "Moving logs file of database $Database on instance $Primary";
	($dbFiles | Where-Object Type -eq 1).PhysicalName | ForEach-Object -Process {Move-Item -Path $_ -Destination $NewLogsFolder;}
    Write-Output '...ok';
	
	# Create new file structure for database to attach
	$newdbFiles = @(Get-ChildItem $NewDataFolder) + @(Get-ChildItem $NewLogsFolder);
	$fs = New-Object System.Collections.Specialized.StringCollection; 
	@($newdbFiles) | ForEach-Object -Process { `
		$Null = $fs.Add($_.FullName); `	
	}; 
	
	# Attach database on Primary
    Write-Output "Attaching database $database on instance $Primary"
	Mount-DbaDatabase -SqlInstance $Primary -Database $Database -FileStructure $fs;
    Write-Output "...ok";
	

	# Add database to AG
	If ($Secondary -and $AvailabilityGroup){
		
        Write-Output "Removing database $database on secondary $Secondary"; 
		Remove-dbaDatabase -SqlInstance $Secondary -Database $Database;
        Write-Output "...ok";
		
        Write-Output "Start adding database $Database from AG $AvailabilityGroup on instance $Primary to secondary $Secondary";
		Add-DbaAgDatabase -SqlInstance $Primary -Database $Database -AvailabilityGroup $AvailabilityGroup -Secondary $Secondary -SeedingMode Automatic;
        Write-Output "...ok";
	}

}
Catch
{
	Write-Error $_.Exception.toString();
}

Running this script on a production environment, I have seen a few seconds of downtime in the worst case with <500GB databases.
But this will depend mainly on your infrastructure and whether the database files are transferred to another physical drive. Another thing to consider is the database cache will be reset with this approach.

Enjoy automation!

L’article Move SQL Server database files to different folders with PowerShell est apparu en premier sur dbi Blog.

If you have a lot of databases to process, you may want to automate this operation: PowerShell is quite convenient for that.
In this blog, I will present you how I did using dbatools module.

In the following script, I took the primary as reference for my restore: this is just as an example.
Of course, you can customize the target folders based on your needs.

# IMPORTANT: dbatools needs to be installed on the server where running this script

# Configure the following parameters
$Primary = '<MyPrimary>';
$Secondary = '<MySecondary>';
$Database = '<MyDatabase>';
$AvailabilityGroup = '<MyAG>';

$SharedBackup = '<MyShare>';


Try
{
    Write-Output "Importing module dbatools";
    Import-Module -Name dbatools;
    Write-Output '...ok';
    
    $DatabaseFilesQuery =  "
    SELECT SERVERPROPERTY('ServerName') as Server_Instance,
    '$($Database)' as Database_Name,
    name as Logical_Name,
    physical_name as Physical_Name, 
    type_desc as Type_Description,
    size/128 as Size_MB
    FROM sys.master_files 
    WHERE database_id = DB_ID('$($Database)')";

    Write-Output "Retrieving information about current database files";
    $dbFiles = Invoke-DbaQuery -SqlInstance $Secondary -Database 'master' -Query $DatabaseFilesQuery -EnableException;

    $dbFiles | Format-Table Server_Instance, Database_Name, Physical_Name, Type_Description, Size_MB;
    Write-Output '...ok';

    # Retrieve locations from primary
    Write-Output "Retrieving information about new database folders";
    
    $Files = Get-DbaDbFile -SqlInstance $Primary -Database $Database;

    # Locate all data files based on primary data file
    $NewDataFolder = Split-Path (($Files | Where-Object { ($_.Type -eq 0) -and ($_.ID -eq 1) -and ($_.FileGroupName -eq 'PRIMARY')}).PhysicalName);
	
	# Assume there is only one log file
    $NewLogFolder = Split-Path (($Files | Where-Object { ($_.Type -eq 1) -and ($_.ID -eq 2)}).PhysicalName)
    Write-Output '...ok';
    

	$title   = 'Removing secondary database from old folers'
	$msg     = "Do you want to Move database file(s) to  $($NewDataFolder) and to $($NewLogFolder) on Secondary $($Secondary)?"
	$options = '&Yes', '&No'
	$default = 1  # 0=Yes, 1=No

	$Continue = $False;
	
	do {
		$response = $Host.UI.PromptForChoice($title, $msg, $options, $default)
		if ($response -eq 0) {
			$Continue = $True;
			$response = 1;
		}
	} until ($response -eq 1)
	
	If (-not $Continue){
		Write-Warning "Aborted by user...";
		Return;
    }


    # Create subfolder to database
    Write-Output "Creating new database folders";
    $CreateSubFoldersQuery = "
    EXECUTE [master].dbo.xp_create_subdir '$($NewDataFolder)';
    EXECUTE [master].dbo.xp_create_subdir '$($NewLogFolder)';
    "
    $Null = Invoke-DbaQuery -SqlInstance $Secondary -Database 'master' -Query $CreateSubFoldersQuery -EnableException;
    Write-Output '...ok';

    # Remove database from AG on secondary
    Write-Output "Removing database $($Database) from Secondary $($Secondary)";
    $RemoveDBSecondaryQuery = "
    ALTER DATABASE [$($Database)] SET HADR OFF;
    ";
    $Null = Invoke-DbaQuery -SqlInstance $Secondary -Database 'master' -Query $RemoveDBSecondaryQuery -EnableException;
    Write-Output '...ok';

    # Backup Source database - Copy Only option is configurable with this command
    Write-Output "Performing full backup of database $($Database) to Shared Backup $($SharedBackup)";
    $FullBackups = Backup-DbaDatabase -SqlInstance $Primary -Database $Database -Path $SharedBackup -Type Full -FileCount 4;
    Write-Output '...ok';

    Write-Output "Performing log backup of database $($Database) to Shared Backup $($SharedBackup)";
    $LogBackup = Backup-DbaDatabase -SqlInstance $Primary -Database $Database -Path $SharedBackup -Type Log;
    Write-Output '...ok';

    # Restore to secondary with moving files
    Write-Output "Restoring FULL backup for database $($Database) on Secondary $($Secondary)";
    Restore-DbaDatabase -Path $FullBackups -EnableException -SqlInstance $Secondary -WithReplace -NoRecovery -DestinationDataDirectory "$($NewDataFolder)" -DestinationLogDirectory "$($NewLogFolder)";
    Write-Output '...ok';

    Write-Output "Restoring LOG backup for database $($Database) on Secondary $($Secondary)";
    Restore-DbaDatabase -Path $LogBackup -EnableException -SqlInstance $Secondary -NoRecovery -Continue;
    Write-Output '...ok';

    # Add database AG to secondary
    Write-Output "Adding database $($Database) on Secondary $($Secondary)";
    $AddDBSecondaryQuery = "
    ALTER DATABASE [$($Database)] SET HADR AVAILABILITY GROUP = $($AvailabilityGroup);
    ";
    $Null = Invoke-DbaQuery -SqlInstance $Secondary -Database 'master' -Query $AddDBSecondaryQuery -EnableException;
    Write-Output '...ok';

    # Clean up backup files
    Write-Output "Cleaning full backup files";
    Remove-Item -Path $FullBackups.FullName;
    Write-Output '...ok';

}
Catch
{
	Write-Error $_.Exception.toString();
}

The script includes a TRY/CATCH block to stop at any unattended error: it offers a safe way to avoid any side effects.

Enjoy automation!

L’article Move secondary database files in SQL Server AG with PowerShell est apparu en premier sur dbi Blog.

This module is running with at least PowerShell 7.0.6 LTS (Long Term Support) or PowerShell 7.1.3, but higher versions are recommended.

When PowerShell from 1.0 to 5.1 are component of Windows operating systems, PowerShell 7 is cross-platform and is at top of .NET Core.
As a result, PowerShell Core has to be deployed on the environment to use this module.

If you try to use AZ module on Windows PowerShell, you will encounter the following error:

Indeed, I have not the recommended versions specified in the documentation:

For my example, I needed to install PowerShell core. To do so, I did an installation with an msi installer with PowerShell TLS release.
This kind of release only contains security fixes and servicing fixes to minimize the impact on Prod environments. They are of course included in Microsoft Lifecycle Policy.

NOTE: PowerShell 7.0 is no more supported, and only at least PowerShell 7.1 is now available.

After the my previous installation, here is the version I get:

This new module allows you to download only the necessary packages you need, which avoids having too much resources loaded in your PowerShell Console.

Keep in mind that executing Install-Module -Name AZ will install ALL packages:

In most cases, you will prefer only installing packages relative to Azure resources you want to manage.

In addition, using Import-Module -Name AZ will load all packages.
Here is an extract of the PowerShell Module Script associated to AZ module:

If you still have scripts running with AzureRM module, you should update them before 29 February 2024.

L’article Installing Azure AZ Module on Windows 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.