Azure Resource Manager templates have been a regularly discussed feature on the blog, perhaps reflecting the experiences and issues I have had working with them over the past year. For example, we’ve seen:

• How to perform pre-deployment validation of your templates, to ensure they are valid and any issues are resolved as part of your continuous integration (CI) process.
• Some of the pitfalls involved when working with application settings and App Service resources, and why you need to factor in the former when authoring your template.
• The steps required to specify Streaming Units for a Stream Analytics Job resource.

Despite hurdles along the way, I am a huge proponent of their usage, and this is a subject area I would strongly encourage anyone working with Azure to study carefully. Indeed, if you have a desire to standardise and automate your development cycles, then Azure Resource Templates will - arguably - be essential towards achieving this.

As another week began, I found myself having an incredible feeling of déjà vu, with another pesky error message to deal with on my desk. This time, the error was relating to an Azure Resource Manager template deployment and, specifically, the following error message, involving an Azure SQL Server instance configured with a failover group:

{
  "id": "/subscriptions/9466fa60-58e2-4d62-bd5c-290b2707ca35/resourceGroups/my-rg/providers/Microsoft.Resources/deployments/azuredeploy/operations/ABB4A5948E69802B",
  "operationId": "ABB4A5948E69802B",
  "properties": {
    "provisioningOperation": "Create",
    "provisioningState": "Failed",
    "duration": "PT0.1417258S",
    "trackingId": "31c4ff19-3064-42ca-bce5-e212459faa75",
    "statusCode": "BadRequest",
    "statusMessage": {
      "error": {
        "code": "FailoverGroupCreateOrUpdateRequestReadOnlyPropertyModified",
        "message": "The create or update failover group request body should not modify the read-only property 'properties.partnerServers'."
      }
    },
    "targetResource": {
      "id": "/subscriptions/9466fa60-58e2-4d62-bd5c-290b2707ca35/resourceGroups/my-rg/providers/Microsoft.Sql/servers/my-sqlserv/failoverGroups/my-sqlservfg",
      "resourceType": "Microsoft.Sql/servers/failoverGroups",
      "resourceName": "my-sqlserv/my-sqlservfg"
    }
  }
}

A bit of background may be useful at this stage - I had just finished moving the failover group resource, and its associated components, from another subscription. As part of this, some resource types unsupported for resource move (such as Alerts) had to be deleted and recreated using an already authored Resource Manager template. This error, therefore, surfaced during this redeployment, as Azure plainly had some issues when it came to validating and updating the already existing failover group.

I recalled having similar issues with failover groups earlier in the year, under similar circumstances. I also remembered that earlier resource moves across subscriptions sometimes could cause problems, particularly when it comes to underlying Resource ID’s and the like. Although this wasn’t the case upon inspection with the Azure Resource Explorer (a must-have tool for this purpose), I did observe attempts to modify the failover group would also fail. For example, attempts to increase the grace period for data loss to two hours resulted in a similar error to the one above. The only logical conclusion was that something went wrong during the subscription migration. This state of affairs left only a single, nuclear option left at my disposal - to delete and then re-create the failover group via a new template deployment. With fingers and toes crossed throughout, I was relieved to see that this worked as expected.

Now, perhaps very evidently, taking such a drastic step will cause some element of disruption. While deleting a failover group does not pause any database replication settings, any applications interacting the database via the failover group endpoint will be disrupted. The DNS de-registration on Microsoft’s side may also take some time to complete, meaning that any redeployment may have to wait. In my case, I was able to redeploy within 5-10 minutes of removing the failover group, which was not too bad. There is also the risk that someone else may sneak in and grab the failover group DNS record within this short window. What I am getting at is this - think carefully about the impact that the deletion will have on your broader infrastructure and, ideally, schedule any removal during an approved maintenance window.

Azure subscription migrations can be a bit of a hassle to complete, as this example clearly shows. This circumstance reinforces, in my view, the importance of having Azure Resource Manager templates in place for all aspects of your Azure estate. They allow you to quickly deploy your Azure environment out for any purpose, while also ensuring resource groups contain the expected components for your solution. They also cover scenarios like subscription migrations, where, regrettably, not all types of resources can be lifted and shifted to a new location. If you’re still in two minds, get onto the Azure portal, export a template from each of your resource groups and experiment further from there. I am sure that, after a short period, you will begin discovering the multitude of benefits they can deliver.