Merge pull request #79018 from ThalathBhagya/master

minor updated

Author: PRMerger18

articles/backup/backup-azure-mars-troubleshoot.md

@@ -80,34 +80,31 @@ If scheduled backups don't get triggered automatically, while manual backups wor
 
 - Ensure the  Online Backup status is set to **Enable**. To verify the status perform the below:
 
-  - Go to **Control Panel** > **Administrative Tools** > **Task Scheduler**.
-	- Expand **Microsoft**, and select **Online Backup**.
+  - Open **Task Scheduler** and expand **Microsoft**, and select **Online Backup**.
   - Double-click **Microsoft-OnlineBackup**, and go to the **Triggers** tab.
-  - Verify if the status is set to **Enabled**. If it isn't, select **Edit**, and select the **Enabled** check box and click **OK**.
+  - Verify if the status is set to **Enabled**. If it isn't, then select **Edit** > **Enabled** check box and click **OK**.
 
-- Ensure the user account selected for running the task is either **SYSTEM** or **Local Administrators' group** on the server. To verify the user account, go to the **General** tab and check the **Security options**.
+- Ensure the user account selected for running the task is either **SYSTEM** or **Local Administrators' group** on the server. To verify the user account, go to the **General** tab and check the **Security** options.
 
-- See if PowerShell 3.0 or later is installed on the server. To check the PowerShell version, run the following command and verify that the *Major* version number is equal to or greater than 3.
+- Ensure PowerShell 3.0 or later is installed on the server. To check the PowerShell version, run the following command and verify that the *Major* version number is equal to or greater than 3.
 
   `$PSVersionTable.PSVersion`
 
-- See if the following path is part of the *PSMODULEPATH* environment variable.
+- Ensure the following path is part of the *PSMODULEPATH* environment variable
 
   `<MARS agent installation path>\Microsoft Azure Recovery Services Agent\bin\Modules\MSOnlineBackup`
 
-- If the PowerShell execution policy for *LocalMachine* is set to restricted, the PowerShell cmdlet that triggers the backup task might fail. Run the following commands in elevated mode, to check and set the execution policy to either *Unrestricted* or *RemoteSigned*.
+- If the PowerShell execution policy for *LocalMachine* is set to restricted, the PowerShell cmdlet that triggers the backup task might fail. Run the following commands in elevated mode, to check and set the execution policy to either *Unrestricted* or *RemoteSigned*
 
   `PS C:\WINDOWS\system32> Get-ExecutionPolicy -List`
 
   `PS C:\WINDOWS\system32> Set-ExecutionPolicy Unrestricted`
 
-- Ensure server was rebooted after the backup agent installation
+- Ensure there are no missing or corrupted **PowerShell** module **MSonlineBackup**. In case there are any missing or corrupt file, to resolve this issue perform the below:
 
-- Ensure there are no missing or corrupted **PowerShell** module **MSonlineBackup**. In case there are any missing or corrupt file, to resolve the issue perform the below:
-
-  - From another machine (Windows 2008 R2) having the MARS agent working properly, copy the MSOnlineBackup folder from *(C:\Program Files\Microsoft Azure Recovery Services Agent\bin\Modules)* path.
+  - From any machine having MARS agent that is working properly, copy the MSOnlineBackup folder from *(C:\Program Files\Microsoft Azure Recovery Services Agent\bin\Modules)* path.
   - Paste this in problematic machine in the same path *(C:\Program Files\Microsoft Azure Recovery Services Agent\bin\Modules)*.
-  - If **MSOnlineBackup** folder is already exists in the machine, paste/replace the content files inside it.
+  - If **MSOnlineBackup** folder is already exists in the machine, paste or replace the content files inside it.
 
 
 > [!TIP]

articles/backup/backup-azure-system-state-troubleshoot.md

@@ -15,6 +15,29 @@ ms.author: srinathvasireddy
 
 This article describes solutions for issues that you might encounter while using System State Backup.
 
