Merge pull request #22930 from rwestMSFT/rw-0613-always-on-rename

AlwaysOn -> Always On [Bulk update]

Author: Court72

azure-sql/managed-instance/managed-instance-link-preparation-wsfc.md

@@ -114,11 +114,11 @@ Next, verify that Always On option can be enabled on SQL Server by following the
 
 1. Open SQL Server Configuration Manager
 1. Double-click on SQL Server
-1. Click on AlwaysOn High Availability tab
+1. Click on Always On High Availability tab
 
    :::image type="content" source="./media/managed-instance-link-preparation-wsfc/managed-instance-link-alwayson-validate.png" alt-text="Screenshot of validating that Always On option is enabled in SQL Server.":::
 
-   - You should be able to see the name of the WSFC you've created, and you should be able to check-on the Enable AlwaysOn Availability Groups should option. This verification confirms the configuration has been completed successfully.
+   - You should be able to see the name of the WSFC you've created, and you should be able to check-on the Enable Always On Availability Groups should option. This verification confirms the configuration has been completed successfully.
 
 ## Grant permissions in SQL Server for WSFC
 

azure-sql/managed-instance/managed-instance-link-preparation.md

@@ -96,10 +96,10 @@ select
     end as 'HadrStatus'
 ```
 
-The above query will display if AlwaysOn availability group is enabled, or not, on your SQL Server.
+The above query will display if Always On availability group is enabled, or not, on your SQL Server.
 
 >[!IMPORTANT]
-> For SQL Server 2016, if you need to enable AlwaysOn availability group, you will need to complete extra steps documented in [prepare SQL Server 2016 prerequisites](managed-instance-link-preparation-wsfc.md). These extra steps are not required for all higher SQL Server versions (2019-2022) supported by the link.
+> For SQL Server 2016, if you need to enable Always On availability group, you will need to complete extra steps documented in [prepare SQL Server 2016 prerequisites](managed-instance-link-preparation-wsfc.md). These extra steps are not required for all higher SQL Server versions (2019-2022) supported by the link.
 
 If the availability groups feature isn't enabled, follow these steps to enable it, or otherwise skip to the next section: 
 
@@ -110,11 +110,11 @@ If the availability groups feature isn't enabled, follow these steps to enable i
    :::image type="content" source="./media/managed-instance-link-preparation/sql-server-configuration-manager-sql-server-properties.png" alt-text="Screenshot that shows SQL Server Configuration Manager, with selections for opening properties for the service.":::
 
 1. Go to the **Always On Availability Groups** tab. 
-1. Select the **Enable AlwaysOn Availability Groups** checkbox, and then select **OK**. 
+1. Select the **Enable Always On Availability Groups** checkbox, and then select **OK**. 
 
    :::image type="content" source="./media/managed-instance-link-preparation/always-on-availability-groups-properties.png" alt-text="Screenshot that shows the properties for Always On availability groups.":::
 
-    - If using **SQL Server 2016**, and if Enable AlwaysOn Availability Groups option is disabled with message `This computer is not a node in a failover cluster.`, follow extra steps described in [prepare SQL Server 2016 prerequisites](managed-instance-link-preparation-wsfc.md). Once you've completed these other steps, come back and retry this step again.
+    - If using **SQL Server 2016**, and if Enable Always On Availability Groups option is disabled with message `This computer is not a node in a failover cluster.`, follow extra steps described in [prepare SQL Server 2016 prerequisites](managed-instance-link-preparation-wsfc.md). Once you've completed these other steps, come back and retry this step again.
 
 1. Select **OK** in the dialog
 1. Restart the SQL Server service.

azure-sql/managed-instance/user-initiated-failover.md

@@ -131,7 +131,7 @@ To monitor the progress of user initiated failover for your BC instance, execute
 SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states
 ```
 
