Merge pull request #244848 from stevenmatthew/agent-update

agent-update: updated agent-deploy for SMB public preview

Author: prmerger-automator[bot]

articles/storage-mover/agent-deploy.md

@@ -5,7 +5,7 @@ author: stevenmatthew
 ms.author: shaas
 ms.service: azure-storage-mover
 ms.topic: how-to
-ms.date: 03/27/2023
+ms.date: 07/25/2023
 ---
 
 <!-- 
@@ -19,32 +19,28 @@ REVIEW Engineering: not reviewed
 EDIT PASS: started
 
 Initial doc score: 83
-Current doc score: 96 (2026 words and 10 false-positive issues)
+Current doc score: 96 (2038 words and 10 false-positive issues)
 
 !########################################################
 -->
 
 # Deploy an Azure Storage Mover agent
 
-The Azure Storage Mover service utilizes agents to perform the migration jobs you configure in the service. An agent is a virtual machine-based migration appliance that runs on a virtualization host. Ideally, your virtualization host is located as near as possible to the source storage to be migrated.
+The Azure Storage Mover service utilizes agents to perform the migration jobs you configure in the service. An agent is a virtual machine-based migration appliance that runs on a virtualization host. Ideally, your virtualization host is located as near as possible to the source storage to be migrated. Storage Mover can support multiple agents.
 
-Because the agent is essentially a migration appliance, you interact with it through an agent-local administrative shell. The shell limits the operations you can perform on this machine, though network configuration and troubleshooting tasks are accessible.
+Because an agent is essentially a migration appliance, you interact with it through an agent-local administrative shell. The shell limits the operations you can perform on this machine, though network configuration and troubleshooting tasks are accessible.
 
 Use of the agent in migrations is managed through Azure. Both Azure PowerShell and CLI are supported, and graphical interaction is available within the Azure portal. The agent is made available as a disk image compatible with new Windows Hyper-V virtual machines (VM).
 
 This article guides you through the steps necessary to successfully deploy a Storage Mover agent VM.
 
 ## Prerequisites
 
-- A capable Windows Hyper-V host on which to run the agent VM. See the [Recommended compute and memory resources](#recommended-compute-and-memory-resources) section in this article for details about resource requirements for the agent VM.
+- A capable Windows Hyper-V host on which to run the agent VM.<br/> See the [Recommended compute and memory resources](#recommended-compute-and-memory-resources) section in this article for details about resource requirements for the agent VM.
 
 > [!NOTE]
 > At present, Windows Hyper-V is the only supported virtualization environment for your agent VM. Other virtualization environments have not been tested and are not supported.
 
-## 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.
-
 ## 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.
@@ -53,7 +49,7 @@ Like every VM, the agent requires available compute, memory, network, and storag
 
 The agent requires unrestricted internet connectivity.
 
-There's no single network configuration option that works for every environment. However, 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 is fine for a test environment, but may not be suitable 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 may 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.
 
@@ -72,14 +68,18 @@ You can get help with [creating a virtual switch for Hyper-V virtual machines](/
 **Number of items** *refers to the total number of files and folders in the source.*
 
 > [!IMPORTANT]
-> While agent VMs below minimal specs may work for your migration, they may not perform optimally.
+> While agent VMs below minimal specs may work for your migration, they may not perform optimally and are not supported.
 
 The [Performance targets](performance-targets.md) article contains test results from different source namespaces and VM resources.
 
 ### 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.
 
+## 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.
+
 ## Create the agent 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**.
@@ -125,20 +125,19 @@ The agent is delivered with a default user account and password. Immediately aft
 
 ## Bandwidth throttling
 
-A general consideration when deploying new machines in a network is the amount of bandwidth they use. Any Azure Storage Mover agent uses all available network bandwidth on the local network (source share to agent) and the WAN link (agent to Azure Storage).
+Take time to consider the amount of bandwidth a new machine uses before you deploy it to your network. An Azure Storage Mover agent communicates with a source share using the local network, and the Azure Storage service on the wide area network (WAN) link. In both cases, the agent uses all available network bandwidth.
 
 > [!IMPORTANT]
 > The current Azure Storage Mover agent does not support bandwidth throttling schedules.
 
-If bandwidth throttling is important to you, consider creating a local virtual network (VNet) with network quality of service (QoS) settings and an internet connection. Then expose the agent to the internet through this VNet. An unauthenticated network proxy server can also be configured locally on the agent.
+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.
 
 ## Decommissioning an agent
 
-When you no longer need a specific storage mover agent, you can decommission it.
-During public review, decommissioning is a two-step process:
+When you no longer need a specific storage mover agent, you can decommission it. Decommissioning is a two-step process:
 
-1. The agent needs to be unregistered from the storage mover resource.
-1. Stop and delete the agent VM on your virtualization host.
+1. Unregister the agent from the storage mover resource.
+1. Stop the agent VM on your virtualization host and then delete it.
 
 Decommissioning an agent starts with unregistering the agent. There are three options to start the unregistration process:
 
@@ -153,9 +152,9 @@ You can unregister an agent using the administrative shell of the agent VM. The
 2) Network configuration
 3) Service and job status
 4) Unregister
-5) Open restricted shell
-6) Collect support bundle
-7) Restart agent
+5) Collect support bundle
+6) Restart agent
+7) Disk Cleanup
 8) Exit
 
 xdmsh> 4

articles/storage-mover/includes/agent-shell-connect.md

@@ -27,6 +27,3 @@ ssh <AgentIpAddress> -l admin
 > A newly deployed Storage Mover agent has a default password: </br>**Local user:** admin </br>**Default password:** admin
 
 You're prompted and advised to change the default password immediately after you first connect to a newly deployed agent. Note down the new password, there's no process to recover it. Losing your password locks you out from the administrative shell. Cloud management doesn't require this local admin password. If the agent was previously registered, you can still use it for migration jobs. Agents are disposable. They hold little value beyond the current migration job they're executing. You can always deploy a new agent and use that instead to run the next migration job.
-
-> [!NOTE]
-> Losing the local account password during public preview precludes you from accessing your detailed copy logs.