In this article, we will see how to compare Azure SQL database schema using sqlpackage.exe and generate a delta script that shows the differences in a controlled and repeatable way. The approach and flow are similar to the DACPAC-based comparison strategy discussed earlier on AzureOps.

Why use sqlpackage for database comparison?

sqlpackage.exe is a command-line utility provided by Microsoft that works with DACPAC and BACPAC files. Using sqlpackage, you can:

• Compare two databases using DACPACs
• Generate a deployment (delta) script
• Control destructive changes explicitly
• Automate comparisons in CI/CD pipelines

For Azure SQL Database scenarios, this method is especially useful when direct schema comparison tools are not available or when automation is required.

Creating a DACPAC

To compare database schemas using sqlpackage, you first need a DACPAC file, which represents the database schema.

You can create a DACPAC using sqlpackage.exe, SSMS, or Visual Studio. For a quick, step-by-step guide covering all methods, refer to this article.

Installing sqlpackage Before You Begin

Before you can compare two Azure SQL database schemas using sqlpackage, you need to install the sqlpackage command-line utility on your machine. sqlpackage.exe is the same tool that Powers the DACPAC deployments discussed in this site’s previous article on deploying DACPACs to Azure SQL Database.

Here are the recommended ways to install sqlpackage, depending on your environment:

Option 1 — Install as a .NET Global Tool (Cross-Platform)

The easiest and most modern way to install sqlpackage on Windows, macOS, or Linux is using the .NET SDK tool installer. This gives you the sqlpackage command directly on your PATH. Run below command in command prompt.

dotnet tool install --global Microsoft.SqlPackage

If you already have it installed and want to update to the latest version, run:

dotnet tool update --global Microsoft.SqlPackage

This method works well for local development and automation scripts, including PowerShell and CI/CD pipelines.

Option 2 — Download Standalone Zip (Windows / macOS / Linux)

If you don’t use the .NET SDK or prefer a self-contained download, Microsoft also publishes standalone builds of sqlpackage:

1. Visit the official SqlPackage download page on Microsoft Docs.
2. Download the appropriate zip for your OS.
3. Extract and place the folder somewhere on your system (e.g., C:\tools\sqlpackage).
4. Add the folder containing sqlpackage.exe to your system PATH so you can call it from any terminal.

This method is useful if you want to avoid installing .NET tools or need to bundle sqlpackage with deployment scripts.

High-level approach

The comparison process consists of three simple steps:

1. Export both Azure SQL databases to DACPAC files
2. Use sqlpackage.exe with /Action:Script
3. Review the generated delta script before applying it

In this article, we focus on step 2, assuming you already have DACPAC files for both databases.

Sample scenario

Let us assume the following setup:

• Source (baseline) database: sales-test-db
• Target (to be aligned) database: sales-prod-db

Our goal is to compare Azure SQL Database schema and generate a SQL script that shows what changes are required to make Production match Test.

Sample sqlpackage command

Below is a sample sqlpackage.exe command to compare two DACPAC files and generate a delta script.

sqlpackage.exe ^
  /Action:Script ^
  /SourceFile:"C:\Dacpacs\sales-test-db.dacpac" ^
  /TargetFile:"C:\Dacpacs\sales-prod-db.dacpac" ^
  /TargetDatabaseName:"sales-prod-db" ^
  /OutputPath:"C:\Dacpacs\sales_test_vs_prod_delta.sql" ^
  /p:DropObjectsNotInSource=True

In case you want to use PowerShell ISE, you can use below script.

# Path to sqlpackage.exe
$sqlPackagePath = "C:\Program Files\Microsoft SQL Server\160\DAC\bin\sqlpackage.exe"

# DACPAC paths
$SourceDacpacPath = "C:\Dacpacs\sales-test-db.dacpac"
$TargetDacpacPath = "C:\Dacpacs\sales-prod-db.dacpac"

# Target database name
$TargetDatabaseName = "sales-prod-db"

# Output script path
$OutputScriptPath = "C:\Dacpacs\sales_test_vs_prod_delta.sql"

# Publish options
$DropObjectsNotInSource = "True"

# Execute sqlpackage
& $sqlPackagePath `
    /Action:Script `
    /SourceFile:$SourceDacpacPath `
    /TargetFile:$TargetDacpacPath `
    /TargetDatabaseName:$TargetDatabaseName `
    /OutputPath:$OutputScriptPath `
    /p:DropObjectsNotInSource=$DropObjectsNotInSource

This command does not apply any changes. It only generates a SQL script that you can review and execute manually if needed.

Understanding each parameter

Let us break down all the parameters used in the command.