-Before initiating the failover, your output will indicate the current primary replica on BC service tier containing one primary and three secondaries in the AlwaysOn Availability Group. Upon execution of a failover, running this query again would need to indicate a change of the primary node.
+Before initiating the failover, your output will indicate the current primary replica on BC service tier containing one primary and three secondaries in the Always On Availability Group. Upon execution of a failover, running this query again would need to indicate a change of the primary node.
 
 You will not be able to see the same output with GP service tier as the one above shown for BC. This is because GP service tier is based on a single node only. 
 You can use alternative T-SQL query showing the time SQL process started on the node for GP service tier instance:

azure-sql/virtual-machines/windows/application-patterns-development-strategies.md

@@ -35,7 +35,7 @@ To complete the steps in this article, your availability groups need to be alrea
 
 Related topics include:
 
-* [Configure AlwaysOn Availability Groups in Azure VM (GUI)](availability-group-manually-configure-tutorial-single-subnet.md)   
+* [Configure Always On Availability Groups in Azure VM (GUI)](availability-group-manually-configure-tutorial-single-subnet.md)   
 * [Configure a VNet-to-VNet connection by using Azure Resource Manager and PowerShell](/azure/vpn-gateway/vpn-gateway-vnet-vnet-rm-ps)
 
 [!INCLUDE [updated-for-az.md](../../includes/updated-for-az.md)]
@@ -195,7 +195,7 @@ $ILB | Add-AzLoadBalancerRuleConfig -Name $LBConfigRuleName -FrontendIpConfigura
 
 1. Launch SQL Server Management Studio and connect to the primary replica.
 
-1. Navigate to **AlwaysOn High Availability** > **Availability Groups** > **Availability Group Listeners**. 
+1. Navigate to **Always On High Availability** > **Availability Groups** > **Availability Group Listeners**. 
 
 1. You should now see the listener name that you created in Failover Cluster Manager. Right-click the listener name and select **Properties**.
 

azure-sql/virtual-machines/windows/availability-group-listener-powershell-configure.md

@@ -188,7 +188,7 @@ If the cluster resources and dependencies are correctly configured, you should b
 
 1. Start SQL Server Management Studio, and then connect to the primary replica.
 
-2. Go to **AlwaysOn High Availability** > **Availability Groups** > **Availability Group Listeners**.  
+2. Go to **Always On High Availability** > **Availability Groups** > **Availability Group Listeners**.  
 
     You should now see the listener name that you created in Failover Cluster Manager. 
 

azure-sql/virtual-machines/windows/availability-group-load-balancer-portal-configure.md

