Merge pull request #36516 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-28 23:30 UTC

Author: learn-build-service-prod[bot]

azure-sql/database/failover-group-sql-db.md

@@ -90,10 +90,7 @@ There is some overlap of content in the following articles, be sure to make chan
 
 - **Failover group read-only listener**
 
-  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. If you can't tolerate downtime for the read-only sessions and can use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the `AllowReadOnlyFailoverToPrimary` property. In that case, the read-only traffic is automatically redirected to the primary if the secondary isn't available.
-
-  > [!NOTE]
-  > The `AllowReadOnlyFailoverToPrimary` property only has effect if Microsoft managed failover policy is enabled and a forced failover has been triggered. In that case, if the property is set to True, the new primary will serve both read-write and read-only sessions.
+  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. 
 
 - **Multiple failover groups**
 

azure-sql/managed-instance/failover-group-configure-sql-mi.md

@@ -524,10 +524,12 @@ When using failover groups, consider the following limitations:
     - after failover, and can delay or prevent a subsequent failover.
 - Database rename isn't supported for databases in failover group. You'll need to temporarily delete the failover group to be able to rename a database.
 - System databases aren't replicated to the secondary instance in a failover group. Therefore, scenarios that depend on objects from the system databases such as Server Logins and Agent jobs, require objects to be manually created on the secondary instances and also manually kept in sync after any changes made on primary instance. The only exception is Service master Key (SMK) for SQL Managed Instance that is replicated automatically to secondary instance during creation of failover group. Any subsequent changes of SMK on the primary instance however won't be replicated to secondary instance. To learn more, see how to [Enable scenarios dependent on objects from the system databases](#enable-scenarios-dependent-on-objects-from-the-system-databases).
+- When new databases are added to a failover group, planned failover is unavailable until the new database has been seeded to the secondary replica and is synchronized. Forced failover is still available during this process.
 - For instances inside of a failover group, changing the service tier to, or from, the Next-gen General Purpose tier isn't supported. You must first delete the failover group before modifying either replica, and then re-create the failover group after the change takes effect.
 - SQL managed instances in a failover group must have the same [update policy](update-policy.md), though it's possible to [change the update policy](#change-update-policy) for instances within a failover group.
 
 
+
 ## <a id="programmatically-managing-failover-groups"></a> Programmatically manage failover groups
 
 Failover groups can also be managed programmatically using Azure PowerShell, Azure CLI, and REST API. The following tables describe the set of commands available. Failover groups include a set of Azure Resource Manager APIs for management, including the [Azure SQL Database REST API](/rest/api/sql/) and [Azure PowerShell cmdlets](/powershell/azure/). These APIs require the use of resource groups and support Azure role-based access control (Azure RBAC). For more information on how to implement access roles, see [Azure role-based access control (Azure RBAC)](/azure/role-based-access-control/overview).

azure-sql/managed-instance/failover-group-sql-mi.md

@@ -74,10 +74,7 @@ There's some overlap of content in the following articles, be sure to make chang
 
 - **Failover group read-only listener**
 
-  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a SQL managed instance, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.<zone_id>.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. If you can't tolerate downtime for the read-only sessions and can use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the `AllowReadOnlyFailoverToPrimary` property. In that case, the read-only traffic is automatically redirected to the primary if the secondary isn't available.
-
-  > [!NOTE]  
-  > The `AllowReadOnlyFailoverToPrimary` property only has effect if Microsoft managed failover policy is enabled and a forced failover has been triggered. In that case, if the property is set to True, the new primary serves both read-write and read-only sessions.
+  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a SQL managed instance, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.<zone_id>.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. 
 
 ## Failover group architecture
 
@@ -267,13 +264,16 @@ Performing a drill using forced failover is **not recommended**, as this operati
 - The workload is stopped on the primary SQL managed instance.
 - All long running transactions have completed.
 - All client connections to the primary SQL managed instance have been disconnected.
-- [Failover group status](failover-group-sql-mi.md#failover-group-status) is 'Synchronizing'.
+- [Failover group status](failover-group-sql-mi.md#failover-group-status) is `Synchronizing` on **both** the primary and secondary instances.
 
 Please ensure the two SQL managed instances have switched roles. Also that the failover group status has switched from *'Failover in progress'* to *'Synchronizing'* before optionally establishing connections to the new primary SQL managed instance and starting read-write workload.
 
-To perform a data lossless failback to the original SQL managed instance roles, using manual planned failover instead of forced failover is **strongly recommended**. If forced failback is used:
+To perform a data lossless failback to the original SQL managed instance roles, using manual planned failover instead of forced failover is **strongly recommended**. 
+
+If forced failback is used:
 
 - Follow the same steps as for the data lossless failover.
+- Forced failback is expected to fail if a previous forced failover did not succeed on both SQL managed instances. Ensure failover group status is `Synchronizing` on **both** instances before executing the forced failback.
 - Longer failback execution time is expected if the forced failback is executed **shortly after** the initial forced failover is completed, as it has to wait for completion of outstanding automatic backup operations on the former primary SQL managed instance.
 - Any outstanding automatic backup operations on an instance transitioning from the primary to the secondary role can impact database availability on this instance.
 - Please use the failover group status to determine whether both instances have successfully changed their roles and are ready to accept client connections.

docs/linux/sql-server-linux-custom-password-policy.md

@@ -4,7 +4,7 @@ description: Learn how to use a custom password policy for SQL logins with SQL S
 author: Madhumitatripathy
 ms.author: matripathy
 ms.reviewer: mikeray, randolphwest
-ms.date: 05/01/2025
+ms.date: 01/16/2026
 ms.service: sql
 ms.subservice: linux
 ms.topic: how-to
@@ -30,23 +30,23 @@ Password policies are a crucial aspect of securing any database environment. The
 This enforcement ensures that logins that use SQL Server authentication are secure.
 
 > [!NOTE]  
-> Password policies are available on Windows. For more information, see [Password Policy](../relational-databases/security/password-policy.md).
+> Password policies are available on Windows. For more information, see [Password policy](../relational-databases/security/password-policy.md).
 
 ## Custom policy settings
 
-Beginning with [!INCLUDE [sssql25-md](../includes/sssql25-md.md)] on Linux, you can set the following configuration parameters in the `mssql.conf` file to enforce a custom password policy.
+In [!INCLUDE [sssql25-md](../includes/sssql25-md.md)] and later versions on Linux, you can set the following configuration parameters in the `mssql.conf` file to enforce a custom password policy.
 
 | Configuration option | Description |
 | --- | --- |
-| `passwordpolicy.passwordminimumlength` | Defines the minimum number of characters required for a password. The passwords can be up to 128 characters long. |
-| `passwordpolicy.passwordhistorylength` | Determines the number of previous passwords that must be remembered. |
-| `passwordpolicy.passwordminimumage` | Specifies the minimum duration a user must wait before changing their password again. |
+| `passwordpolicy.passwordminimumlength` | Sets the minimum number of characters required for a password. Passwords can be up to 128 characters long. |
+| `passwordpolicy.passwordhistorylength` | Sets the number of previous passwords that the system remembers. |
+| `passwordpolicy.passwordminimumage` | Sets the minimum duration a user must wait before changing their password again. |
 | `passwordpolicy.passwordmaximumage` | Sets the maximum duration a password can be used before it must be changed. |
 
 > [!NOTE]  
-> Currently, the `passwordminimumlength` can be set to fewer than eight characters. [!INCLUDE [password-complexity](includes/password-complexity.md)]
+> You can currently set the `passwordminimumlength` to fewer than eight characters. [!INCLUDE [password-complexity](includes/password-complexity.md)]
 
-There are two ways to configure custom password policies for SQL authentication logins in SQL Server on Linux:
+You can configure custom password policies for SQL authentication logins in SQL Server on Linux in two ways:
 
 - [Enforce custom password policy](#adutil) with **adutil**
 - [Manually configure the `mssql.conf` file](#manual) using the **mssql-conf** tool
@@ -55,19 +55,19 @@ There are two ways to configure custom password policies for SQL authentication
 
 ## Set custom password policy with adutil
 
-In environments where policy management is centralized in an Active Directory (AD) server, domain administrators can set and modify the password policy values in the AD server. Additionally, the Linux machine running SQL Server must also be part of the Windows domain.
+In environments where policy management is centralized in an Active Directory (AD) server, domain administrators set and modify the password policy values in the AD server. The Linux machine running SQL Server must also be part of the Windows domain.
 
 Use [adutil](sql-server-linux-ad-auth-adutil-introduction.md) to fetch the password policy from the AD server and write it to the `mssql.conf` file. This method offers the benefit of centralized management, and ensures consistent application of policies across the SQL Server environment.
 
 ### Requirements for adutil
 
-1. Establish a Kerberos authenticated session
+1. Establish a Kerberos authenticated session:
 
-   - Run `kinit` with `sudo` to obtain or renew the Kerberos ticket-granting ticket (TGT).
+   - Run `kinit` with `sudo` to get or renew the Kerberos ticket-granting ticket (TGT).
 
-   - Use a privileged account for the `kinit` command. The account needs to have permission to connect to the domain.
+   - Use a privileged account for the `kinit` command. The account needs permission to connect to the domain.
 
-   In the following example, replace `<user>` with an account with elevated privileges in the domain.
+   In the following example, replace `<user>` with an account that has elevated privileges in the domain.
 
    ```bash
    sudo kinit <user>@CONTOSO.COM
@@ -85,7 +85,7 @@ Use [adutil](sql-server-linux-ad-auth-adutil-introduction.md) to fetch the passw
    sudo adutil updatepasswordpolicy
    ```
 
-   If the command is successful, you should see a similar message:
+   If the command is successful, the output looks similar to the following example:
 
    ```output
    Successfully updated password policy in mssqlconf.
@@ -102,15 +102,15 @@ Use [adutil](sql-server-linux-ad-auth-adutil-introduction.md) to fetch the passw
 
 <a id="manual"></a>
 
-## Set custom password policy with mssql-conf manually
+## Manually set a custom password policy using mssql-conf
 
 You can set the SQL authentication login password policy by updating the parameters in the `mssql.conf` file with **mssql-conf**. This approach provides simplicity and direct control over the policy settings.
 
-Use this method when the Linux host that is running SQL Server isn't part of the domain, and there's no domain controller to get the password policies from.
+Use this method when the Linux host running SQL Server isn't part of the domain, and there's no domain controller to get the password policies from.
 
 Run the following **mssql-conf** commands to set each policy configuration property.
 
-1. Set the minimum password length to 14 characters, adhering to the complexity requirements outlined in the [Password Policy](../relational-databases/security/password-policy.md).
+1. Set the minimum password length to 14 characters, adhering to the complexity requirements outlined in the [Password policy](../relational-databases/security/password-policy.md).
 
    ```bash
    sudo /opt/mssql/bin/mssql-conf set passwordpolicy.passwordminimumlength 14
@@ -128,7 +128,7 @@ Run the following **mssql-conf** commands to set each policy configuration prope
    sudo /opt/mssql/bin/mssql-conf set passwordpolicy.passwordhistorylength 8
    ```
 
-1. Set the maximum password age is set to 45 days. A user can use a password for up to 45 days before the user must change it.
+1. Set the maximum password age to 45 days. A user can use a password for up to 45 days before the user must change it.
 
    ```bash
    sudo /opt/mssql/bin/mssql-conf set passwordpolicy.passwordmaximumage 45
@@ -146,13 +146,13 @@ Currently, the `minimumpasswordlength` can't be set to more than 14 characters.
 
 After updating the group password policy in Active Directory, you must manually run the `adutil updatepasswordpolicy` command to update `mssql.conf`. This command doesn't run automatically. Ensure the Linux machine running SQL Server is part of the domain, or manually set it using **mssql-conf**.
 
-In Active Directory, each group-level password policy can be defined or undefined using a checkbox.
+In Active Directory, you can define or undefine each group-level password policy using a checkbox.
 
 :::image type="content" source="media/sql-server-linux-custom-password-policy/password-length-properties.png" alt-text="Screenshot of minimum password length security policy setting.":::
 
 However, unchecking the policy doesn't disable it in SQL Server on Linux. To avoid applying the custom password policy, update the settings in **mssql-conf** instead of relying on the checkbox.
 
 ## Related content
 
-- [Password Policy](../relational-databases/security/password-policy.md)
-- [Strong Passwords](../relational-databases/security/strong-passwords.md)
+- [Password policy](../relational-databases/security/password-policy.md)
+- [Strong passwords](../relational-databases/security/strong-passwords.md)