+## Basic troubleshooting
+We recommend you perform the below validation, before you start troubleshooting System State backup:
+
+- [Ensure Microsoft Azure Recovery Services (MARS) Agent is up to date](https://go.microsoft.com/fwlink/?linkid=229525&clcid=0x409)
+- [Ensure there is network connectivity between MARS agent and Azure](https://aka.ms/AB-A4dp50)
+- Ensure Microsoft Azure Recovery Services is running (in Service console). If required restart and retry the operation
+- [Ensure 5-10% free volume space is available on scratch folder location](https://aka.ms/AB-AA4dwtt)
+- [Check if another process or antivirus software is interfering with Azure Backup](https://aka.ms/AB-AA4dwtk)
+- [Scheduled backup fails, but manual backup works](https://aka.ms/ScheduledBackupFailManualWorks)
+- Ensure your OS has the latest updates
+- [Ensure unsupported drives and files with unsupported attributes are excluded from backup](backup-support-matrix-mars-agent.md#supported-drives-or-volumes-for-backup)
+- Ensure **System Clock** on the protected system is configured to correct time zone <br>
+- [Ensure that the server has at least .Net Framework version 4.5.2 and higher](https://www.microsoft.com/download/details.aspx?id=30653)<br>
+- If you are trying to **reregister your server** to a vault, then: <br>
+  - Ensure the agent is uninstalled on the server and it is deleted from portal <br>
+  - Use the same passphrase that was initially used for registering the server <br>
+- In case of offline backup ensure that Azure PowerShell version 3.7.0 is installed on both source and copy computer before you begin offline backup operation
+- [Consideration when Backup agent is running on an Azure virtual machine](https://aka.ms/AB-AA4dwtr)
+
+### Limitation
+- Recovering to different hardware using System State recovery is not recommended by Microsoft
+- System State backup currently supports "on premise" Windows servers, this functionality is not available for Azure VMs.
+
 ## Pre-requisite
 
 Before we troubleshoot System State Backup with Azure Backup, ensure you preform the below pre-requisites check.  

articles/backup/backup-configure-vault.md

@@ -251,14 +251,13 @@ After the initial backup is completed, the **Job completed** status appears in t
 
 ## Ad hoc backup policy retention behavior
 
+* For more information, refer step 8 of [Create a backup policy](backup-configure-vault.md#create-a-backup-policy)
+
 | Backup Schedule option | How long will the backed-up data be retained?
 | -- | --
-| Schedule a backup every: *Day | **Default Retention**: Equivalent to the “retention in days for daily backups.” <br/><br/> **Exception**: If a daily scheduled backup set for long term retention (Weeks, Months, Years) fails, then an adhoc backup triggered right after this failed scheduled backup is considered for long-term retention. Otherwise, the next scheduled backup is considered for long-term retention.<br/><br/> **Example**: If (say) the scheduled backup taken on Thursday 8:00 am fails and the same backup was to be considered for Weekly/Monthly/Yearly retention, then the first adhoc backup triggered before the next scheduled backup (say) Friday, 8:00 am would be automatically tagged for Weekly/Monthly/Yearly retention as applicable to the Thursday 8:00 am backup.
-| Schedule a backup every: *Weekly | **Default Retention**: 1 day. <br/> Adhoc Backups taken for a data source with weekly Backup policy are deleted the very next day, even if they are the most recent Backups for the data source. <br/><br/> **Exception**: If a weekly scheduled backup set for long term retention (Weeks, Months, Years) fails, then an adhoc backup triggered right after this failed scheduled backup is considered for long-term retention. Otherwise, the next scheduled backup is considered for long-term retention. <br/><br/> **Example**: If (say) the scheduled backup taken on Thursday 8:00 am fails and the same backup was to be considered for Monthly/Yearly retention, then the first adhoc backup triggered before the next scheduled backup (say) Thursday, 8:00 am would be automatically tagged for Monthly/Yearly retention as applicable to the Thursday 8:00 am backup
-
+| Schedule a backup every: *Day | **Default Retention**: Equivalent to the “retention in days for daily backups” <br/><br/> **Exception**: If a daily scheduled backup set for long term retention (Weeks, Months, Years) fails, then an adhoc backup triggered right after this failed scheduled backup is considered for long-term retention. Otherwise, the next scheduled backup is considered for long-term retention.<br/><br/> **Example**: If (say) the scheduled backup taken on Thursday 8:00 am fails and the same backup was to be considered for Weekly/Monthly/Yearly retention, then the first adhoc backup triggered before the next scheduled backup (say) Friday, 8:00 am would be automatically tagged for Weekly/Monthly/Yearly retention as applicable to the Thursday 8:00 am backup.
+| Schedule a backup every: *Weekly | **Default Retention**: 1 day <br/> Adhoc Backups taken for a data source with weekly Backup policy are deleted the very next day, even if they are the most recent Backups for the data source. <br/><br/> **Exception**: If a weekly scheduled backup set for long term retention (Weeks, Months, Years) fails, then an adhoc backup triggered right after this failed scheduled backup is considered for long-term retention. Otherwise, the next scheduled backup is considered for long-term retention. <br/><br/> **Example**: If (say) the scheduled backup taken on Thursday 8:00 am fails and the same backup was to be considered for Monthly/Yearly retention, then the first adhoc backup triggered before the next scheduled backup (say) Thursday, 8:00 am would be automatically tagged for Monthly/Yearly retention as applicable to the Thursday 8:00 am backup
 
-> [!NOTE]
-> For more information, refer step 8 of [Create a backup policy](backup-configure-vault.md#create-a-backup-policy)
 
 ## Next steps