Merge pull request #285143 from ankitaduttaMSFT/tsts

TS docs

Author: ttorble

articles/site-recovery/azure-to-azure-troubleshoot-replication.md

@@ -33,7 +33,7 @@ You should see the event **Data change rate beyond supported limits**:
 
 If you select the event, you should see the exact disk information:
 
-:::image type="content" source="./media/site-recovery-azure-to-azure-troubleshoot/data_change_event2.png" alt-text="Page that shows the data change rate event details.":::
+ 
 
 ### Azure Site Recovery limits
 

articles/site-recovery/media/vmware-troubleshoot-appliance-health-issue/appliance-health.png

@@ -585,6 +585,10 @@
       href: vmware-azure-troubleshoot-configuration-server.md
     - name: Process server errors
       href: vmware-physical-azure-troubleshoot-process-server.md
+    - name: Replication appliance health
+      href: vmware-troubleshoot-appliance-health-issue.md
+    - name: Mobility agent health
+      href: vmware-troubleshoot-mobility-agent-health.md      
     - name: Mobility service - push installation errors
       href: vmware-azure-troubleshoot-push-install.md
     - name: Failover to Azure errors

articles/site-recovery/media/vmware-troubleshoot-appliance-health-issue/certificate.png

@@ -1,14 +1,14 @@
 ---
-title: Troubleshoot replication issues for disaster recovery of VMware VMs and physical servers to Azure by using Azure Site Recovery
-description: This article provides troubleshooting information for common replication issues during disaster recovery of VMware VMs and physical servers to Azure by using Azure Site Recovery.
+title: Troubleshoot replication issues for disaster recovery of VMware virtual machines and physical servers to Azure by using Azure Site Recovery
+description: This article provides troubleshooting information for common replication issues during disaster recovery of VMware virtual machines and physical servers to Azure by using Azure Site Recovery.
 author: ankitaduttaMSFT
-manager: rochakm
 ms.service: azure-site-recovery
 ms.topic: troubleshooting
-ms.date: 04/26/2023
+ms.date: 08/21/2024
 ms.author: ankitadutta
 
 ---
+
 # Troubleshoot replication issues for VMware VMs and physical servers
 
 This article describes some common issues and specific errors you might encounter when you replicate on-premises VMware VMs and physical servers to Azure using [Site Recovery](site-recovery-overview.md).
