Merge pull request #35093 from MashaMSFT/fixes

Clarifying joining AG & SQL MI failover group updates

Author: JamesJBarnett

azure-sql/includes/failover-group-overview.md

@@ -25,7 +25,7 @@ To achieve full business continuity, adding regional database redundancy is only
 Failover groups support two failover policies:
 
 - **Customer managed (recommended)** - Customers can perform a failover of a group when they notice an unexpected outage impacting one or more databases in the failover group. When using command line tools such as PowerShell, the Azure CLI, or the Rest API, the failover policy value for customer managed is `manual`. 
-- **Microsoft managed** - In the event of a widespread outage that impacts a primary region, Microsoft initiates failover of all impacted failover groups that have their failover policy configured to be Microsoft-managed. Microsoft managed failover won't be initiated for individual failover groups or a subset of failover groups in a region. When using command line tools such as PowerShell, the Azure CLI, or the Rest API, the failover policy value for Microsoft-managed is `automatic`. 
+- **Microsoft managed** - In the event of a widespread outage that impacts a primary region, Microsoft initiates failover of *all* impacted failover groups that have their failover policy configured to be Microsoft-managed. Microsoft managed failover won't be initiated for individual failover groups or a subset of failover groups in a region. When using command line tools such as PowerShell, the Azure CLI, or the Rest API, the failover policy value for Microsoft-managed is `automatic`. 
 
 Each failover policy has a unique set of use cases and corresponding expectations on the failover scope and data loss, as the following table summarizes: 
 
@@ -36,7 +36,7 @@ Each failover policy has a unique set of use cases and corresponding expectation
 
 ### Customer managed
 
-On rare occasions, the built-in [availability or high availability](../database/high-availability-sla-local-zone-redundancy.md) isn't enough to mitigate an outage, and your databases in a failover group might be unavailable for a duration that isn't acceptable to the service level agreement (SLA) of the applications using the databases. Databases can be unavailable due to a localized issue impacting just a few databases, or it could be at the datacenter, availability zone, or region level. In any of these cases, to restore business continuity, you can initiate a forced failover.
+On rare occasions, the built-in [availability or high availability](../database/high-availability-sla-local-zone-redundancy.md) isn't enough to mitigate an outage, and your databases in a failover group might be unavailable for a duration that isn't acceptable to the service level agreement (SLA) of the applications that use the databases. Databases can be unavailable due to a localized issue impacting just a few databases, or it could be at the datacenter, availability zone, or region level. In any of these cases, to restore business continuity, you can initiate a forced failover.
 
 _Setting your failover policy to customer managed is highly recommended_, as it keeps you in control of when to initiate a failover and restore business continuity. You can initiate a failover when you notice an unexpected outage impacting one or more databases in the failover group.
 
@@ -50,17 +50,17 @@ With a Microsoft managed failover policy, disaster recovery responsibility is de
 When these conditions are met, the Azure SQL service initiates forced failovers for all failover groups in the region that have the failover policy set to Microsoft managed. 
 
 > [!IMPORTANT]
-> Use customer managed failover policy to test and implement your disaster recovery plan. **Do not** rely on Microsoft managed failover, which might only be executed by Microsoft in extreme circumstances.
-> A Microsoft managed failover would be initiated for all failover groups in the region that have  failover policy set to Microsoft managed. It can't be initiated for individual failover group. If you need the ability to selectively failover your failover group, use customer managed failover policy. 
+> Use the customer managed failover policy to test and implement your disaster recovery plan. **Do not** rely on Microsoft managed failover, which might only be executed by Microsoft in extreme circumstances.
+> A Microsoft managed failover is initiated for all failover groups in the region that have their failover policy set to Microsoft managed. It can't be initiated for individual failover groups. If you need to selectively fail over your failover group, use customer managed failover policy.
 
 Set the failover policy to Microsoft managed only when:
 
 - You want to delegate disaster recovery responsibility to the Azure SQL service. 
 - The application is tolerant to your database being unavailable for at least one hour or more.
