We’ve recently begun attempting to scale our Azure App Services up and down for our test environments; scaling them up to match production performance levels (SKU: PremiumV2) during the day and then back down to minimal (SKU: Basic) at the end of the working day to save on costs. Just in the last month or two however, we’ve started to get the error “Cannot use the SKU Basic with File Change Audit for site XXX-XXX-XXX-XXX”.
Initially, we thought it had to do with the fact that we had a Diagnostic setting that was tracking
AppServiceFileAuditLogs, but even after removing that Diagnostic setting before attempting the scale down, the issue persisted.
After banging our head against the walls with no progress being made, we opened a low-severity ticket with Azure Support to understand what was going on. They suggested we remove the following App Configuration settings:
Again, these did not have any effect.
It was at this time that I was in the portal browsing around for something else and happened to notice the “JSON View” option at the top right of the App Service so I checked it out and grep’d for
audit just to see what I’d find.
Not so bingo:
But seeing that setting got me to thinking. What if there’s a bug in what JSON View is showing. The error we’re receiving is clearly saying it’s enabled, but the website is showing
null; what if there’s some kind of type-mismatch going on behind the portal that is showing null but actually has a setting? What if we could use a different mechanism to test that theory?
Well, it just so happens that Azure PowerShell has a
Get-AzResource function that can do just that and this blog post shows us how to do that.
First, let’s get the resource:
$appServiceRG = "example-resource-group" $appServiceName = "example-app-service-name" $config = Get-AzResource -ResourceGroupName $appServiceRG ` -ResourceType "Microsoft.Web/sites/config" ` -ResourceName "$($appServiceName)/web" ` -apiVersion 2016-08-01
We now have an object in
$config that we can now check the properties of by doing:
And there it is:
fileChangeAuditEnabled : True
Now all we need to do is configure it to
false (and also unset a property called
ReservedInstanceCount which is a duplicate of
preWarmedInstanceCount but cannot be included when we try and reset the other setting due to what I assume is Azure just keeping it around for legacy reasons):
$config.Properties.fileChangeAuditEnabled = "false" $config.Properties.PSObject.Properties.Remove('ReservedInstanceCount')
And finally, let’s set the setting:
$config | Set-AzResource -Force
Now, when you try to scale down from a PremiumV2 SKU to a Basic SKU, you will no longer receive the error of “Cannot use the SKU Basic with File Change Audit for site XXX-XXX-XXX-XXX”.