@@ -33,15 +33,15 @@ To solve these issues, [troubleshoot connectivity and replication](vmware-physic
 
 When you try to select the source machine to enable replication by using Site Recovery, the machine might not be available for one of the following reasons:
 
-* **Two virtual machines with the same instance UUID**: If two virtual machines under the vCenter have the same instance UUID, the first virtual machine discovered by the configuration server is displayed in the Azure portal. To resolve this issue, ensure that no two virtual machines have the same instance UUID. This scenario is commonly seen in instances where a backup VM becomes active and is logged into our discovery records. Refer to [Azure Site Recovery VMware-to-Azure: How to clean up duplicate or stale entries](https://social.technet.microsoft.com/wiki/contents/articles/32026.asr-vmware-to-azure-how-to-cleanup-duplicatestale-entries.aspx) to resolve.
-* **Incorrect vCenter user credentials**: Ensure that you added the correct vCenter credentials when you set up the configuration server by using the OVF template or unified setup. To verify the credentials that you added during setup, see [Modify credentials for automatic discovery](vmware-azure-manage-configuration-server.md#modify-credentials-for-automatic-discovery).
-* **vCenter insufficient privileges**: If the permissions provided to access vCenter don't have the required permissions, failure to discover virtual machines might occur. Ensure that the permissions described in [Prepare an account for automatic discovery](vmware-azure-tutorial-prepare-on-premises.md#prepare-an-account-for-automatic-discovery) are added to the vCenter user account.
-* **Azure Site Recovery management servers**: If the virtual machine is used as a management server under one or more of the following roles - Configuration server /scale-out process server / Master target server, then you won't be able to choose the virtual machine from the portal. Management servers cannot be replicated.
-* **Already protected/failed over through Azure Site Recovery services**: If the virtual machine is already protected or failed over through Site Recovery, the virtual machine isn't available to select for protection in the portal. Ensure that the virtual machine you're looking for in the portal isn't already protected by any other user or under a different subscription.
-* **vCenter not connected**: Check if vCenter is in a connected state. To verify, go to Recovery Services vault > Site Recovery Infrastructure > Configuration Servers > Click on respective configuration server > a blade opens on your right with details of associated servers. Check if vCenter is connected. If it's in a "Not Connected" state, resolve the issue, and then [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine isn't listed on the portal.
-* **ESXi powered off**: If the ESXi host under which the virtual machine resides is in a powered-off state, then the virtual machine isn't listed or isn't selectable on the Azure portal. Power on the ESXi host, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine is listed on the portal.
-* **Pending reboot**: If there is a pending reboot on the virtual machine, then you won't be able to select the machine on the Azure portal. Ensure to complete the pending reboot activities and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). After this, virtual machine is listed on the portal.
-* **IP not found or Machine does not have an IP address**: If the virtual machine doesn't have a valid IP address associated with it, then you are not able to select the machine on the Azure portal. Ensure to assign a valid IP address to the virtual machine, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). It could also be caused if the machine does not have a valid IP address associated with one of its NICs. Either assign a valid IP address to all NICs or remove the NIC that's missing the IP. After this, the virtual machine is listed on the portal.
+- **Two virtual machines with the same instance UUID**: If two virtual machines under the vCenter have the same instance UUID, the first virtual machine discovered by the configuration server is displayed in the Azure portal. To resolve this issue, ensure that no two virtual machines have the same instance UUID. This scenario is commonly seen in instances where a backup VM becomes active and is logged into our discovery records. Refer to [Azure Site Recovery VMware-to-Azure: How to clean up duplicate or stale entries](https://social.technet.microsoft.com/wiki/contents/articles/32026.asr-vmware-to-azure-how-to-cleanup-duplicatestale-entries.aspx) to resolve.
+-  **Incorrect vCenter user credentials**: Ensure that you added the correct vCenter credentials when you set up the configuration server by using the OVF template or unified setup. To verify the credentials that you added during setup, see [Modify credentials for automatic discovery](vmware-azure-manage-configuration-server.md#modify-credentials-for-automatic-discovery).
+-  **vCenter insufficient privileges**: If the permissions provided to access vCenter don't have the required permissions, failure to discover virtual machines might occur. Ensure that the permissions described in [Prepare an account for automatic discovery](vmware-azure-tutorial-prepare-on-premises.md#prepare-an-account-for-automatic-discovery) are added to the vCenter user account.
+-  **Azure Site Recovery management servers**: If the virtual machine is used as a management server under one or more of the following roles - Configuration server /scale-out process server / Master target server, then you won't be able to choose the virtual machine from the portal. Management servers cannot be replicated.
+-  **Already protected/failed over through Azure Site Recovery services**: If the virtual machine is already protected or failed over through Site Recovery, the virtual machine isn't available to select for protection in the portal. Ensure that the virtual machine you're looking for in the portal isn't already protected by any other user or under a different subscription.
+-  **vCenter not connected**: Check if vCenter is in a connected state. To verify, go to Recovery Services vault > Site Recovery Infrastructure > Configuration Servers > Click on respective configuration server > a blade opens on your right with details of associated servers. Check if vCenter is connected. If it's in a "Not Connected" state, resolve the issue, and then [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine isn't listed on the portal.
+-  **ESXi powered off**: If the ESXi host under which the virtual machine resides is in a powered-off state, then the virtual machine isn't listed or isn't selectable on the Azure portal. Power on the ESXi host, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server) on the portal. After this, virtual machine is listed on the portal.
+-  **Pending reboot**: If there is a pending reboot on the virtual machine, then you won't be able to select the machine on the Azure portal. Ensure to complete the pending reboot activities and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). After this, virtual machine is listed on the portal.
+- **IP not found or Machine does not have an IP address**: If the virtual machine doesn't have a valid IP address associated with it, then you are not able to select the machine on the Azure portal. Ensure to assign a valid IP address to the virtual machine, and [refresh the configuration server](vmware-azure-manage-configuration-server.md#refresh-configuration-server). It could also be caused if the machine does not have a valid IP address associated with one of its NICs. Either assign a valid IP address to all NICs or remove the NIC that's missing the IP. After this, the virtual machine is listed on the portal.
 
 ### Troubleshoot protected virtual machines greyed out in the portal
 
@@ -54,6 +54,7 @@ Another reason could be that the machine was cloned. When machines move between
 
 
 Following is a list of some of the most common issues:
+
 ### Initial replication issues [error 78169]
 
 Over and above ensuring that there are no connectivity, bandwidth, or time sync-related issues, ensure that:
@@ -119,6 +120,7 @@ To resolve the issue, use the following steps to verify the service status:
 
         *C:\Program Files (X86)\Microsoft Azure Site Recovery\agent\svagents\*.log*
 3. To register the master target with the configuration server, navigate to folder **%PROGRAMDATA%\ASR\Agent**, and run the following on command prompt:
+
    ```
    cmd
    cdpcli.exe --registermt
@@ -140,7 +142,7 @@ To resolve the issue, you can associate the policy with the configuration server
 
 ## Error ID 78144 - No app-consistent recovery point available for the VM in the last 'XXX' minutes
 
-Enhancements have been made in mobility agent [9.23](vmware-physical-mobility-service-overview.md#mobility-service-agent-version-923-and-higher) & [9.27](site-recovery-whats-new-archive.md#update-rollup-39) versions to handle VSS installation failure behaviors. Ensure that you're on the latest versions for best guidance on troubleshooting VSS failures.
+Enhancements have been made in mobility agent [9.23](vmware-physical-mobility-service-overview.md#mobility-service-agent-version-923-and-later) & [9.27](site-recovery-whats-new-archive.md#update-rollup-39) versions to handle VSS installation failure behaviors. Ensure that you're on the latest versions for best guidance on troubleshooting VSS failures.
 
 Some of the most common issues are listed:
 
@@ -171,7 +173,7 @@ Search for the string "vacpError"  by opening the vacp.log file in an editor
 
 `Ex: `**`vacpError`**`:220#Following disks are in FilteringStopped state [\\.\PHYSICALDRIVE1=5, ]#220|^|224#FAILED: CheckWriterStatus().#2147754994|^|226#FAILED to revoke tags.FAILED: CheckWriterStatus().#2147754994|^|`
 
-In the preceeding  example **2147754994** is the error code that tells you about the failure as shown:
+In the preceding  example **2147754994** is the error code that tells you about the failure as shown:
 
 #### VSS writer is not installed - Error 2147221164
 

articles/site-recovery/toc.yml

@@ -6,7 +6,7 @@ manager: gaggupta
 ms.service: azure-site-recovery
 ms.topic: how-to
 ms.author: ankitadutta
-ms.date: 07/10/2024
+ms.date: 08/21/2024
 ms.custom: engagement-fy23, linux-related-content
 ---
 
@@ -41,7 +41,7 @@ Push installation is an integral part of the job that runs from the Azure portal
 
 The push installation workflow is described in the following sections:
 
-### Mobility service agent version 9.23 and higher
+### Mobility service agent version 9.23 and later
 
 For more information about version 9.23, see [Update Rollup 35 for Azure Site Recovery](https://support.microsoft.com/help/4494485/update-rollup-35-for-azure-site-recovery).
 
@@ -57,7 +57,7 @@ During a push installation of the Mobility service, the following steps are perf
     - To generate application-consistent recovery points, refer to [our guidance](vmware-physical-manage-mobility-service.md#install-site-recovery-vss-provider-on-source-machine) to complete a manual installation of the Site Recovery VSS provider.
     - If you don't want to generate application-consistent recovery points, [modify the replication policy](vmware-azure-set-up-replication.md#create-a-policy) to turn off application-consistent recovery points.
 
-### Mobility service agent version 9.22 and below
+### Mobility service agent version 9.22 and older
 
 1. The agent is pushed to the source machine. Copying the agent to the source machine can fail due to multiple environmental errors. Refer to [our guidance](vmware-azure-troubleshoot-push-install.md) to troubleshoot push installation failures.
 1. After the agent is successfully copied to the server, a prerequisite check is performed on the server.
@@ -67,7 +67,7 @@ During a push installation of the Mobility service, the following steps are perf
 1. As part of the agent installation, the Volume Shadow Copy Service (VSS) provider for Azure Site Recovery is installed. The VSS provider is used to generate application-consistent recovery points.
    - If the VSS provider installation fails, the agent installation fails. To avoid failure of the agent installation, use [version 9.23](https://support.microsoft.com/help/4494485/update-rollup-35-for-azure-site-recovery) or higher to generate crash-consistent recovery points and do a manual install of the VSS provider.
 
-### Mobility service agent version 9.55 and higher
+### Mobility service agent version 9.55 and later
 
 1. The modernized architecture of mobility agent is set as default for the version 9.55 and above. Follow the instructions [here](#install-the-mobility-service-using-ui-modernized) to install the agent.
 2. To install the modernized architecture of mobility agent on versions 9.54 and above, follow the instructions [here](#install-the-mobility-service-using-command-prompt-modernized).
@@ -117,20 +117,21 @@ Locate the installer files for the server’s operating system using the followi
 > This section is applicable to Azure Site Recovery - Modernized. [Here are the installation instructions for Classic](#install-the-mobility-service-using-command-prompt-classic).
 
 ### Windows machine
+
 1. Open command prompt and navigate to the folder where the installer file has been placed.
 
    ```cmd
    cd C:\Program Files (x86)\Microsoft Azure Site Recovery
    ```
 2. Run the following command to extract the installer file:
    ```cmd
-       .\Microsoft-ASR_UA*Windows*release.exe /q /x:"C:\Program Files (x86)\Microsoft Azure Site Recovery"
+       Microsoft-ASR_UA*Windows*release.exe /q /x:"C:\Program Files (x86)\Microsoft Azure Site Recovery"
     ```
 3. To proceed with the installation, run the following command:
 
    ```cmd
 
-    .\UnifiedAgentInstaller.exe /Platform vmware /Silent /Role MS /CSType CSPrime /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery"
+    UnifiedAgentInstaller.exe /Platform vmware /Silent /Role MS /CSType CSPrime /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery"
    ```
     Once the installation is complete, copy the string that is generated alongside the parameter *Agent Config Input*. This string is required to [generate the Mobility Service configuration file](#generate-mobility-service-configuration-file).
 
@@ -139,7 +140,7 @@ Locate the installer files for the server’s operating system using the followi
 4. After successfully installing, register the source machine with the above appliance using the following command:
 
    ```cmd
-   "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\UnifiedAgentConfigurator.exe" /SourceConfigFilePath "config.json" /CredentialLessDiscovery true /CSType CSPrime
+   "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\UnifiedAgentConfigurator.exe" /SourceConfigFilePath "config.json"  /CSType CSPrime
    ```
 
 #### Installation settings
@@ -216,8 +217,14 @@ When providing both the machine credentials and the vCenter server or vSphere ES
   Use the following steps to generate mobility service configuration file:
 
   1. Navigate to the appliance with which you want to register your source machine. Open the Microsoft Azure Appliance Configuration Manager and navigate to the section **Mobility service configuration details**.
-  2. Paste the Machine Details string that you copied from Mobility Service and paste it in the input field here.
-  3. Click **Download configuration file**.
+  2. Paste the machine details string that you've copied from the Mobility Service and paste it in the input field here. In case you're re-registering the Mobility service, use the following commands to get the machine details string:
+      1. **Linux** : 
+          `cd /usr/local/ASR/Vx/bin/ ./AzureRcmCli --getagentconfiginput`
+      1. **Windows** :
+          `cd "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent"`
+          `./AzureRcmCli.exe --getagentconfiginput`
+                        
+  1. Select **Download configuration file**.
 
   ![Image showing download configuration file option for Mobility Service](./media/vmware-physical-mobility-service-overview-modernized/download-configuration-file.png)
 
@@ -450,5 +457,4 @@ As a **prerequisite to update or protect Ubuntu 14.04 machines** from 9.42 versi
 
 ## Next steps
 
-> [!div class="nextstepaction"]
-> [Set up push installation for the Mobility service](vmware-azure-install-mobility-service.md).
+- [Set up push installation for the Mobility service](vmware-azure-install-mobility-service.md).