Merge pull request #250520 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: rmca14

.openpublishing.redirection.azure-vmware.json

@@ -9,6 +9,11 @@
             "source_path_from_root": "/articles/azure-vmware/attach-disk-pools-to-azure-vmware-solution-hosts.md",
             "redirect_url": "/azure/storage/elastic-san/elastic-san-introduction",
             "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-vmware/migrate-sql-server-always-on-cluster.md",
+            "redirect_url": "/articles/azure-vmware/migrate-sql-server-always-on-availability-group",
+            "redirect_document_id": false
         }
     ]
 }

articles/active-directory/managed-identities-azure-resources/how-to-view-managed-identity-activity.md

@@ -106,8 +106,11 @@ System-assigned identity:
 5. To view the identity's Enterprise application in Azure Active Directory, select the “Managed Identity ID” column.
 6. To view the Azure resource or user-assigned managed identity, search by name in the search bar of the Azure portal.
 
+ > [!NOTE] 
+ > Since managed identity authentication requests originate within the Azure infrastructure, the IP Address value is excluded here.
+
 ## Next steps
 
 * [Managed identities for Azure resources](./overview.md)
 * [Azure Activity log](../../azure-monitor/essentials/activity-log.md)
-* [Azure Active Directory sign-ins log](../reports-monitoring/concept-sign-ins.md)
+* [Azure Active Directory sign-ins log](../reports-monitoring/concept-sign-ins.md)

articles/aks/auto-upgrade-node-image.md

@@ -93,7 +93,7 @@ az provider register --namespace Microsoft.ContainerService
 - The `SecurityPatch` channel isn't supported on Windows OS node pools. 
 
  > [!NOTE]
- > By default, any new cluster created with an API version of `06-01-2022`or later will set the node OS auto-upgrade channel value to `NodeImage`. Any existing clusters created with an API version earlier than `06-01-2022` will have the node OS auto-upgrade channel value set to `None` by default.
+ > By default, any new cluster created with an API version of `06-01-2022` or later will set the node OS auto-upgrade channel value to `NodeImage`. Any existing clusters created with an API version earlier than `06-01-2022` will have the node OS auto-upgrade channel value set to `None` by default.
 
 
 ## Using node OS auto-upgrade with Planned Maintenance