-- It's acceptable to trigger forced failovers some time after the grace period expires as the actual time for the forced failover can vary significantly. 
+- It's acceptable to trigger forced failovers some time after the grace period expires, as the actual time for the forced failover can vary significantly. 
 - It's acceptable that all databases within the failover group fail over, regardless of their zone redundancy configuration or availability status. Although databases configured for zone redundancy are resilient to zonal failures and might not be impacted by an outage, they'll still be failed over if they're part of a failover group with a Microsoft managed failover policy.  
 - It's acceptable to have forced failovers of databases in the failover group without taking into consideration the application's dependency on other Azure services or components used by the application, which can cause performance degradation or unavailability of the application.
 - It's acceptable to incur an unknown amount of data loss, as the exact time of forced failover can't be controlled, and ignores the synchronization status of the secondary databases.
-- All the primary and secondary database(s) in the failover group and any geo replication relationships have the same service tier, compute tier (provisioned or serverless) & compute size (DTUs or vCores). If the service level objective (SLO) of all the databases don't match, then the failover policy will be eventually updated from Microsoft Managed to Customer Managed by Azure SQL service. 
+- The primary and secondary replicas in the failover group have the same service tier, compute tier, and compute size.
 
 When a failover is triggered by Microsoft, an entry for the operation name **Failover Azure SQL failover group** is added to the [Azure Monitor activity log](/azure/azure-monitor/essentials/activity-log). The entry includes the name of the failover group under **Resource**, and **Event initiated by** displays a single hyphen (-) to indicate the failover was initiated by Microsoft.  This information can also be found on the **Activity log** page of the new primary server or instance in the Azure portal. 

azure-sql/managed-instance/doc-changes-updates-known-issues.md

@@ -5,7 +5,7 @@ description: Learn about the currently known issues with Azure SQL Managed Insta
 author: MashaMSFT
 ms.author: mathoma
 ms.reviewer: randolphwest, mathoma
-ms.date: 06/09/2025
+ms.date: 08/25/2025
 ms.service: azure-sql-managed-instance
 ms.subservice: service-overview
 ms.topic: troubleshooting-known-issue
