The problem

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:

  • DIAGNOSTICS_AZUREBLOBCONTAINERSASURL
  • DIAGNOSTICS_AZUREBLOBRETENTIONINDAYS
  • DiagnosticServices_EXTENSION_VERSION
  • WEBSITE_HTTPLOGGING_CONTAINER_URL
  • WEBSITE_HTTPLOGGING_RETENTION_DAYS

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.

Bingo: fileChangeAuditEnabled

Not so bingo: fileChangeAuditEnabled: null

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.

The solution

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:

$config.Properties

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')

Next, as per the suggestion from Parameswaran in the comments (thank you!), create a new Array (since existing arrays are of fixed size and cannot be modified) while removing AppServiceFileAuditLogs from the list of azureMonitorLogCategories

$newCategories = @()

ForEach ($entry in $config.Properties.azureMonitorLogCategories) {
    If ($entry -ne "AppServiceFileAuditLogs") {
        $newCategories += $entry
    }
}

$config.Properties.azureMonitorLogCategories = $newCategories

And finally, let’s set the setting:

$config | Set-AzResource -Force

Next, for any Deployment Slots you have on this resource, repeat these steps again, but using the following resource retrieval code:

$config = Get-AzResource -ResourceGroupName $appServiceRG `
    -ResourceType "Microsoft.Web/sites/slots" `
    -ResourceName "$($appServiceName)" `
    -apiVersion 2016-08-01

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”.

16 thoughts on “ Cannot use the SKU Basic with File Change Audit for site ”

  1. Hey!! Thanks for this post. Getting the same error. I tried your solution but for me properties are not getting update when I use $config|Set-AzResource -Force command. The setting gets updated locally but doesn’t get pushed to cloud.

    Reply

    2. Nexxai and Ayushi, if in case the workaround given by Nexxai is not working, check the 2 options 1) Ensure Diagnostic Settings and App service logs are disabled and then run the script given by Nexxai. 2) If that doesnt works still, navigate to https://resources.azure.com -> resourceGroups->YOUR RESOURCE GROUP->Providers->Microsoft.Web->Sites->YOUR WEBAPP->config->web. Find for the JSON value fileChangeAuditEnabled and if it’s true, switch to EDIT mode(ReadWrite should be enabled) and go to the section fileChangeAuditEnabled and make it false. Apply this setting by pressing PUT button, in case if still it doesnt change, look for azureMonitorCategories and remove AppServiceFileAuditLogs. Also make the fileChangeAuditEnabled to false again and PUT this. You will now be able to downsize the App Service to BASIC or Standard. Please note that you can apply this change only if you dont want the FileChangeAudit at all which is an important feature on logging part from Microsoft.

      Reply

      1. Thank you so much for this information! I’ve updated the script on the page to reflect your suggestion.

        Reply

  2. I don’t have words to say thanks to you for the blog. It has helped me like anything. I was not finding any cause, even not got any reply from Microsoft.

    Reply

  3. Another workaround through the Azure Portal is to go into App Service > Monitoring – Diagnostic settings (preview) > service -Edit Setting > Untick “AppServiceFileAuditLogs” and click Save. Repeat for all your app services in the app service plan and then you can scale down your plan (I went from P1V3 to S1).

    Once scaled down you can add that setting back for each App Service (probably a good idea because it could affect logging) and then scale back up again no worries (I went from S1 to P1V3)

    If you try and scale down again, you will come across the same issue and have to repeat the process.

    Big thanks to nexxai for finding this obscure issue!! You can vote on User Voice for the problem https://feedback.azure.com/users/4659259176

    Reply

    1. My problem (and I’m betting a few other people reading this article) was that turning it off in the portal had no effect. Maybe there was a backend bug that’s since been fixed, but yeah, unchecking the box in the portal didn’t do anything. Hopefully they’ve fixed that problem?!

      Reply

    2. Even after clearing that setting on the Diagnostics blade, I still had to manually clean out all the Configuration Settings that had been added to my app, so be sure to check that if you’re still stuck.

      Reply

  4. I just had this same occurrence, and had to work through this with MS support.
    In my case, searching for and removing the above app settings in all the deployment slots of all my apps on that app service, enabled me to then freely scale my app service plan again.

    Frankly the MS Tech who took me from Chat to a Teams call was excellent.

    Reply

    1. Ahh, I hadn’t considered that the App Settings could be different in deployment slots since we don’t use them. I will update the text to point out that those will need to be handled too.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.