/Action:Script

Specifies that sqlpackage should generate a deployment script instead of publishing changes directly to a database. This is the safest option when comparing environments like Test and Production.

/SourceFile

Path to the source DACPAC file. This represents the desired state of the database.

/SourceFile:"C:\Dacpacs\sales-test-db.dacpac"

In our example, the Test database schema is treated as the source of truth.

/TargetFile

Path to the target DACPAC file. This represents the database you want to compare against.

/TargetFile:"C:\Dacpacs\sales-prod-db.dacpac"

The generated script will contain changes required to make the target match the source.

/TargetDatabaseName

Logical name of the target database.

/TargetDatabaseName:"sales-prod-db"

This parameter is mandatory for the Script action, even when you are comparing DACPAC-to-DACPAC.

/OutputPath

Specifies where the generated delta script should be written.

/OutputPath:"C:\Dacpacs\sales_test_vs_prod_delta.sql"

Always review this script carefully before executing it in Production.

/p:DropObjectsNotInSource

Controls whether objects that exist in the target but not in the source should be dropped.

/p:DropObjectsNotInSource=True

• True – Generates DROP statements for extra objects in the target
• False – Preserves objects that exist only in the target

⚠️ Use this option with caution, especially for Production databases.

Common additional publish parameters

Depending on your requirements, you may also consider these commonly used parameters:

• /p:BlockOnPossibleDataLoss=False
• /p:IgnorePermissions=True
• /p:IgnoreRoleMembership=True
• /p:ExcludeObjectTypes=Users;Logins
• /p:ExcludeSchemaValidation=True

These options help fine-tune the comparison and avoid unwanted differences.

Best practices

• Always generate a script first (/Action:Script)
• Review the delta script line by line
• Never auto-apply changes to Production without validation
• Store DACPACs and scripts in source control
• Use the same approach in CI/CD pipelines for consistency

Conclusion

Comparing two Azure SQL databases using sqlpackage.exe is a reliable and automation-friendly approach. By working with DACPAC files and generating delta scripts, you gain full visibility and control over schema changes before they reach Production.

This method fits well into modern DevOps workflows and provides a safe alternative to manual or GUI-based comparisons.

If you regularly manage schema changes across multiple environments, sqlpackage should be a core part of your database deployment tool.

Pro tips
1. If you want to generate BACPAC file of an Azure SQL database, you can refer to this post

See more

The post Compare Azure SQL Database Schema Using sqlpackage appeared first on AzureOps.

Pre-requisites:
To implement Azure Data Factory automation using Azure automation account you would need,
1. Azure subscription and a resource group with Azure Data Factory and Azure Automation Account.
2. Admin permission to grant access to Azure automation account on Azure Data Factory.

What is Managed Identity?

Managed identity is a service principal associated with resources in Azure. When we create a Data Factory in Azure, it automatically creates an app in Microsoft Entra ID (Azure active directory).To connect Azure Data Factory from Azure automation account, we need to grant Azure automation account’s system-assigned managed identity access to the Azure Data Factory. This makes access management more secure and easy.

Benefits of using managed identity authentication

1. You don’t need to manage credentials.
2. You can use managed identities to authenticate to any resource that supports Entra ID authentication, including your applications.
3. Managed identities can be used at no extra cost.

Types of managed identities

There are two types of managed identities:
1. System assigned managed identity – This is the identity that is associated with Azure resources like Azure automation account.
2. User-assigned managed identity – This identity is created and managed by the user in Azure portal. Learn more about it here.

Let us now see how the system-assigned managed identity of Azure automation account can be used to connect and manage Azure Data Factory integration runtime.

Enable the System assigned managed identity for Azure automation account

1. Navigate to Azure automation account resource in Azure portal.

2. Click ‘Identity’ under ‘Account Settings’ as shown in the image below.

3. Under the System assigned tab, enable Status and click Save.

Grant access to Azure automation account on Azure Data Factory

1. Navigate to Data Factory resource in Azure portal and Click on Access control (IAM). Click Add -> Add role assignment as shown in the image below.

2. Grant sufficient role to Azure automation account resource on Data Factory resource under the Role tab. Job function role – ‘Data Factory Contributor’ should be sufficient to perform management activities on Data Factory.

3. Under the Members tab, select ‘Managed Identity’. Search for the managed identity of Azure automation account to whom you want to grant access.

Start And Stop Azure Data Factory IR using PowerShell runbook

1. Import Azure Az PowerShell modules in automation account. Under the automation account resource, navigate to ‘Shared resources’ -> ‘Modules’.