@@ -159,14 +159,14 @@ The replica in the remote data center is part of the availability group but it i
 
 Preferably, update the cluster configuration to set `RegisterAllProvidersIP=1` and the client connection strings to set `MultiSubnetFailover=Yes`. See [Connecting With MultiSubnetFailover](/sql/relational-databases/native-client/features/sql-server-native-client-support-for-high-availability-disaster-recovery#Anchor_0).
 
-If you cannot modify the connection strings, you can configure name resolution caching. See [Time-out error and you cannot connect to a SQL Server 2012 AlwaysOn availability group listener in a multi-subnet environment](https://support.microsoft.com/help/2792139/time-out-error-and-you-cannot-connect-to-a-sql-server-2012-alwayson-av).
+If you cannot modify the connection strings, you can configure name resolution caching. See [Time-out error and you cannot connect to a SQL Server 2012 Always On availability group listener in a multi-subnet environment](https://support.microsoft.com/help/2792139/time-out-error-and-you-cannot-connect-to-a-sql-server-2012-alwayson-av).
 
 ## Fail over to remote region
 
 To test listener connectivity to the remote region, you can fail over the replica to the remote region. While the replica is asynchronous, failover is vulnerable to potential data loss. To fail over without data loss, change the availability mode to synchronous and set the failover mode to automatic. Use the following steps:
 
 1. In **Object Explorer**, connect to the instance of SQL Server that hosts the primary replica.
-1. Under **AlwaysOn Availability Groups**, **Availability Groups**, right-click your availability group and select **Properties**.
+1. Under **Always On Availability Groups**, **Availability Groups**, right-click your availability group and select **Properties**.
 1. On the **General** page, under **Availability Replicas**, set the secondary replica in the DR site to use **Synchronous Commit** availability mode and **Automatic** failover mode.
 1. If you have a secondary replica in same site as your primary replica for high availability, set this replica to **Asynchronous Commit** and **Manual**.
 1. Select OK.

azure-sql/virtual-machines/windows/availability-group-manually-configure-multiple-regions.md

@@ -191,9 +191,9 @@ To enable the availability group feature, follow these steps:
 1. Launch the RDP file to the first SQL Server VM (such as **SQL-VM-1**) with a domain account that is a member of sysadmin fixed server role, such as the **CORP\Install** domain account created in the [prerequisites document](availability-group-manually-configure-prerequisites-tutorial-multi-subnet.md)
 1. From the **Start** screen of one your SQL Server VMs, launch **SQL Server Configuration Manager**.
 1. In the browser tree, highlight **SQL Server Services**, right-click the **SQL Server (MSSQLSERVER)** service and select **Properties**.
-1. Select the **AlwaysOn High Availability** tab, then check the box to **Enable AlwaysOn availability groups**:
+1. Select the **Always On High Availability** tab, then check the box to **Enable Always On availability groups**:
 
-    :::image type="content" source="./media/availability-group-manually-configure-tutorial-multi-subnet/08-enable-always-on.png" alt-text="Enable AlwaysOn availability groups":::
+    :::image type="content" source="./media/availability-group-manually-configure-tutorial-multi-subnet/08-enable-always-on.png" alt-text="Enable Always On availability groups":::
 
 1. Select **Apply**. Select **OK** in the pop-up dialog.
 1. Restart the SQL Server service.

azure-sql/virtual-machines/windows/availability-group-manually-configure-tutorial-multi-subnet.md

@@ -196,13 +196,13 @@ The cluster core resources are configured with a file share witness.
 
 ## Enable availability groups
 
-Next, enable the **AlwaysOn availability groups** feature. Do these steps on both SQL Servers.
+Next, enable the **Always On availability groups** feature. Do these steps on both SQL Servers.
 
 1. From the **Start** screen, launch **SQL Server Configuration Manager**.
 2. In the browser tree, select **SQL Server Services**, then right-click the **SQL Server (MSSQLSERVER)** service and select **Properties**.
-3. Select the **AlwaysOn High Availability** tab, then select **Enable AlwaysOn availability groups**, as follows:
+3. Select the **Always On High Availability** tab, then select **Enable Always On availability groups**, as follows:
 
-    ![Enable AlwaysOn availability groups](./media/availability-group-manually-configure-tutorial-single-subnet/54-enableAlwaysOn.png)
+    ![Enable Always On availability groups](./media/availability-group-manually-configure-tutorial-single-subnet/54-enableAlwaysOn.png)
 
 4. Select **Apply**. Select **OK** in the pop-up dialog.
 
@@ -286,7 +286,7 @@ You are now ready to configure an availability group using the following steps:
 
 ### Create the availability group:
 
-1. On remote desktop session to the first SQL Server. In **Object Explorer** in SSMS, right-click **AlwaysOn High Availability** and select **New availability group Wizard**.
+1. On remote desktop session to the first SQL Server. In **Object Explorer** in SSMS, right-click **Always On High Availability** and select **New availability group Wizard**.
 
     ![Launch New availability group Wizard](./media/availability-group-manually-configure-tutorial-single-subnet/56-newagwiz.png)
 
@@ -339,11 +339,11 @@ You are now ready to configure an availability group using the following steps:
 
 ### Check the availability group
 
-1. In **Object Explorer**, expand **AlwaysOn High Availability**, and then expand **availability groups**. You should now see the new availability group in this container. Right-click the availability group and select **Show Dashboard**.
+1. In **Object Explorer**, expand **Always On High Availability**, and then expand **availability groups**. You should now see the new availability group in this container. Right-click the availability group and select **Show Dashboard**.
 
    ![Show availability group Dashboard](./media/availability-group-manually-configure-tutorial-single-subnet/76-showdashboard.png)
 
-   Your **AlwaysOn Dashboard** should look similar to the following screenshot:
+   Your **Always On Dashboard** should look similar to the following screenshot:
 
    ![availability group Dashboard](./media/availability-group-manually-configure-tutorial-single-subnet/78-agdashboard.png)
 
@@ -354,7 +354,7 @@ You are now ready to configure an availability group using the following steps:
    ![availability group in Failover Cluster Manager](./media/availability-group-manually-configure-tutorial-single-subnet/80-clustermanager.png)
 
    > [!WARNING]
-   > Do not try to fail over the availability group from the Failover Cluster Manager. All failover operations should be performed from within **AlwaysOn Dashboard** in SSMS. For more information, see [Restrictions on Using The Failover Cluster Manager with availability groups](/sql/database-engine/availability-groups/windows/failover-clustering-and-always-on-availability-groups-sql-server).
+   > Do not try to fail over the availability group from the Failover Cluster Manager. All failover operations should be performed from within **Always On Dashboard** in SSMS. For more information, see [Restrictions on Using The Failover Cluster Manager with availability groups](/sql/database-engine/availability-groups/windows/failover-clustering-and-always-on-availability-groups-sql-server).
     >
 
 At this point, you have an availability group with replicas on two instances of SQL Server. You can move the availability group between instances. You cannot connect to the availability group yet because you do not have a listener. In Azure virtual machines, the listener requires a load balancer. The next step is to create the load balancer in Azure.
@@ -513,7 +513,7 @@ In SQL Server Management Studio, set the listener port.
 
 1. Launch SQL Server Management Studio and connect to the primary replica.
 
-1. Navigate to **AlwaysOn High Availability** > **availability groups** > **availability group Listeners**.
+1. Navigate to **Always On High Availability** > **availability groups** > **availability group Listeners**.
 
 1. You should now see the listener name that you created in Failover Cluster Manager. Right-click the listener name and select **Properties**.
 

azure-sql/virtual-machines/windows/availability-group-manually-configure-tutorial-single-subnet.md

@@ -36,7 +36,7 @@ The primary migration methods are:
 * Detach the data and log files, copy them to Azure Blob storage, and then attach them to SQL Server in the Azure VM from the URL.
 * Convert the on-premises physical machine to a Hyper-V VHD, upload it to Azure Blob storage, and then deploy it as new VM using uploaded VHD.
 * Ship the hard drive using the Windows Import/Export Service.
-* If you have an AlwaysOn Availability Group deployment on-premises, use the [Add Azure Replica Wizard](/previous-versions/azure/virtual-machines/windows/sqlclassic/virtual-machines-windows-classic-sql-onprem-availability) to create a replica in Azure, failover, and point users to the Azure database instance.
+* If you have an Always On Availability Group deployment on-premises, use the [Add Azure Replica Wizard](/previous-versions/azure/virtual-machines/windows/sqlclassic/virtual-machines-windows-classic-sql-onprem-availability) to create a replica in Azure, failover, and point users to the Azure database instance.
 * Use SQL Server [transactional replication](/sql/relational-databases/replication/transactional/transactional-replication) to configure the Azure SQL Server instance as a subscriber, disable replication, and point users to the Azure database instance.
 
 > [!TIP]
@@ -46,7 +46,7 @@ The primary migration methods are:
 
 For best data transfer performance, migrate the database files into the Azure VM using a compressed backup file.
 
-To minimize downtime during the database migration process, use either the AlwaysOn option or the transactional replication option.
+To minimize downtime during the database migration process, use either the Always On option or the transactional replication option.
 
 If it isn't possible to use the above methods, manually migrate your database. Generally, you start with a database backup, follow it with a copy of the database backup into Azure, and then restore the database. You can also copy the database files themselves into Azure and then attach them. There are several methods by which you can accomplish this manual process of migrating a database into an Azure VM.