Merge pull request #113694 from MicrosoftDocs/master

merge master to live (Sunday PM publish)

Author: tfosmark

CONTRIBUTING.md

@@ -11,7 +11,7 @@ For more information, see the [Code of Conduct FAQ](https://opensource.microsoft
 
 ## How can I contribute?
 
-There are a variety of ways to contribute to the documentation, review the sections below to find out which one is right for you.
+There are many ways to contribute to the documentation, review the sections below to find out which one is right for you.
 
 ### Reporting Bugs and Suggesting Enhancements
 

articles/app-service/web-sites-monitor.md

@@ -5,7 +5,7 @@ author: btardif
 
 ms.assetid: d273da4e-07de-48e0-b99d-4020d84a425e
 ms.topic: article
-ms.date: 01/11/2019
+ms.date: 04/23/2020
 ms.author: byvinyal
 ms.custom: seodec18
 
@@ -48,7 +48,7 @@ If an app exceeds the *CPU (short)*, *CPU (Day)*, or *bandwidth* quota, the app
 
 ![403 error message][http403]
 
-If the app Memory quota is exceeded, the app is restarted.
+If the app Memory quota is exceeded, the app is stopped temporarily.
 
 If the Filesystem quota is exceeded, any write operation fails. Write operation failures include any writes to logs.
 
@@ -130,8 +130,7 @@ There are two metrics that reflect CPU usage:
 **CPU percentage**: Useful for apps hosted in Basic, Standard, and Premium plans, because they can be scaled out. CPU percentage is a good indication of the overall usage across all instances.
 
 ## Metrics granularity and retention policy
-
-Metrics for an app and app service plan are logged and aggregated by the service. Metrics are retained for 90 days.
+Metrics for an app and app service plan are logged and aggregated by the service and [retained according to these rules](../azure-monitor/platform/data-platform-metrics.md#retention-of-metrics).
 
 ## Monitoring quotas and metrics in the Azure portal
 To review the status of the various quotas and metrics that affect an app, go to the [Azure portal](https://portal.azure.com).
@@ -164,4 +163,4 @@ For more information about autoscale, see [How to scale](../monitoring-and-diagn
 <!-- Images. -->
 [http403]: ./media/web-sites-monitor/http403.png
 [quotas]: ./media/web-sites-monitor/quotas.png
-[metrics]: ./media/web-sites-monitor/metrics.png
+[metrics]: ./media/web-sites-monitor/metrics.png

articles/azure-monitor/log-query/logs-structure.md

@@ -50,16 +50,17 @@ Unlike a Log Analytics workspace, an Application Insights application has a fixe
 
 | Table | Description | 
 |:---|:---|
-| availabilityResults | Summary data from availability tests. |
-| browserTimings      | Data about client performance, such as the time taken to process the incoming data. |
-| customEvents        | Custom events created by your application. |
-| customMetrics       | Custom metrics created by your application. |
-| dependencies        | Calls from the application to external components. |
-| exceptions          | Exceptions thrown by the application runtime. |
-| pageViews           | Data about each website view with browser information. |
-| performanceCounters | Performance measurements from the compute resources supporting the application. |
-| requests            | Details of each application request.  |
-| traces              | Results from distributed tracing. |
+| availabilityResults	| Summary data from availability tests.
+| browserTimings      | 	Data about client performance, such as the time taken to process the incoming data.
+| customEvents	      | Custom events created by your application.
+| customMetrics	      | Custom metrics created by your application.
+| dependencies	      | Calls from the application to other components (including external components) recorded via TrackDependency() – for example, calls to REST API, database or a file system. 
+| exceptions	        | Exceptions thrown by the application runtime, captures both server side and client-side (browsers) exceptions.
+| pageViews	          | Data about each website view with browser information.
+| performanceCounters	| Performance measurements from the compute resources supporting the application, for example, Windows performance counters.
+| requests	          | Requests received by your application. For example, a separate request record is logged for each HTTP request that your web app receives. 
+| traces	            | Detailed logs (traces) emitted through application code/logging frameworks recorded via TrackTrace().
+
 
 You can view the schema for each table in the **Schema** tab in Log Analytics for the application.
 

articles/azure-monitor/platform/diagnostic-settings.md

@@ -5,7 +5,7 @@ author: bwren
 ms.author: bwren
 services: azure-monitor
 ms.topic: conceptual
-ms.date: 04/15/2020
+ms.date: 04/27/2020
 ms.subservice: logs
 ---
 
@@ -26,7 +26,13 @@ Each Azure resource requires its own diagnostic setting, which defines the follo
 A single diagnostic setting can define no more than one of each of the destinations. If you want to send data to more than one of a particular destination type (for example, two different Log Analytics workspaces), then create multiple settings. Each resource can have up to 5 diagnostic settings.
 
 > [!NOTE]
-> [Platform metrics](metrics-supported.md) are collected automatically to [Azure Monitor Metrics](data-platform-metrics.md). Diagnostic settings can be used to collect metrics for certain Azure services into Azure Monitor Logs for analysis with other monitoring data using [log queries](../log-query/log-query-overview.md).
+> [Platform metrics](metrics-supported.md) are collected automatically to [Azure Monitor Metrics](data-platform-metrics.md). Diagnostic settings can be used to collect metrics for certain Azure services into Azure Monitor Logs for analysis with other monitoring data using [log queries](../log-query/log-query-overview.md) with certain limitations. 
+>  
+>  
+> Sending multi-dimensional metrics via diagnostic settings is not currently supported. Metrics with dimensions are exported as flattened single dimensional metrics, aggregated across dimension values. *For example*: The 'IOReadBytes' metric on an Blockchain can be explored and charted on a per node level. However, when exported via diagnostic settings, the metric exported represents as all read bytes for all nodes. In addition, due to internal limitations not all metrics are exportable to Azure Monitor Logs / Log Analytics. For more information, see the [list of exportable metrics](metrics-supported-export-diagnostic-settings.md). 
+>  
+>  
+> To get around these limitations for specific metrics, we suggest you manually extract them using the [Metrics REST API](https://docs.microsoft.com/rest/api/monitor/metrics/list) and import them into Azure Monitor Logs using the [Azure Monitor Data collector API](data-collector-api.md).  
 
 ## Destinations
 
@@ -73,9 +79,8 @@ You can configure diagnostic settings in the Azure portal either from the Azure
      - **AllMetrics** routes a resource's platform metrics into the Azure Logs store, but in log form. These metrics are usually sent only to the Azure Monitor metrics time-series database. Sending them to the Azure Monitor Logs store (which is searchable via Log Analytics) you to integrate them into queries which search across other logs. This option may not be available for all resource types. When it is supported, [Azure Monitor supported metrics](metrics-supported.md) lists what metrics are collected for what resource types.
 
        > [!NOTE]
-       > Sending multi-dimensional metrics via diagnostic settings is not currently supported. Metrics with dimensions are exported as flattened single dimensional metrics, aggregated across dimension values.
-       >
-       > *For example*: The 'IOReadBytes' metric on an Blockchain can be explored and charted on a per node level. However, when exported via diagnostic settings, the metric exported represents as all read bytes for all nodes.
+       > See limitatation for routing metrics to Azure Monitor Logs earlier in this article.  
+
 
      - **Logs** lists the different categories available depending on the resource type. Check any categories that you would like to route to a destination.
 

articles/site-recovery/azure-to-azure-common-questions.md

@@ -189,11 +189,11 @@ You can replicate 16 virtual machines together in a replication group.
 Because multi-VM consistency is CPU intensive, enabling it can affect workload performance. Use multi-VM consistency only if machines are running the same workload and you need consistency across multiple machines. For example, if you have two SQL Server instances and two web servers in an application, you should have multi-VM consistency for the SQL Server instances only.
 
 ### Can you add an already replicating VM to a replication group?
-
 You can add a VM to a new replication group while enabling replication. You can also add a VM to an existing replication group while enabling replication. However, you cannot add an already replicating VM to a new replication group or existing replication group.
-
+ 
 ## Failover
 
+
 ### How is capacity ensured in the target region for Azure VMs?
 
 The Site Recovery team and Azure capacity management team plan for sufficient infrastructure capacity. When you start a failover, the teams also help ensure VM instances that are protected by Site Recovery will deploy to the target region.

articles/site-recovery/azure-to-azure-how-to-enable-zone-to-zone-disaster-recovery.md

@@ -0,0 +1,125 @@
+---
+title: Enable Zone to Zone Disaster Recovery for Azure Virtual Machines
+description: This article describes when and how to use Zone to Zone Disaster Recovery for Azure virtual machines.
+author: sideeksh
+manager: gaggupta
+ms.service: site-recovery
+ms.topic: article
+ms.date: 04/28/2020
+ms.author: sideeksh
+
+---
+
+# Enable Zone to Zone Disaster Recovery for Azure virtual machines
+
+This article describes how to replicate, failover, and failback Azure virtual machines from one Availability Zone to another within the same Azure region.
+
+>[!NOTE]
+>
+>- Site Recovery currently does not support Recovery Plans for Zone to Zone Disaster Recovery. 
+>- Support for Zone to Zone disaster recovery is currently limited to two regions: Southeast Asia and UK South.  
+
+Site Recovery service contributes to your business continuity and disaster recovery strategy by keeping your business apps up and running, during planned and unplanned outages. It is the recommended Disaster Recovery option to keep your applications up and running if there are regional outages.
+
+Availability Zones are unique physical locations within an Azure region. Each zone has one or more datacenters. 
+
+## Using Availability Zones for Disaster Recovery 
+
+Typically, Availability Zones are used to deploy VMs in a High Availability configuration. They may be too close to each other to serve as a Disaster Recovery solution in case of natural disaster.
+
+However, in some scenarios, Availability Zones can be leveraged for Disaster Recovery:
+
+- Many customers who had a metro Disaster Recovery strategy while hosting applications on premise sometimes look to mimic this strategy once they migrate applications over to Azure. These customers acknowledge the fact that metro Disaster Recovery strategy may not work in case of a large-scale physical disaster and accept this risk. For such customers, Zone to Zone Disaster Recovery can be used as a Disaster Recovery option.
+
+- Many other customers have complicated networking infrastructure and do not wish to recreate it in a secondary region due to the associated cost and complexity. Zone to Zone Disaster Recovery reduces complexity as it leverages redundant networking concepts across Availability Zones making configuration much simpler. Such customers prefer simplicity and can also use Availability Zones for Disaster Recovery.
+
+- In some regions that do not have a paired region within the same legal jurisdiction (for example, Southeast Asia), Zone to Zone Disaster Recovery can serve as the de-facto Disaster Recovery solution as it helps ensure legal compliance, since your applications and data do not cross national boundaries. 
+
+- Zone to Zone Disaster Recovery implies replication of data across shorter distances when compared with Azure to Azure Disaster Recovery and therefore, you may see lower latency and consequently lower RPO.
+
+While these are strong advantages, there is a possibility that Zone to Zone Disaster Recovery may fall short of resilience requirements in the event of a region-wide natural disaster.
+
+## Networking for Zone to Zone Disaster Recovery
+
+As mentioned above, Zone to Zone Disaster Recovery reduces complexity as it leverages redundant networking concepts across Availability Zones making configuration much simpler. The behavior of networking components in the Zone to Zone Disaster Recovery scenario is outlined below: 
+
+- Virtual Network: You may use the same virtual network as the source network for actual failovers. Use a different virtual network to the source virtual network for test failovers.
+
+- Subnet: Failover into the same subnet is supported.
+
+- Private IP address: If you are using static IP addresses, you can use the same IPs in the target zone if you choose to configure them in such a manner.
+
+- Accelerated Networking: Similar to Azure to Azure Disaster Recovery, you may enable Accelerated Networking if the VM SKU supports it.
+
+- Public IP address: You can attach a previously created standard public IP address in the same region to the target VM. Basic public IP addresses do not support Availability Zone related scenarios.
+
+- Load balancer: Standard load balancer is a regional resource and therefore the target VM can be attached to the backend pool of the same load balancer. A new load balancer is not required.
+
+- Network Security Group: You may use the same network security groups as applied to the source VM.
+
+## Pre-requisites
+
+Before deploying Zone to Zone Disaster Recovery for your VMs, it is important to ensure that other features enabled on the VM are interoperable with zone to zone disaster recovery.
+
+|Feature  | Support statement  |
+|---------|---------|
+|Classic VMs   |     Not supported    |
+|ARM VMs    |    Supported    |
+|Azure Disk Encryption v1 (dual pass, with AAD)     |     Supported	|
+|Azure Disk Encryption v2 (single pass, without AAD)    |    Supported    |
+|Unmanaged disks    |    Not supported    |
+|Managed disks    |    Supported    |
+|Customer managed keys    |    Supported    |
+|Proximity placement groups    |    Supported    |
+|Backup interoperability    |    File level backup and restore are supported. Disk and VM level backup and restore and not supported.    |
+|Hot add/remove    |    Disks can be added after enabling zone to zone replication. Removal of disks after enabling zone to zone replication is not supported.    |	
+
+## Set up Site Recovery Zone to Zone Disaster Recovery
+
+### Log in
+
+Login to the Azure portal.
+
+### Enable replication for the zonal Azure virtual machine
+
+1. On the Azure portal menu, select Virtual machines, or search for and select Virtual machines on any page. Select the VM you want to replicate. For zone to zone disaster recovery, this VM must already be in an availability zone.
+
+2. In Operations, select Disaster recovery.
+
+3. As shown below, in the Basics tab, select ‘Yes’ for ‘Disaster Recovery between Availability Zones?’
+
+    ![Basic Settings page](./media/azure-to-azure-how-to-enable-zone-to-zone-disaster-recovery/zonal-disaster-recovery-basic-settings-blade.png)
+
+4. If you accept all defaults, click ‘Review + Start replication’ followed by ‘Start replication’.
+
+5. If you want to make changes to the replication settings, click on ‘Next: Advanced settings’.
+
+6. Change the settings away from default wherever appropriate. For users of Azure to Azure Disaster Recovery, this page might seem familiar. More details on the options presented on this blade can be found [here](https://docs.microsoft.com/azure/site-recovery/azure-to-azure-tutorial-enable-replication)
+
+    ![Advanced Settings page](./media/azure-to-azure-how-to-enable-zone-to-zone-disaster-recovery/zonal-disaster-recovery-advanced-settings-blade.png)
+
+7. Click on ‘Next: Review + Start replication’ and then ‘Start replication’.
+
+## FAQs
+
+1. How does pricing work for Zone to Zone Disaster Recovery?
+Pricing for Zone to Zone Disaster Recovery is identical to the pricing of Azure to Azure Disaster Recovery. You can find more details on the pricing page [here](https://azure.microsoft.com/pricing/details/site-recovery/) and [here](https://azure.microsoft.com/blog/know-exactly-how-much-it-will-cost-for-enabling-dr-to-your-azure-vm/). Note that the egress charges that you would see in zone to zone disaster recovery would be lower than region to region disaster recovery.
+
+2. What is the SLA for RTO and RPO?
+The RTO SLA is the same as that for Site Recovery overall. We promise RTO <= 2 hours. There is no defined SLA for RPO.
+
+3. Is capacity guaranteed in the secondary zone?
+The Site Recovery team and Azure capacity management team plan for sufficient infrastructure capacity. When you start a failover, the teams also help ensure VM instances that are protected by Site Recovery will deploy to the target zone.
+
+4. Which operating systems are supported?
+Zone to Zone Disaster Recovery supports the same operating systems as Azure to Azure Disaster Recovery. Refer to the support matrix [here](https://docs.microsoft.com/azure/site-recovery/azure-to-azure-support-matrix).
+
+## Next steps
+
+The steps that need to be followed to run a Disaster Recovery drill, fail over, re-protect, and failback are the same as the steps in Azure to Azure Disaster Recovery scenario.
+
+To perform a Disaster Recovery drill, please follow the steps outlined [here](https://docs.microsoft.com/azure/site-recovery/azure-to-azure-tutorial-dr-drill).
+
+To perform a fail over and re-protect VMs in the secondary zone, follow the steps outlined [here](https://docs.microsoft.com/azure/site-recovery/azure-to-azure-tutorial-failover-failback).
+
+To failback to the primary zone, follow the steps outlined [here](https://docs.microsoft.com/azure/site-recovery/azure-to-azure-tutorial-failback).

articles/site-recovery/azure-to-azure-how-to-reprotect.md

@@ -93,6 +93,10 @@ When the VM is re-protected after failing back to the primary region (i.e., if t
 
 When the VM is re-protected from the DR region to the primary region, we do not delete the erstwhile primary VM and associated NIC(s).
 
+When the VM is re-protected after failing back to the primary region (i.e., if the VM is re-protected from primary region to DR region), the target VM and associated NIC(s) are deleted. 
+
+When the VM is re-protected from the DR region to the primary region, we do not delete the erstwhile primary VM and associated NIC(s).
+
 ## Next steps
 
 After the VM is protected, you can initiate a failover. The failover shuts down the VM in the secondary region and creates and boots the VM in the primary region, with brief downtime during this process. We recommend you choose an appropriate time for this process and that you run a test failover before initiating a full failover to the primary site. [Learn more](site-recovery-failover.md) about Azure Site Recovery failover.

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

@@ -168,8 +168,6 @@ Because SUSE Linux uses symbolic links, or symlinks, to maintain a certificate l
 
 For Site Recovery replication to work, outbound connectivity to specific URLs is required from the VM. If your VM is behind a firewall or uses network security group (NSG) rules to control outbound connectivity, you might face one of these issues. While we continue to support outbound access via URLs, using an allow list of IP ranges is no longer supported.
 
-### Issue 1: Failed to register Azure VM with Site Recovery (151195)
-
 #### Possible causes
 
 - A connection can't be established to Site Recovery endpoints because of a Domain Name System (DNS) resolution failure.