2. Create ‘datafactory-name’ and ‘resourcegroup-name’ variables in the automation account and assign appropriate values to them.

3. Navigate to ‘Process Automation’ left side section under Azure automation account and click ‘Runbooks’ . Create a new PowerShell runbook and provide necessary details.

4. You can use the code below to connect and stop/start Integration runtime in Azure Data Factory.

Stop ADF integration runtime

# Retrieve Automation Variables
$DataFactoryName = Get-AzAutomationVariable -Name 'datafactory-name'
$ResourceGroup = Get-AzAutomationVariable -Name 'resourcegroup-name'

# Authenticate to Azure
Connect-AzAccount

# Get Integration Runtime in Azure Data Factory
$IntegrationRuntime = Get-AzDataFactoryV2IntegrationRuntime `
                            -DataFactoryName $DataFactoryName `
                            -ResourceGroupName $ResourceGroup

# Check the current status of the Integration Runtime
$IRStatus = $IntegrationRuntime.Status
Write-Output "Current Integration Runtime Status: $IRStatus"

# Stop the Integration Runtime if it is running
if ($IRStatus -eq 'Online') {
    Stop-AzDataFactoryV2IntegrationRuntime `
        -DataFactoryName $DataFactoryName `
        -ResourceGroupName $ResourceGroup `
        -Name $IntegrationRuntime.Name

    Write-Output "Integration Runtime '$($IntegrationRuntime.Name)' has been stopped."
} else {
    Write-Output "Integration Runtime '$($IntegrationRuntime.Name)' is already stopped or in a state that cannot be stopped."
}

Start ADF integration runtime

# Retrieve Automation Variables
$DataFactoryName = Get-AzAutomationVariable -Name 'datafactory-name'
$ResourceGroup = Get-AzAutomationVariable -Name 'resourcegroup-name'

# Authenticate to Azure
Connect-AzAccount

# Get Integration Runtime in Azure Data Factory
$IntegrationRuntime = Get-AzDataFactoryV2IntegrationRuntime `
                            -DataFactoryName $DataFactoryName `
                            -ResourceGroupName $ResourceGroup

# Check the current status of the Integration Runtime
$IRStatus = $IntegrationRuntime.Status
Write-Output "Current Integration Runtime Status: $IRStatus"

# Start the Integration Runtime if it is not running
if ($IRStatus -ne 'Online') {
    Start-AzDataFactoryV2IntegrationRuntime `
        -DataFactoryName $DataFactoryName `
        -ResourceGroupName $ResourceGroup `
        -Name $IntegrationRuntime.Name

    Write-Output "Integration Runtime '$($IntegrationRuntime.Name)' is starting."
} else {
    Write-Output "Integration Runtime '$($IntegrationRuntime.Name)' is already running."
}

Notice in the above code blocks that we have not used any credentials to authenticate to Azure. This is because authentication is taken care of using managed identity.

Pro tips:
1. Learn how to connect to Azure SQL from Azure Data Factory using managed identity.
2. Azure Automation Run as accounts, including Classic Run as accounts have retired on 30 September 2023. It is now mandatory to use the managed identity.

See more

The post Programmatically Start and Stop Azure Data Factory Integration Runtime appeared first on AzureOps.

Pre-requisites:
1. Access to Data Factory resources in the Azure portal.
2. Az PowerShell module installed on the local machine.

Understanding Azure Data Factory Triggers

Azure Data Factory utilizes triggers to initiate data pipeline executions based on specific conditions automatically. These conditions can be set on a schedule, event, or through manual intervention. Triggers play a crucial role in ensuring that data pipelines run at the correct time, keeping data processing up-to-date and accurate. Turning triggers on-demand on and off gives data engineers the flexibility to control the data flow efficiently.

Script to disable and enable triggers in Azure Data Factory

Use the below PowerShell script to disable all the triggers in Azure Data Factory.

$adf_name = 'adfname'
$resourcegroup_name = 'resourcegroupname'

$triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $adf_name -ResourceGroupName $resourcegroup_name; 
$triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $resourcegroup_name -DataFactoryName $adf_name -Name $_.name -Force }

Use the below PowerShell script to enable all the triggers in Azure Data Factory.

$adf_name = 'adfname'
$resourcegroup_name = 'resourcegroupname'

$triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $adf_name -ResourceGroupName $resourcegroup_name; 
$triggersADF | ForEach-Object { Start-AzDataFactoryV2Trigger -ResourceGroupName $resourcegroup_name -DataFactoryName $adf_name -Name $_.name -Force }

Manage ADF triggers in YAML based Azure DevOps pipeline

