Background
Historically, DevOps Auditing could be configured through the server-level auditing API using the isDevopsAuditEnabled property under:
Microsoft.Sql/servers/auditingSettings
As Azure SQL auditing capabilities evolved, a dedicated resource was introduced specifically for DevOps Auditing:
Microsoft.Sql/servers/devOpsAuditingSettings
This dedicated API is now the supported approach for configuring DevOps Auditing.
The Question
Customers occasionally observe that setting isDevopsAuditEnabled=true continues to work on some servers but not on others.
A recent customer engagement highlighted this scenario where the same deployment was able to enable DevOps Auditing on most servers, while a smaller subset of servers ignored the setting even though the ARM operation completed successfully.
At first glance, this appears inconsistent. However, the behaviour is expected.
How Backward Compatibility Works
Today, Azure SQL maintains backward compatibility for customers who still use the legacy auditing API.
The behaviour is as follows:
- The recommended and supported approach is to use the dedicated DevOps Auditing resource:
Microsoft.Sql/servers/devOpsAuditingSettings
- The isDevopsAuditEnabled property under:
Microsoft.Sql/servers/auditingSettings
is no longer recommended for new implementations.
- To preserve backward compatibility, the legacy property may continue to work for servers that have never been migrated to the new model.
- Once the dedicated DevOps Auditing API is used on a server for the first time, that server is permanently marked as migrated.
- After migration, the legacy isDevopsAuditEnabled property is no longer honoured for that server, even if it is supplied in subsequent requests.
Why Some Servers Behave Differently
Consider an environment with hundreds of Azure SQL servers managed through ARM templates or Azure Policy.
The deployment may successfully update:
{
“type”: “Microsoft.Sql/servers/auditingSettings”,
“properties”: {
“isDevopsAuditEnabled”: true
}
}
For servers that have never used the new DevOps Auditing resource, the setting may still take effect.
For servers that were previously configured through:
Microsoft.Sql/servers/devOpsAuditingSettings
the server is already considered migrated. In these cases, the request can complete successfully, but the legacy property is ignored and DevOps Auditing remains unchanged.
Recommended Action
Customers should migrate all automation, ARM templates, Bicep templates, Terraform deployments, and Azure Policies to use the dedicated DevOps Auditing resource:
Microsoft.Sql/servers/devOpsAuditingSettings
and avoid relying on the legacy isDevopsAuditEnabled property going forward.
Key Takeaway
If isDevopsAuditEnabled appears to work for some servers but not others, it is usually due to the server’s migration state:
- Not yet migrated → legacy flag may still work.
- Already migrated → legacy flag is ignored.
- Use Microsoft.Sql/servers/devOpsAuditingSettings for all future configurations.
This behaviour allows Azure SQL to maintain backward compatibility while providing a clear migration path to the dedicated DevOps Auditing configuration model.