Adding references to VMware to support the upcoming VMware agent release

Author: stevenmatthew

articles/storage-mover/agent-deploy.md

@@ -19,7 +19,7 @@ REVIEW Engineering: not reviewed
 EDIT PASS: started
 
 Initial doc score: 83
-Current doc score: 96 (2038 words and 10 false-positive issues)
+Current doc score: 96 (2093 words and 10 false-positive issues)
 
 !########################################################
 -->
@@ -43,17 +43,17 @@ This article guides you through the steps necessary to successfully deploy a Sto
 
 ## Determine required resources for the VM
 
-Like every VM, the agent requires available compute, memory, network, and storage space resources on the host. Although overall data size may affect the time required to complete a migration, it's generally the number of files and folders that drives resource requirements.
+Like every VM, the agent requires available compute, memory, network, and storage space resources on the host. Although overall data size might affect the time required to complete a migration, it's generally the number of files and folders that drives resource requirements.
 
 ### Network resources
 
 The agent requires unrestricted internet connectivity.
 
-Although no single network configuration option works for every environment, the simplest configuration involves the deployment of an external virtual switch. The external switch type is connected to a physical adapter and allows your host operating system (OS) to share its connection with all your virtual machines (VMs). This switch allows communication between your physical network, the management operating system, and the virtual adapters on your virtual machines. This approach may be acceptable for a test environment, but is likely not sufficient for a production server.
+Although no single network configuration option works for every environment, the simplest configuration involves the deployment of an external virtual switch. The external switch type is connected to a physical adapter and allows your host operating system (OS) to share its connection with all your virtual machines (VMs). This switch allows communication between your physical network, the management operating system, and the virtual adapters on your virtual machines. This approach might be acceptable for a test environment, but is likely not sufficient for a production server.
 
 After the switch is created, ensure that both the management and agent VMs are on the same switch. On the WAN link firewall, outbound TCP port 443 must be open. Keep in mind that connectivity interruptions are to be expected when changing network configurations.
 
-You can get help with [creating a virtual switch for Hyper-V virtual machines](/windows-server/virtualization/hyper-v/get-started/create-a-virtual-switch-for-hyper-v-virtual-machines) in the [Windows Server](/windows-server/) documentation.
+You can get help with [creating a virtual switch for Hyper-V virtual machines](/windows-server/virtualization/hyper-v/get-started/create-a-virtual-switch-for-hyper-v-virtual-machines) in the [Windows Server](/windows-server/) documentation. Consult the VMware support website for detailed guidance on creating a virtual switch for VMware-hosted VMs.
 
 ### Recommended compute and memory resources
 
@@ -74,14 +74,16 @@ The [Performance targets](performance-targets.md) article contains test results
 
 ### Local storage capacity
 
-At a minimum, the agent image needs 20 GiB of local storage. The amount required may increase if a large number of small files are cached during a migration.
+At a minimum, the agent image needs 20 GiB of local storage. The amount required might increase if a large number of small files are cached during a migration.
 
 ## Download the agent VM image
 
-The image is hosted on Microsoft Download Center as a zip file. Download the file at [https://aka.ms/StorageMover/agent](https://aka.ms/StorageMover/agent) and extract the agent virtual hard disk (VHD) image to your virtualization host.
+Images for agent VMs are hosted on Microsoft Download Center as a zip file. Download the file at [https://aka.ms/StorageMover/agent](https://aka.ms/StorageMover/agent) and extract the agent virtual hard disk (VHD) image to your virtualization host.
 
 ## Create the agent VM
 
+The following steps describe the process for creating a VM using Microsoft Hyper-V. Consult the VMware support website for detailed guidance on creating a VMware-based VM.
+
 1. Create a new VM to host the agent. Open **Hyper-V Manager**. In the **Actions** pane, select **New** and **Virtual Machine...** to launch the **New Virtual Machine Wizard**.
 
    :::image type="content" source="media/agent-deploy/agent-vm-create-sml.png" alt-text="Image showing how to launch the New Virtual Machine Wizard from within the Hyper-V Manager." lightbox="media/agent-deploy/agent-vm-create-lrg.png":::
@@ -119,7 +121,7 @@ The image is hosted on Microsoft Download Center as a zip file. Download the fil
 
 ## Change the default password
 
-The agent is delivered with a default user account and password. Immediately after deploying and starting the agent VM, connect to it and change the default password!
+The agent is delivered with a default user account and password. Connect to the newly created agent and change the default password immediately after the agent is deployed and started.
 
 [!INCLUDE [agent-shell-connect](includes/agent-shell-connect.md)]
 
@@ -130,7 +132,7 @@ Take time to consider the amount of bandwidth a new machine uses before you depl
 > [!IMPORTANT]
 > The current Azure Storage Mover agent does not support bandwidth throttling schedules.
 
-If bandwidth throttling is important to you, create a local virtual network (VNet) with network quality of service (QoS) settings and an internet connection. This approach allows you to expose the agent through the VNet, and to locally configure an unauthenticated network proxy server on the agent if needed.
+If bandwidth throttling is important to you, create a local virtual network with an internet connection and configure quality of service (QoS) settings. This approach allows you to expose the agent through the virtual network and to locally configure an unauthenticated network proxy server on the agent if needed.
 
 ## Decommissioning an agent
 
@@ -196,7 +198,7 @@ Several things take place during the unregistration process:
 
 - The agent is removed from the storage mover resource. You can no longer see the agent in the *Registered agents* tab in the portal or select it for new migration jobs.
 - The agent is also removed from the Azure ARC service. This removal deletes the hybrid compute resource of type *Server - Azure Arc* that represented the agent with the Azure ARC service in the same resource group as your storage mover resource.
-- Unregistration removes the managed identity of the agent from Microsoft Entra ID. The associated service principal is automatically removed, invalidating any permissions this agent may have had on other Azure resources. If you check the role-based access control (RBAC) role assignments, for instance of a target storage container the agent previously had permissions to, you no longer find the service principal of the agent, because it was deleted. The assignment itself is still visible as "Unknown service principal" but this assignment no longer connects to an identity and can never be reconnected. It's simply a sign that a role assignment used to be here, of a service principal that no longer exists.
+- Unregistration removes the managed identity of the agent from Microsoft Entra ID. The associated service principal is automatically removed, invalidating any permissions this agent might have on other Azure resources. If you check the role-based access control (RBAC) role assignments, for instance of a target storage container the agent previously had permissions to, you no longer find the service principal of the agent, because it was deleted. The assignment itself is still visible as "Unknown service principal" but this assignment no longer connects to an identity and can never be reconnected. It's simply a sign that a role assignment used to be here, of a service principal that no longer exists.
 
   This behavior is standard, and not specific to Azure Storage Mover. You can observe the same behavior if you remove a different service principal from Microsoft Entra ID and then check a former role assignment.
 
@@ -211,6 +213,6 @@ You can stop the agent VM on your virtualization host after the unregistration i
 
 ## Next steps
 
-After you've deployed your agent VM, started it, and changed the default password of the local account:
+After you deploy your agent, started it, and changed the default password of the local account:
 > [!div class="nextstepaction"]
 > [Register the agent with your storage mover Azure resource](agent-register.md)