Overview
We have received several support cases where customers encounter the error shown below when attempting to create a failover group for Azure SQL Managed Instance. In this article, we explore one of the possible causes of this error.
Creating instance failover group failed.
An unexpected error occured while processing the request. Tracking ID: 'XYZ'
Prerequisites Review
This article focuses on an additional configuration requirement beyond what is documented in
Configure a failover group - Azure SQL Managed Instance | Microsoft Learn:
- The secondary managed instance must be empty, without any user databases.
- The configuration of your primary and secondary instance should be the same to ensure the secondary instance can sustainably process changes replicated from the primary instance, including during periods of peak activity. This includes the compute size, storage size, and service tier.
- The IP address range for the virtual network of the primary instance must not overlap with the address range of the virtual network for the secondary managed instance, or any other virtual network peered with either the primary or secondary virtual network.
- Both instances must be in the same DNS zone. When you create your secondary managed instance, you must specify the primary instance's DNS zone ID. If you don't, the zone ID is generated as a random string when the first instance is created in each virtual network and the same ID is assigned to all other instances in the same subnet. Once assigned, the DNS zone can't be modified.
- Network Security Groups (NSG) rules for the subnets of both instances must have open inbound and outbound TCP connections for port 5022 and port range 11000-11999 to facilitate communication between the two instances.
- Managed instances should be deployed to paired regions for performance reasons. Managed instances that reside in geo-paired regions benefit from a significantly higher geo-replication speed compared to unpaired regions.
- Both instances must use the same update policy.
In the scenario discussed here, all of the above requirements were fully satisfied.
Scenario Details
The primary SQL Managed Instance was configured to use customer‑managed keys (CMK) for Transparent Data Encryption (TDE), with automatic key rotation enabled.
The secondary SQL Managed Instance was configured to use service‑managed keys (SMK) or it can be configured with a different CMK than the one used by the primary instance for database encryption.
Root Cause
The issue occurs because all servers participating in geo‑replication must share the same key material as the encryption protector of the primary server. This requirement is documented in
Customer-managed transparent data encryption (TDE) - Azure SQL Database & Azure SQL Managed Instance & Azure Synapse Analytics | Microsoft Learn.
In this scenario, the mismatch between CMK on the primary instance and SMK on the secondary instance caused the failover group creation to fail.
Resolution
If there is a requirement not to encrypt the secondary managed instance databases using the same key as the primary for example, to continue using SMK you can still satisfy the failover group requirement without changing the active encryption protector on the secondary instance.
To achieve this:
- Add the primary instance’s TDE key to the secondary managed instance.
- Ensure that the option “Make this key the default TDE protector” is disabled.
This allows the key to be used solely for failover group operations while keeping SMK or different CMK as the active TDE protector on the secondary instance after failover group creation.
After fixing the issue, failover group was successfully created.
Additional Resources
Configure a failover group - Azure SQL Managed Instance | Microsoft Learn
Disclaimer
Please note that products, features, and configuration options discussed in this article are subject to change. This article reflects the state of Azure SQL Managed Instance as of April 2026.
We hope you found this article helpful. Please feel free to share your feedback in the comments section.
Microsoft