@@ -28,7 +28,7 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 | [Error 8992 when running DBCC CHECKDB on a SQL Server database that originated from SQL Managed Instance](#error-8992-when-running-dbcc-checkdb-on-a-sql-server-database-that-originated-from-sql-managed-instance) | March 2025 | Has workaround | |
 | [Differential backups aren't taken when an instance is linked to SQL Server](#differential-backups-arent-taken-when-an-instance-is-linked-to-sql-server) | Sept 2024 | By design | |
 | [List of long-term backups in Azure portal shows backup files for active and deleted databases with the same name](#list-of-long-term-backups-in-azure-portal-shows-backup-files-for-active-and-deleted-databases-with-the-same-name) | Mar 2024 | Has Workaround | |
-| [Temporary instance inaccessibility using the failover group listener during scaling operation](#temporary-instance-inaccessibility-using-the-failover-group-listener-during-scaling-operation) | Jan 2024 | No resolution | |
+| [Temporary instance inaccessibility using the failover group listener during scaling operation](#temporary-instance-inaccessibility-using-the-failover-group-listener-during-scaling-operation) | Jan 2024 | Resolved | April 2025 |
 | [The event_file target of the system_health event session is not accessible](#the-event_file-target-of-the-system_health-event-session-is-not-accessible) | Dec 2023 | Resolved | May 2025 |
 | [Procedure sp_send_dbmail might fail when @query parameter is used on Nov22FW enabled managed instances](#procedure-sp_send_dbmail-may-fail-when-query-parameter-is-used-on-nov22fw-enabled-managed-instances) | Dec 2023 | Has Workaround | |
 | [Increased number of system logins used for transactional replication](#increased-number-of-system-logins-used-for-transactional-replication) | Dec 2022 | No resolution | |
@@ -213,7 +213,11 @@ A DNS record of `<name>.database.windows.com` is created when you create a [logi
 
 In some circumstances, there might exist an issue with Service Principal used to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)) and Azure Key Vault (AKV) services. As a result, this issue impacts usage of Microsoft Entra authentication and transparent data encryption (TDE) with SQL Managed Instance. This might be experienced as an intermittent connectivity issue, or not being able to run statements such are `CREATE LOGIN/USER FROM EXTERNAL PROVIDER` or `EXECUTE AS LOGIN/USER`. Setting up TDE with customer-managed key on a new Azure SQL Managed Instance might also not work in some circumstances.
 
-**Workaround**: To prevent this issue from occurring on your SQL Managed Instance, before executing any update commands, or in case you have already experienced this issue after update commands, go to the **Overview page** of your SQL managed instance in the Azure portal. Under **Settings**, select **Microsoft Entra ID** to access the SQL Managed Instance [Microsoft Entra ID admin page](../database/authentication-aad-configure.md#azure-sql-managed-instance). Verify if you can see the error message "Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal". In case you've encountered this error message, select it, and follow the step-by-step instructions provided until this error has been resolved.
+**Workaround**: To prevent this issue from occurring on your SQL Managed Instance, before executing any update commands, or in case you have already experienced this issue after update commands, go to the **Overview page** of your SQL managed instance in the Azure portal. Under **Settings**, select **Microsoft Entra ID** to access the SQL Managed Instance [Microsoft Entra ID admin page](../database/authentication-aad-configure.md#azure-sql-managed-instance). Verify if you can see the error message: 
+
+`Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal`. 
+
+In case you've encountered this error message, select it, and follow the step-by-step instructions provided until this error has been resolved.
 
 ### SQL Agent roles need explicit EXECUTE permissions for non-sysadmin logins
 
@@ -362,8 +366,13 @@ The `tempdb` database is always split into 12 data files, and the file structure
 
 Error logs that are available in SQL Managed Instance aren't persisted, and their size isn't included in the maximum storage limit. Error logs might be automatically erased if failover occurs. There might be gaps in the error log history because SQL Managed Instance was moved several times on several virtual machines.
 
+
+## Resolved
+
 ### Temporary instance inaccessibility using the failover group listener during scaling operation
 
+**(Resolved in April 2025)**
+
 Scaling managed instance sometimes requires moving the instance to a different virtual cluster, along with the associated service-maintained DNS records. If the managed instance participates in a failover group, the DNS record corresponding to its associated failover group listener (read-write listener, if the instance is the current geo-primary read-only listener, if the instance is the current geo-secondary) is moved to the new virtual cluster.
 
 In the current scaling operation design, the listener DNS records are removed from the originating virtual cluster before the managed instance itself is fully migrated to the new virtual cluster, which in some situations can lead to prolonged time during which the instance's IP address can't be resolved using the listener. During this time, a SQL client attempting to access the instance being scaled using the listener endpoint can expect login failures with the following error message:
@@ -374,7 +383,7 @@ Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The lo
 
 The issue will be addressed through scaling operation redesign.
 
-## Resolved
+
 
 <a id="msdb-table-for-manual-backups-doesnt-preserve-the-username"></a>
 
@@ -438,7 +447,7 @@ The `@query` parameter in the [sp_send_db_mail](/sql/relational-databases/system
 
 The **Active Directory admin** page of Azure portal for Azure SQL Managed Instance might show the following error message, even though Service Principal already exists:
 
-"Managed Instance needs a Service Principal to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)). Click here to create a Service Principal"
+`Managed Instance needs a Service Principal to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)). Click here to create a Service Principal`
 
 You can neglect this error message if Service Principal for the managed instance already exists, and/or Microsoft Entra authentication on the managed instance works.