Merge pull request #310422 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-13 12:00 UTC

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

articles/logic-apps/connectors/dataverse.md

@@ -92,6 +92,7 @@ The table summarizes agentless migration requirements for VMware vSphere VMs.
 **iSCSI targets** | VMs with iSCSI targets aren't supported for agentless migration.
 **Multipath IO** | Not supported.
 **Storage vMotion** | Supported. 
+**VMware Cloud Director's Fast Provisioning** | Not supported.
 **Teamed NICs** | Not supported.
 **IPv6** | Not supported.
 **NVMe disks** | Not supported.

articles/migrate/migrate-support-matrix-vmware-migration.md

@@ -43,7 +43,7 @@ Before you start this tutorial, check you have these prerequisites in place.
 
 **Requirement** | **Details**
 --- | ---
-**Hyper-V host** | Hyper-V hosts on which servers are located can be standalone, or in a cluster.<br/><br/> The host must be running Windows Server 2022, Windows Server 2019, or Windows Server 2016.<br/><br/> Verify inbound connections are allowed on WinRM port 5985 (HTTP), so that the appliance can connect to pull server metadata and performance data, using a Common Information Model (CIM) session.
+**Hyper-V host** | Hyper-V hosts on which servers are located can be standalone, or in a cluster.<br/><br/> The host must be running Windows Server 2025, Windows Server 2022, Windows Server 2019, or Windows Server 2016.<br/><br/> Verify inbound connections are allowed on WinRM port 5985 (HTTP), so that the appliance can connect to pull server metadata and performance data, using a Common Information Model (CIM) session.
 **Appliance deployment** | Hyper-V host needs resources to allocate a server for the appliance:<br/><br/> - 16 GB of RAM, 8 vCPUs, and around 80 GB of disk storage.<br/><br/> - An external virtual switch, and internet access on the appliance, directly or via a proxy.
 **Servers** | All Windows and Linux OS versions are supported for discovery of configuration and performance metadata. <br /><br /> For application discovery on servers, all Windows and Linux OS versions are supported. Check the [OS versions supported for agentless dependency analysis](migrate-support-matrix-hyper-v.md#dependency-analysis-requirements-agentless).<br /><br /> To discover ASP.NET web apps running on IIS web server, check [supported Windows OS and IIS versions](migrate-support-matrix-vmware.md#web-apps-discovery-requirements). For discovery of installed applications and for agentless dependency analysis, Windows servers must have PowerShell version 2.0 or later installed.<br /><br />  To discover Java web apps running on Apache Tomcat web server, check [supported Linux OS and Tomcat versions](migrate-support-matrix-vmware.md#web-apps-discovery-requirements). 
 **SQL Server access** | To discover SQL Server instances and databases, the Windows or SQL Server account [requires these permissions](migrate-support-matrix-hyper-v.md#configure-the-custom-login-for-sql-server-discovery) for each SQL Server instance. You can use the [account provisioning utility](least-privilege-credentials.md) to create custom accounts or use any existing account that is a member of the sysadmin server role for simplicity.

articles/migrate/tutorial-discover-hyper-v.md

@@ -4,21 +4,21 @@ description: Azure PowerShell Script Sample - Learn how to create multiple Elast
 author: roygara
 ms.service: azure-elastic-san-storage
 ms.topic: sample
-ms.date: 05/31/2024
+ms.date: 01/09/2026
 ms.author: rogarana
 ms.custom: devx-track-azurepowershell
 # Customer intent: "As a cloud architect, I want to create multiple Elastic SAN volumes in a batch using a CSV file, so that I can streamline the volume provisioning process and improve efficiency in managing storage resources."
 ---
 
 # Create multiple elastic SAN volumes in a batch
 
-To simplify creating multiple volumes as a batch, you can use a .csv with pre-filled values to create as many volumes of varying sizes as you like.
+The PowerShell script in this article simplifies creating multiple Azure Elastic SAN volumes as a batch. To use the script, make a .csv file with pre-filled values to create as many volumes of varying sizes as you want.
 
-Format your .csv with five columns, **ResourceGroupName**, **ElasticSanName**, **VolumeGroupName**, **Name**, and **SizeGiB**. The following screenshot provides an example:
+Format your .csv file with five columns: **ResourceGroupName**, **ElasticSanName**, **VolumeGroupName**, **Name**, and **SizeGiB**. The following screenshot provides an example:
 
 :::image type="content" source="media/elastic-san-batch-create-sample/batch-elastic-san.png" alt-text="Screenshot of an example csv file, with example column names and values." lightbox="media/elastic-san-batch-create-sample/batch-elastic-san.png":::
 
-Then you can use the following script to create your volumes.
+Then, use the following script to create your volumes.
 
 ```azurepowershell
 $filePath = "D:\ElasticSan\TestCsv3.csv" 

articles/storage/elastic-san/elastic-san-batch-create-sample.md

@@ -1,48 +1,48 @@
 ---
-title: Best practices for configuring an Elastic SAN
-description: Learn about the best practices for getting optimal performance when configuring an Azure Elastic SAN.
+title: Azure Elastic SAN configuration best practices
+description: Learn best practices for optimizing Azure Elastic SAN performance. Get recommendations for client-side settings, MPIO, iSCSI configurations, and deployment sizing
 author: roygara
 ms.service: azure-elastic-san-storage
 ms.topic: concept-article
-ms.date: 11/17/2025
+ms.date: 01/09/2026
 ms.author: rogarana
 ms.custom: sfi-image-nochange
 # Customer intent: As a cloud infrastructure administrator, I want to implement best practices for configuring an Elastic SAN, so that I can achieve optimal performance and resource efficiency for my storage solutions in a cloud environment.
 ---
 
 # Optimize the performance of your Elastic SAN
 
-This article provides some general guidance on getting optimal performance with an environment that uses an Azure Elastic SAN.
+This article provides guidance on how to get optimal performance with an environment that uses an Azure Elastic SAN.
 
 ## Client-side optimizations
 
 ### General recommendations
 
-#### Windows & Linux Virtual Machines
+#### Windows and Linux virtual machines
 
-- For best performance, deploy your virtual machines (VM) and Elastic SAN in the same zone and the same region.
+- For the best performance, deploy your virtual machines (VMs) and Elastic SAN in the same zone and the same region.
 
-- VM storage I/O to Elastic SAN volumes uses VM network bandwidth, so traditional disk throughput limits on a VM don't apply to Elastic SAN volumes. Choose a VM that can provide sufficient bandwidth for production/VM-to-VM I/O and iSCSI I/O to attached Elastic SAN volumes. Generally, you should use Gen 5 (D / E / M series) VMs for the best performance.
+- VM storage I/O to Elastic SAN volumes uses VM network bandwidth, so traditional disk throughput limits on a VM don't apply to Elastic SAN volumes. Choose a VM that can provide sufficient bandwidth for production/VM-to-VM I/O and iSCSI I/O to attached Elastic SAN volumes. Generally, you should use Gen 5 (D, E, or M series) VMs for the best performance.
 
-- Enable **Accelerated Networking** on the VM during creation. To do it via Azure PowerShell or Azure CLI or to enable Accelerated Networking on existing VMs, see [Use Azure PowerShell to create a VM with Accelerated Networking](../../virtual-network/create-vm-accelerated-networking-powershell.md)
+- Enable **Accelerated Networking** on the VM during creation. To learn how to enable it by using Azure PowerShell or Azure CLI, or to enable Accelerated Networking on existing VMs, see [Use Azure PowerShell to create a VM with Accelerated Networking](../../virtual-network/create-vm-accelerated-networking-powershell.md).
 
 :::image type="content" source="media/elastic-san-best-practices/enable-accelerated-networking.png" alt-text="Screenshot of VM creation flow, enable accelerated networking highlighted." lightbox="media/elastic-san-best-practices/enable-accelerated-networking.png":::
 
-- You must use 32 sessions per target volume for each volume to achieve its maximum IOPS and/or throughput limits. Use Multipath I/O (MPIO) on the client to manage these multiple sessions to each volume for load balancing. Scripts are available for [Windows](elastic-san-connect-windows.md), [Linux](elastic-san-connect-linux.md), or on the Connect to volume page for your volumes in the Azure portal, which uses 32 sessions by default. Windows software iSCSI initiator has a limit of maximum 256 sessions. If you need to connect more than eight volumes to a Windows VM, reduce the number of sessions to each volume as needed. 
+- To achieve maximum IOPS and throughput limits, use 32 sessions per target volume for each volume. Use Multipath I/O (MPIO) on the client to manage these multiple sessions to each volume for load balancing. Scripts are available for [Windows](elastic-san-connect-windows.md), [Linux](elastic-san-connect-linux.md), or on the Connect to volume page for your volumes in the Azure portal, which uses 32 sessions by default. Windows software iSCSI initiator has a limit of maximum 256 sessions. If you need to connect more than eight volumes to a Windows VM, reduce the number of sessions to each volume as needed. 
 
 #### Azure VMware Solution
 
 - Deploy your Elastic SAN in the same region and availability zone as your Azure VMware Solution cluster
 -  Configure Private Endpoints before mounting your Elastic SAN volume as an external datastore
-- If you plan for your environment to ever have 16 nodes in an Azure VMware Solution cluster, use one of the following configurations, depending on which hosts you have.
+- If you plan for your environment to ever have 16 nodes in an Azure VMware Solution cluster, use one of the following configurations, depending on which hosts you have:
     - AV36, AV36P, AV52 - Six iSCSI sessions over three Private Endpoints
     - AV64 - Seven iSCSI sessions over seven Private Endpoints
-- If your environment won't have 16 nodes, use one of the following configurations.
+- If your environment won't have 16 nodes, use one of the following configurations:
     -  AV36, AV36P, AV52 - Eight iSCSI sessions over four Private Endpoints
     - AV64 - Eight iSCSI sessions over eight Private Endpoints
 
     > [!NOTE]
-    > When an Elastic SAN volume is attached to a cluster, it automatically attaches to all nodes. If you have 16 nodes and each node is configured to use eight iSCSI sessions that uses the maximum number of connections (128). Configuring your nodes to use seven iSCSI sessions ensures that if you need to attach an extra node (for maintenance) then you have available iSCSI sessions. 
+    > When an Elastic SAN volume is attached to a cluster, it automatically attaches to all nodes. If you have 16 nodes and each node is configured to use eight iSCSI sessions, the configuration uses the maximum number of connections (128). Configuring your nodes to use seven iSCSI sessions ensures that if you need to attach an extra node (for maintenance) then you have available iSCSI sessions. 
 
 - Use eager zeroed thick provisioning when creating virtual disks
 - Size ExpressRoute Gateway so that it can meet your throughput requirements
@@ -64,11 +64,11 @@ mpclaim -L -M 2
 Set-MPIOSetting -NewDiskTimeout 30
 ```
 
-For more information regarding MPIO cmdlets, see [MPIO reference](/powershell/module/mpio/).
+For more information about MPIO cmdlets, see [MPIO reference](/powershell/module/mpio/).
 
 #### Linux
 
-Update /etc/multipath.conf file with the following commands: 
+Update the /etc/multipath.conf file by using the following commands: 
 
 ```config
 defaults {
@@ -100,10 +100,10 @@ Microsoft manages MPIO settings for Azure VMware Solution. Optimal values are se
 Update the registry settings for iSCSI initiator on Windows.
 
 1.	Open Registry Editor:
-1. Select Start, type regedit in the search box and press enter.
+1. Select **Start**, type `regedit` in the search box, and press **Enter**.
 1.	Navigate to the following location:
     [\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\\{4d36e97b-e325-11ce-bfc1-08002be10318}\0004 (Microsoft iSCSI Initiator)\Parameters]
-1.	Update the following settings. Right-click on each setting and select **Modify**. Change **Base** to **Decimal**, update the value and select **OK**.
+1.	Update the following settings. Right-click on each setting and select **Modify**. Change **Base** to **Decimal**, update the value, and select **OK**.
 
 |Description  |Parameter and value  |
 |---------|---------|
@@ -116,23 +116,24 @@ Update the registry settings for iSCSI initiator on Windows.
 |Sets timeout value for WMI requests to 30 seconds     |WMIRequestTimeout = 30 seconds         |
 |Sets timeout value for link down time to 30 seconds     |LinkDownTime = 30 seconds         |
 
-**Note**: After updating registry settings for optimal performance, you must restart the VM for the changes to take effect. If the VM is not restarted, you will continue to use the default settings.
+> [!NOTE]
+> After updating registry settings for optimal performance, you must restart the VM for the changes to take effect. If you don't restart the VM, you will continue to use the default settings.
 
-In cluster configurations, ensure iSCSI initiator names unique across all nodes that are sharing volumes. In Windows, you can update them via iSCSI Initiator app.
+In cluster configurations, ensure iSCSI initiator names are unique across all nodes that are sharing volumes. In Windows, you can update them via the iSCSI Initiator app.
 
-1.	Select **Start**, search for **iSCSI Initiator** in the search box. This opens the iSCSI Initiator.
-1.	Select **Configuration** to see current initiator name.
+1.	Select **Start**, search for **iSCSI Initiator** in the search box. This action opens the iSCSI Initiator.
+1.	Select **Configuration** to see the current initiator name.
 
     :::image type="content" source="media/elastic-san-best-practices/iscsi-initiator-config-widnows.png" alt-text="Screenshot of iSCSI Initiator configuration on Windows." lightbox="media/elastic-san-best-practices/iscsi-initiator-config-widnows.png"::: 
 
-1.	To modify it, select **Change**, enter new initiator name, and select OK.
+1.	To modify it, select **Change**, enter new initiator name, and select **OK**.
 
     :::image type="content" source="media/elastic-san-best-practices/update-iscsi-initiator-name-windows.png" alt-text="Screenshot of updating the iSCSI Initiator Name on Windows." lightbox="media/elastic-san-best-practices/update-iscsi-initiator-name-windows.png"::: 
 
 
 #### Linux
 
-Update the following settings with recommended values in global iSCSI configuration file (iscsid.conf, generally found in /etc/iscsi directory) on the client before connecting any volumes to it. When a volume is connected, a node is created along with a configuration file specific to that node (for example on Ubuntu VMs, it can be found in the `/etc/iscsi/nodes/$volume_iqn/portal_hostname,$port` directory) inheriting the settings from global configuration file. If you already connected one or more volumes to the client before updating global configuration file, update the node specific configuration file for each volume directly or using the following command:
+Update the following settings with recommended values in the global iSCSI configuration file (`iscsid.conf`, generally found in the `/etc/iscsi` directory) on the client before connecting any volumes to it. When you connect a volume, a node is created along with a configuration file specific to that node. For example, on Ubuntu VMs, you can find it in the `/etc/iscsi/nodes/$volume_iqn/portal_hostname,$port` directory. This configuration file inherits the settings from the global configuration file. If you already connected one or more volumes to the client before updating the global configuration file, update the node-specific configuration file for each volume directly or use the following command:
 
 ```
 # Variable declaration
@@ -167,9 +168,10 @@ sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node
 sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.DataDigest -v CRC32C 
 
 ```
-**Note**: After updating iSCSI configuration files, restart the VM to ensure the new settings are applied.
+> [!NOTE]
+> After updating iSCSI configuration files, restart the VM to ensure the new settings are applied.
 
-In cluster configurations, ensure iSCSI initiator names are unique across all nodes that are sharing volumes. In Linux, modify /etc/iscsi/initiatorname.iscsi to update the initiator name.
+In cluster configurations, ensure iSCSI initiator names are unique across all nodes that are sharing volumes. In Linux, modify `/etc/iscsi/initiatorname.iscsi` to update the initiator name.
 :::image type="content" source="media/elastic-san-best-practices/update-iscsi-initiator-name-linux.png" alt-text="Screenshot updating the iSCSI Initiator Name on Linux." lightbox="media/elastic-san-best-practices/update-iscsi-initiator-name-linux.png"::: 
 
 #### Azure VMware Solution
@@ -178,8 +180,8 @@ Microsoft manages iSCSI settings. Optimal values are set when you create a datas
 
 ## Elastic SAN optimizations
 
-Before deploying an Elastic SAN, determining the optimal size of the Elastic SAN you deploy is necessary to achieving the right balance of performance for your workloads and cost. Use the following steps to determine the best sizing for you:
+Before deploying an Elastic SAN, determine the optimal size for your deployment to achieve the right balance of performance for your workloads and cost. Use the following steps to determine the best sizing for you:
 
-With your existing storage solution, select a time interval (day/week/quarter) to track performance. The best time interval is one that is a good snapshot of your applications/workloads. Over that time period, record the combined maximum IOPS and throughput for all workloads. If you use an interval higher than a minute, or if any of your workloads have bottlenecks with your current configuration, consider adding more base capacity to your Elastic SAN deployment. You should leave some headroom when determining your base capacity, to account for growth. The rest of your Elastic SAN's storage should use additional-capacity, to save on cost.
+With your existing storage solution, select a time interval (day, week, or quarter) to track performance. The best time interval is one that provides a good snapshot of your applications and workloads. Over that time period, record the combined maximum IOPS and throughput for all workloads. If you use an interval higher than a minute, or if any of your workloads have bottlenecks with your current configuration, consider adding more base capacity to your Elastic SAN deployment. Leave some extra capacity when determining your base capacity to account for growth. Use additional-capacity storage for the rest of your Elastic SAN to save on cost.
 
 For more information on performance, see [Elastic SAN and virtual machine performance](elastic-san-performance.md).