Use the script below to enable and disable triggers in adf using a YAML-based]deployment pipeline in Azure DevOps.

          deploy:  #Configure steps under deploy hook.
            steps:
              #task to disable triggers in Azure Data Factory.
              - task: AzurePowerShell@5     
                displayName: Stop Triggers
                inputs:
                  azureSubscription: 'subscriptionname'
                  ScriptType: 'InlineScript'
                  Inline: |
                    $triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName "$(dataFactoryName)" -ResourceGroupName "$(resourceGroup)"; 
                    $triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName "$(resourceGroup)" -DataFactoryName "$(dataFactoryName)" -Name $_.name -Force }
                  azurePowerShellVersion: 'LatestVersion'             
             
              #task to enable triggers in Azure Data Factory.
              - task: AzurePowerShell@5    
                displayName: Start Triggers
                inputs:
                  azureSubscription: 'subscriptionname'
                  ScriptType: 'InlineScript'
                  Inline: |
                    $triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName "$(dataFactoryName)" -ResourceGroupName "$(resourceGroup)";
                    $triggersADF | ForEach-Object { Start-AzDataFactoryV2Trigger -ResourceGroupName "$(resourceGroup)" -DataFactoryName "$(dataFactoryName)" -Name $_.name -Force }
                  azurePowerShellVersion: 'LatestVersion'

Pro tips:
1. It is important to disable triggers before deploying data factory code using Azure DevOps pipelines. Refer to this article if you want to automate Azure data factory deployments using the DevOps pipeline.

See more

The post Disable and Enable triggers in Azure Data Factory using PowerShell appeared first on AzureOps.

Pre-requisites:
1. Azure Az PowerShell module installed and you have the appropriate permissions to access and modify the Azure Key Vault.
2. Azure key vault with appropriate permissions.

Update key vault secrets using PowerShell

Run below PowerShell command in any editor like PowerShell ISE.

$azureTenantId = "tenantid"
$subscriptionId = "subscriptionId"
$keyVaultName = "vaultname"
"'Log in to Azure..."
Connect-AzAccount -Tenant $azureTenantId  -Subscription $subscriptionId
Set-AzContext -TenantId $azureTenantId
$secretAccessKeyID = Set-AzKeyVaultSecret -VaultName $keyVaultName -Name <key name> -SecretValue <secret value> 

Here,

Connect-AzAccount -Tenant $azureTenantId -Subscription $subscriptionId
This cmdlet connects to your Azure account using the specified Azure Tenant ID and Subscription ID. It initiates an authentication process to sign in to Azure.

Set-AzContext -TenantId $azureTenantId
This cmdlet sets the context for the current session to the specified Azure Tenant ID. It ensures that it can perform subsequent operations in the context of the specified Azure tenant.

$secretAccessKeyID = Set-AzKeyVaultSecret -VaultName $keyVaultName -Name <key name> -SecretValue <secret value>
This line updates a secret in the Azure Key Vault specified by $keyVaultName. It uses the Set-AzKeyVaultSecret cmdlet to perform this task. Replace <key name> with the name of the secret you want to update, and <secret value> with the new value for the secret.

Update secret in azure key vault using managed identity

$azureTenantId =  "tenantid"
$keyVaultName = "vaultname"
"'Log in to Azure…"
Connect-AzAccount -Identity
Set-AzContext -TenantId $azureTenantId
$secretAccessKeyID = Set-AzKeyVaultSecret -VaultName $keyVaultName -Name <key name> -SecretValue <secret value> 

Here,

Connect-AzAccount -Identity
To connect to Azure, this command uses the Managed Service Identity (MSI) of the current environment where the script is running. With MSI, you can access Azure resources without the need for explicit credentials in the code. However, it is important to note that this requires the environment to have a system-assigned or user-assigned managed identity with the necessary permissions to access the Azure Key Vault.

Set-AzContext -TenantId $azureTenantId
This cmdlet sets the context for the current session to the specified Azure Tenant ID. It ensures that subsequent operations are performed in the context of the specified Azure tenant. The value for $azureTenantId was retrieved from the Azure Automation variable.

$secretAccessKeyID = Set-AzKeyVaultSecret -VaultName $keyVaultName -Name <key name> -SecretValue <secret value>
This line updates a secret in the Azure Key Vault specified by $keyVaultName. It uses the Set-AzKeyVaultSecret cmdlet to perform this task. Replace <key name> with the name of the secret you want to update, and <secret value> with the new value for the secret.