@@ -117,7 +117,7 @@ To view the status of your node OS auto upgrades, look up [activity logs][monito
 
 * Can I change the node OS auto-upgrade channel value if my cluster auto-upgrade channel is set to `node-image` ?
 
- No. Currently, when you set the [cluster auto-upgrade channel][Autoupgrade] to `node-image`, it also automatically sets the node OS auto-upgrade channel to `NodeImage`. You can't change the node OS auto-upgrade channel value if your cluster auto-upgrade channel is `node-image`. In order to be able to change the node OS auto-upgrade channel values, make sure the cluster auto-upgrade channel isn't `node-image`.
+ No. Currently, when you set the [cluster auto-upgrade channel][Autoupgrade] to `node-image`, it also automatically sets the node OS auto-upgrade channel to `NodeImage`. You can't change the node OS auto-upgrade channel value if your cluster auto-upgrade channel is `node-image`. In order to be able to change the node OS auto-upgrade channel values, make sure the [cluster auto-upgrade channel][Autoupgrade] isn't `node-image`.
 
 <!-- LINKS -->
 [planned-maintenance]: planned-maintenance.md

articles/aks/faq.md

@@ -103,6 +103,7 @@ AKS supports the following [admission controllers][admission-controllers]:
 - *NamespaceLifecycle*
 - *LimitRanger*
 - *ServiceAccount*
+- *DefaultIngressClass*
 - *DefaultStorageClass*
 - *DefaultTolerationSeconds*
 - *MutatingAdmissionWebhook*

articles/azure-monitor/logs/logs-data-export.md

@@ -33,7 +33,7 @@ Log Analytics workspace data export continuously exports data that's sent to you
 
 ## Limitations
 
-- Custom logs created using the [HTTP Data Collector API](./data-collector-api.md) can't be exported, including text-based logs consumed by Log Analytics agent. Custom logs created using [data collection rules](./logs-ingestion-api-overview.md), including text-based logs can be can be exported. 
+- Custom logs created using the [HTTP Data Collector API](./data-collector-api.md) can't be exported, including text-based logs consumed by Log Analytics agent. Custom logs created using [data collection rules](./logs-ingestion-api-overview.md), including text-based logs, can be exported. 
 - Data export will gradually support more tables, but is currently limited to tables specified in the [supported tables](#supported-tables) section.
 - You can define up to 10 enabled rules in your workspace, each can include multiple tables. You can create more rules in workspace in disabled state. 
 - Destinations must be in the same region as the Log Analytics workspace.

articles/azure-vmware/enable-sql-azure-hybrid-benefit.md

@@ -18,7 +18,7 @@ The placement policy defines the hosts that are running SQL Server as well as th
 
 For example, if each host in Azure VMware Solution has 36 cores and you intend to have 2 hosts run SQL Server then the Azure Hybrid Benefit will apply to 72 cores, regardless of the number of SQL Server instances or other virtual machines are on that host. 
 
-You can also choose to view a video tutorial for configuring Azure Hybrid Benefit for SQL Server in Azure VMware Solution [here](https://www.youtube.com/watch?v=vJIQ1K2KTa0).
+[View a video tutorial for configuring Azure Hybrid Benefit for SQL Server in Azure VMware Solution](https://www.youtube.com/watch?v=vJIQ1K2KTa0)
 
 ## Configure host-VM placement policy 
 

articles/azure-vmware/migrate-sql-server-always-on-cluster.md renamed to articles/azure-vmware/migrate-sql-server-always-on-availability-group.md

@@ -10,7 +10,7 @@ ms.custom: engagement-fy23
 ---
 # Migrate a SQL Server Always On Availability Group to Azure VMware Solution
 
-In this article, you learn how to migrate a Microsoft SQL Server Always On Availability Group  to Azure VMware Solution. For VMware HCX, you can follow the VMware vMotion migration procedure.
+In this article, you learn how to migrate a SQL Server Always On Availability Group  to Azure VMware Solution. For VMware HCX, you can follow the VMware vMotion migration procedure.
 
 :::image type="content" source="media/sql-server-hybrid-benefit/sql-always-on-architecture.png" alt-text="Diagram showing the architecture of Always On SQL Server for  Azure VMware Solution." border="false" lightbox="media/sql-server-hybrid-benefit/sql-always-on-architecture.png":::
 
@@ -19,27 +19,31 @@ In this article, you learn how to migrate a Microsoft SQL Server Always On Avail
 These are the prerequisites to migrating your SQL Server instance to Azure VMware Solution.
 
 - Review and record the storage and network configuration of every node in the cluster.
-- Backup the full database.
-- Backup the virtual machine running the Microsoft SQL Server instance.
+- Maintain backups of all the SQL Server databases.
+- Backup the virtual machine or virtual machines hosting SQL Server.
 - Remove the virtual machine from any VMware vSphere Distributed Resource Scheduler (DRS) groups and rules.
 - VMware HCX must be configured between your on-premises datacenter and the Azure VMware Solution private cloud that runs the migrated workloads. For more information on how to configure HCX, see [Azure VMware Solution documentation](install-vmware-hcx.md).
-- Ensure that all the network segments in use by the Microsoft SQL Server are extended into your Azure VMware Solution private cloud. To verify this step, see [Configure VMware HCX network extension](configure-hcx-network-extension.md).
+- Ensure that all the network segments in use by SQL Server and workloads using it are extended into your Azure VMware Solution private cloud. To verify this step, see [Configure VMware HCX network extension](configure-hcx-network-extension.md).
 
-VMware HCX over VPN is supported in Azure VMware Solution for workload migration. However, due to the size of database workloads, VMware HCX over VPN is not recommended for Microsoft SQL Server Always On migrations for production workloads. ExpressRoute connectivity is recommended as more performant and reliable. For Microsoft SQL Server Standalone and non-production workloads this may be suitable, depending upon the size of the database, to migrate. 
+VMware HCX over VPN is supported in Azure VMware Solution for workload migration.
+However, due to the size of database workloads, VMware HCX over VPN is not recommended for Microsoft SQL Server Always On FCI or AG migrations for production workloads.
+ExpressRoute connectivity is recommended as more performant and reliable. 
+For Microsoft SQL Server standalone and non-production workloads this may be suitable, depending upon the size of the database, to migrate. 
 
 Microsoft SQL Server (2019 and 2022) was tested with Windows Server (2019 and 2022) Data Center edition with the virtual machines deployed in the on-premises environment. Windows Server and SQL Server have been configured following best practices and recommendations from Microsoft and VMware. The on-premises source infrastructure was VMware vSphere 7.0 Update 3 and VMware vSAN running on Dell PowerEdge servers and Intel Optane P4800X SSD NVMe devices.
 
 ## Downtime considerations
 
-Predicting downtime during a migration depends upon the size of the database to be migrated and the speed of the private network connection to Azure cloud. Always On migrations are intended to be executed with low database downtime. However, plan to conduct the migration during off-peak hours within a pre-approved change window.
+Downtime during a migration depends upon the size of the database to be migrated and the speed of the private network connection to Azure cloud.
+While SQL Server Availablity Group migrations can be executed with minimal solution downtime, it is optimal to conduct the migration during off-peak hours within a pre-approved change window.
 
-The table below indicates the estimated downtime for each Microsoft SQL Server topology.
+The table below indicates the estimated downtime for migraton of each SQL Server topology.
 
 | **Scenario** | **Downtime expected** | **Notes** |
 |:---|:-----|:-----|
-| **Standalone instance** | Low | Migrate with VMware vMotion, the DB is available during migration, but it is not recommended to commit any critical data during it. |
+| **Standalone instance** | Low | Migrate with VMware vMotion, the database is available during migration, but it is not recommended to commit any critical data during it. |
 | **Always On Availability Group** | Low | The primary replica will always be available during the migration of the first secondary replica and the secondary replica will become the primary after the initial failover to Azure. |
-| **Failover Cluster Instance** | High | All nodes of the cluster are shutdown and migrated using VMware HCX Cold Migration. Downtime duration depends upon database size and private network speed to Azure cloud. |
+| **Always On     Failover Cluster Instance** | High | All nodes of the cluster are shutdown and migrated using VMware HCX Cold Migration. Downtime duration depends upon database size and private network speed to Azure cloud. |
 
 ## Windows Server Failover Cluster quorum considerations
 
@@ -74,7 +78,7 @@ For details about configuring and managing the quorum, see [Failover Clustering
 1. Access the on-premises vCenter Server and proceed to HCX area.
 1. Under **Services** select **Migration** > **Migrate**. 
    - Select one virtual machine running the secondary replica of the database the is going to be migrated.
-   - Set the vSphere cluster in the remote private cloud to run the migrated SQL Server cluster as the **Compute Container**.
+   - Set the vSphere cluster in the remote private cloud, which will now host the migrated SQL Server VM or VMs as the **Compute Container**.
    - Select the **vSAN Datastore** as remote storage.
    - Select a folder. This not mandatory, but is recommended to separate the different workloads in your Azure VMware Solution private cloud.
    - Keep **Same format as source**.

articles/azure-vmware/migrate-sql-server-failover-cluster.md

@@ -11,7 +11,7 @@ ms.custom: engagement-fy23
 
 #  Migrate a SQL Server Always On Failover Cluster Instance to Azure VMware Solution
 
-In this article, you'll learn how to migrate a Microsoft SQL Server Failover Cluster Instance to Azure VMware Solution.
+In this article, you'll learn how to migrate a SQL Server Failover Cluster Instance to Azure VMware Solution.
 Currently Azure VMware Solution service doesn't support VMware Hybrid Linked Mode to connect an on-premises vCenter Server with one running in Azure VMware Solution.
 Due to this constraint, this process requires the use of VMware HCX for the migration.
 For more details about configuring HCX, see [Install and activate VMware HCX in Azure VMware Solution](install-vmware-hcx.md).
@@ -22,17 +22,17 @@ However, you can overcome this limitation by performing the steps shown in this
 :::image type="content" source="media/sql-server-hybrid-benefit/migrated-sql-failover-cluster.png" alt-text="Diagram showing the architecture of SQL Server Failover for Azure VMware Solution." border="false" lightbox="media/sql-server-hybrid-benefit/migrated-sql-failover-cluster.png":::
 
 > [!NOTE]
-> This procedure requires a full shutdown of the cluster. Since the Microsoft SQL Server service will be unavailable during the migration, plan accordingly for the downtime period.  
+> This procedure requires a full shutdown of the cluster. Since the SQL Server service will be unavailable during the migration, plan accordingly for the downtime period.  
 
 ## Prerequisites
 
 - Review and record the storage and network configuration of every node in the cluster.
 - Review and record the WSFC configuration.
-- Back up the database or databases being executed in the cluster.
+- Maintain backups of all the SQL Server databases.
 - Back up the cluster virtual machines.
 - Remove all cluster node VMs from any Distributed Resource Scheduler (DRS) groups and rules they're part of.
 - VMware HCX must be configured between your on-premises datacenter and the Azure VMware Solution private cloud that runs the migrated workloads. For more details about installing VMware HCX, see [Azure VMware Solution documentation](install-vmware-hcx.md).
-- Ensure that all the network segments in use by the Microsoft SQL Server are extended into your Azure VMware Solution private cloud. To verify this step, see [Configure VMware HCX network extension](configure-hcx-network-extension.md).
+- Ensure that all the network segments in use by SQL Server and workloads using it are extended into your Azure VMware Solution private cloud. To verify this step, see [Configure VMware HCX network extension](configure-hcx-network-extension.md).
 
 VMware HCX over VPN is supported in Azure VMware Solution for workload migration.
 However, due to the size of database workloads it isn't recommended for Microsoft SQL Server Failover Cluster Instance and Microsoft SQL Server Always On migrations, especially for production workloads.
@@ -52,9 +52,9 @@ The table below indicates the downtime for each Microsoft SQL Server topology.
 
 | **Scenario** | **Downtime expected** | **Notes** |
 |:---|:-----|:-----|
-| **Standalone instance** | Low | Migration will be done using vMotion, the DB will be available during migration time, but it isn't recommended to commit any critical data during it. |
-| **Always-On Availability Group** | Low | The primary replica will always be available during the migration of the first secondary replica and the secondary replica will become the primary after the initial failover to Azure. |
-| **Failover Cluster Instance** | High | All nodes of the cluster will be shut down and migrated using VMware HCX Cold Migration. Downtime duration will depend upon database size and private network speed to Azure cloud. |
+| **Standalone instance** | Low | Migration will be done using vMotion, the database will be available during migration time, but it isn't recommended to commit any critical data during it. |
+| **Always-On SQL Server Availability Group** | Low | The primary replica will always be available during the migration of the first secondary replica and the secondary replica will become the primary after the initial failover to Azure. |
+| **Always On SQL Server Failover Cluster Instance** | High | All nodes of the cluster will be shut down and migrated using VMware HCX Cold Migration. Downtime duration will depend upon database size and private network speed to Azure cloud. |
 
 ## Windows Server Failover Cluster quorum considerations
 
@@ -101,7 +101,7 @@ For illustration purposes, in this document we're using a two-node cluster with
 
 1. From the **vSphere Client**, go to the HCX plugin area. Under **Services**, select **Migration** > **Migrate**. 
    - Select the second node virtual machine.
-   - Set the vSphere cluster in the remote private cloud that will run the migrated SQL cluster as the **Compute Container**.
+   - Set the vSphere cluster in the remote private cloud, which will now host the migrated SQL Server VM or VMs, as the **Compute Container**.
    - Select the **vSAN Datastore** as remote storage.
    - Select a folder if you want to place the virtual machines in specific folder, this not mandatory but is recommended to separate the different workloads in your Azure VMware Solution private cloud.
    - Keep **Same format as source**.
@@ -130,13 +130,13 @@ For illustration purposes, in this document we're using a two-node cluster with
    - In the **Failover Cluster Manager** review that the second node appears as **Online** status.
     :::image type="content" source="media/sql-server-hybrid-benefit/sql-failover-4.png"  alt-text="Diagram showing a cluster node status in Failover Cluster Manager." border="false" lightbox="media/sql-server-hybrid-benefit/sql-failover-4.png":::
 
-1. Using the **SQL Server Management Studio** connect to the SQL Server cluster resource network name. Check the database is online and accessible.
+1. Using the **SQL Server Management Studio** connect to the SQL Server cluster resource network name. Confirm all databases are online and accessible.
 
 :::image type="content" source="media/sql-server-hybrid-benefit/sql-failover-5.png" alt-text="Diagram showing a verification of SQL Server Management Studio connection  to the migrated cluster instance database." border="false" lightbox="media/sql-server-hybrid-benefit/sql-failover-5.png":::
 
-Finally, check the connectivity to SQL Server from other systems and applications in your infrastructure and verify that all applications using the database(s) can still access them. 
+Finally, check the connectivity to SQL Server from other systems and applications in your infrastructure and verify that all applications using the database or databases can still access them. 
 
-## Next steps
+## More information
 
 - [Enable Azure Hybrid Benefit for SQL Server in Azure VMware Solution](enable-sql-azure-hybrid-benefit.md). 
 - [Create a placement policy in Azure VMware Solution](create-placement-policy.md)