Pro tips:
1. Be cautious while updating secrets; they are sensitive information and should be handled securely.
2. While we can only change secret attributes such as expiration date, activation date. However, we can add a new version of the existing secret
3. Follow this article if you want to learn how to access key vault secrets in Azure Data Factory.

See more

The post Update Secret in Azure Key Vault using PowerShell appeared first on AzureOps.

What is a Power BI template file?

The PBIT file keeps your report structure and contains ‘DataModelSchema File’ instead of ‘‘DataModel file. This means it doesn’t include any data from your source systems, and the size of this file is very small. However, it has Report pages, visuals,  data model definitions, and query definitions. Read more about it here.

Steps to export measures from Power BI file.

1. Save the Power BI file as Power BI template (.pbit)

1. Open the Power BI (.pbix) file in PowerBI Desktop.

2. Click on the File menu item and click Save. Click ‘Browse this device’ button at the bottom left side.

3. Select the Template (.pbit) file type and give a name to the Power BI template file as shown in the below image.

2. Run below PowerShell script.

Copy the below PowerShell script in PowerShell ISE and provide the path to the folder containing the Power BI template file (.pbit) exported in step 1 to variable $pbitFolderPath. Also, give the name of the template file to the $pbiFileName variable.

#Path containing pbit file
#Parameters
################################################################
$pbitFolderPath = "D:\PowerBI files\"
$pbiFileName = "Sample PBI"
################################################################
$pbitFileName = $pbiFileName  + ".pbit"
$pbitFilePath = $pbitFolderPath + $pbiFileName  + ".pbit"
$zipFileName =  $pbiFileName + ".zip";
$exportMeasuresFilePath = $pbitFolderPath +$pbiFileName + ' Calculations.csv'
$zipFileFullPath = $pbitFolderPath + $zipFileName

#Rename pbit file to zip file.
Rename-Item -Path $pbitFilePath -NewName  $zipFileName

#Temp. export file path
$exportPath = $pbitFolderPath + "export\"

#Unzip zip file
Expand-Archive -Path $zipFileFullPath -DestinationPath $exportPath

#DataModelSchema file full path
$dataModelSchemaFullPath =  $exportPath + "DataModelSchema"
$strFileName = "DataModelSchema.json"

#Rename DataModelSchema file to DataModelSchema.json
Rename-Item -Path $dataModelSchemaFullPath -NewName  $strFileName 

#Get the JSON from DataModelSchema.json
$dataModelSchemaJsonFullPath = $exportPath + $strFileName

$jsonStr = Get-Content $dataModelSchemaJsonFullPath -Encoding unicode | Out-String

#Convert the Json to a dynamic object
$outJson = ConvertFrom-Json $jsonStr 

#Extract the tables to a list
$outTables = $outJson.Model.tables

"Table Name, Calculation Type, Calculation Name, Value" | Out-File $exportMeasuresFilePath  

#Remove hidden system generated date tables.
$outTables = $outTables | Where-Object {$_.isHidden -ne $true}

foreach ($outTable in $outTables) 
# Foreach Table in Power BI desktop
{
if ($outTable.measures -ne $null) 
{
$outMeasures = $outTable.measures
foreach ($outMeasure in $outMeasures) 
{
 $("{0} , {1} , {2}, {3}" -f $outTable.name, "Measure", $outMeasure.name, $outMeasure.expression -join " " | Out-String)  | Out-File $exportMeasuresFilePath  -Append
# Write the measure and expression 
}
 }
  if ($outTable.columns -ne $null) 
  { 
  $outColumns = $outTable.columns
  $outColumns = $outColumns | Where-Object {$_.type -eq "calculated"} 
  # Filter on calculated columns only, but this could be removed for all 
  foreach ($outColumn in $outColumns) 
  { 
   $("{0} , {1} , {2}, {3}" -f $outTable.name, "Calculated column" , $outColumn.name, $outColumn.expression -join " ") | Out-File $exportMeasuresFilePath  -Append
  }
}
}
write-host "Calculations written to "$exportMeasuresFilePath 

Rename-Item -Path  $zipFileFullPath -NewName  $pbitFileName

#Clenaup temp files
Remove-Item $exportPath -Recurse

The output of the above script execution will be stored in ‘<PowerBI filename> calculation.csv’ file in the same folder containing the Power BI template file. The result might not be well-formatted csv as the exported calculations can have ‘,’ in its definitions.

Pro tips:
1. Output of the above PowerShell script also includes calculated column expressions.
2. If you are using DAX Studio, you can also export measures from Power BI using Dax Studio
3. To test row-level security, you can read this post if you want to run the Power BI report as a different user.

See more

The post Export Measures From Power BI Desktop appeared first on AzureOps.