Merge branch 'MicrosoftDocs:main' into master

Author: mathapli

.openpublishing.redirection.json

@@ -3729,6 +3729,21 @@
       "source_path_from_root": "/articles/virtual-network/tutorial-create-route-table-cli.md",
       "redirect_url": "/azure/virtual-network/tutorial-create-route-table",
       "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/virtual-network/tutorial-connect-virtual-networks-portal.md",
+      "redirect_url": "/azure/virtual-network/tutorial-connect-virtual-networks",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/virtual-network/tutorial-connect-virtual-networks-powershell.md",
+      "redirect_url": "/azure/virtual-network/tutorial-connect-virtual-networks",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/virtual-network/tutorial-connect-virtual-networks-cli.md",
+      "redirect_url": "/azure/virtual-network/tutorial-connect-virtual-networks",
+      "redirect_document_id": false
     }
   ]
 }

articles/api-management/api-management-howto-ip-addresses.md

@@ -39,7 +39,7 @@ Public IP addresses will be part of the response:
   "properties": {
     ...
     "publicIPAddresses": [
-      "13.77.143.53"
+      "172.31.0.1"
     ],
     ...
   }
@@ -70,7 +70,7 @@ GET https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/
   "properties": {
     ...
     "publicIPAddresses": [
-      "13.85.20.170"
+      "172.31.0.1"
     ],
     "privateIPAddresses": [
       "192.168.1.5"

articles/api-management/media/api-management-howto-ip-addresses/public-ip.png

@@ -25,7 +25,7 @@ The v2 SKU includes the following enhancements:
 - **Autoscaling**: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. This SKU offers true elasticity. In the Standard_v2 and WAF_v2 SKU, Application Gateway can operate both in fixed capacity (autoscaling disabled) and in autoscaling enabled mode. Fixed capacity mode is useful for scenarios with consistent and predictable workloads. Autoscaling mode is beneficial in applications that see variance in application traffic.
 - **Zone redundancy**: An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager. You can choose a single zone or multiple zones where Application Gateway instances are deployed, which makes it more resilient to zone failure. The backend pool for applications can be similarly distributed across availability zones.
 
-  Zone redundancy is available only where Azure Zones are available. In other regions, all other features are supported. For more information, see [Regions and Availability Zones in Azure](../reliability/availability-zones-service-support.md)
+  Zone redundancy is available only where Azure availability zones are available. In other regions, all other features are supported. For more information, see [Azure regions with availability zone support](../reliability/availability-zones-region-support.md).
 - **Static VIP**: Application Gateway v2 SKU supports the static VIP type exclusively. Static VIP ensures that the VIP associated with the application gateway doesn't change for the lifecycle of the deployment, even after a restart. You must use the application gateway URL for domain name routing to App Services via the application gateway, as v1 doesn't have a static VIP.
 - **Header Rewrite**: Application Gateway allows you to add, remove, or update HTTP request and response headers with v2 SKU. For more information, see [Rewrite HTTP headers with Application Gateway](./rewrite-http-headers-url.md)
 - **Key Vault Integration**: Application Gateway v2 supports integration with Key Vault for server certificates that are attached to HTTPS enabled listeners. For more information, see [TLS termination with Key Vault certificates](key-vault-certs.md).

articles/api-management/media/api-management-howto-ip-addresses/vnet-ip.png

@@ -31,7 +31,7 @@ In the event when a zone is down, there's no action required by you to recover f
 
 ## Supported regions with availability zones
 
-See [Regions and Availability Zones in Azure](../reliability/availability-zones-service-support.md) for the Azure regions that have availability zones. 
+See [Azure regions with availability zone support](../reliability/availability-zones-region-support.md) for the Azure regions that have availability zones. 
 Automation accounts currently support the following regions: 
 
 - Australia East
@@ -82,4 +82,4 @@ There is no change to the [Service Level Agreement](https://azure.microsoft.com/
 
 ## Next steps
 
-- Learn more about [regions that support availability zones](../reliability/availability-zones-service-support.md).
+- Learn more about [regions that support availability zones](../reliability/availability-zones-region-support.md).

articles/api-management/media/api-management-using-with-vnet/verify-network-connectivity-status.png

@@ -17,7 +17,7 @@ ms.service: azure-automation
 
 This article explains the disaster recovery strategy to handle a region-wide or zone-wide failure.
 
-You must have a disaster recovery strategy to handle a region-wide service outage or zone-wide failure to help reduce the impact and effects arising from unpredictable events on your business and customers. You are responsible to set up disaster recovery of Automation accounts, and its dependent resources such as Modules, Connections, Credentials, Certificates, Variables and Schedules. An important aspect of a disaster recovery plan is preparing to failover to the replica of the Automation account created in advance in the secondary region, if the Automation account in the primary region becomes unavailable. Ensure that your disaster recovery strategy considers your Automation account and the dependent resources.
+You must have a disaster recovery strategy to handle a region-wide service outage or zone-wide failure to help reduce the impact and effects arising from unpredictable events on your business and customers. You're responsible to set up disaster recovery of Automation accounts, and its dependent resources such as Modules, Connections, Credentials, Certificates, Variables and Schedules. An important aspect of a disaster recovery plan is preparing to fail over to the replica of the Automation account created in advance in the secondary region, if the Automation account in the primary region becomes unavailable. Ensure that your disaster recovery strategy considers your Automation account and the dependent resources.
 
 In addition to high availability offered by Availability zones, some regions are paired with another region to provide protection from regional or large geographical disasters. Irrespective of whether the primary region has a regional pair or not, the disaster recovery strategy for the Automation account remains the same. For more information about regional pairs, [learn more](../availability-zones/cross-region-replication-azure.md).
 
@@ -30,7 +30,7 @@ requires a location that you must use for deployment. This would be the primary
 - Begin by [creating a replica Automation account](/azure/automation/quickstarts/create-azure-automation-account-portal#create-automation-account) in any alternate [region](https://azure.microsoft.com/global-infrastructure/services/?products=automation&regions=all).
 - Select the secondary region of your choice - paired region or any other region where Azure Automation is available.
 - Apart from creating a replica of the Automation account, replicate the dependent resources such as Runbooks, Modules, Connections, Credentials, Certificates, Variables, Schedules and permissions assigned for the Run As account and Managed Identities in the Automation account in primary region to the Automation account in secondary region. You can use the [PowerShell script](#script-to-migrate-automation-account-assets-from-one-region-to-another) to migrate assets of the Automation account from one region to another.
-- If you are using [ARM templates](../azure-resource-manager/management/overview.md) to define and deploy Automation runbooks, you can use these templates to deploy the same runbooks in any other Azure region where you create the replica Automation account. In case of a region-wide outage or zone-wide failure in the primary region, you can execute the runbooks replicated in the secondary region to continue business as usual. This ensures that the secondary region steps up to continue the work if the primary region has a disruption or failure. 
+- If you're using [ARM templates](../azure-resource-manager/management/overview.md) to define and deploy Automation runbooks, you can use these templates to deploy the same runbooks in any other Azure region where you create the replica Automation account. In case of a region-wide outage or zone-wide failure in the primary region, you can execute the runbooks replicated in the secondary region to continue business as usual. This ensures that the secondary region steps up to continue the work if the primary region has a disruption or failure. 
 
 >[!NOTE]
 > Due to data residency requirements, jobs data and logs present in the primary region are not available in the secondary region.
@@ -66,21 +66,21 @@ If the Linux Hybrid Runbook worker is deployed using agent-based approach in a r
 ---
 
 ### Scenario: Execute jobs on Hybrid Runbook Worker deployed in the primary region of failure
-If the Hybrid Runbook worker is deployed in the primary region, and there is a compute failure in that region, the machine will not be available for executing Automation jobs. You must provision a new virtual machine in an alternate region and register it as Hybrid Runbook Worker in Automation account in the secondary region.
+If the Hybrid Runbook worker is deployed in the primary region, and there's a compute failure in that region, the machine won't be available for executing Automation jobs. You must provision a new virtual machine in an alternate region and register it as Hybrid Runbook Worker in Automation account in the secondary region.
 
 - See the installation steps in [how to deploy an extension-based Windows or Linux User Hybrid Runbook Worker](extension-based-hybrid-runbook-worker-install.md?tabs=windows#create-hybrid-worker-group).
 - See the installation steps in [how to deploy an agent-based Windows Hybrid Worker](automation-windows-hrw-install.md#installation-options).
 - See the installation steps in [how to deploy an agent-based Linux Hybrid Worker](automation-linux-hrw-install.md#install-a-linux-hybrid-runbook-worker).
 
 ## Script to migrate Automation account assets from one region to another
 
-You can use these scripts for migration of Automation account assets from the account in primary region to the account in the secondary region. These scripts are used to migrate only Runbooks, Modules, Connections, Credentials, Certificates and Variables. The execution of these scripts does not affect the Automation account and its assets present in the primary region.
+You can use these scripts for migration of Automation account assets from the account in primary region to the account in the secondary region. These scripts are used to migrate only Runbooks, Modules, Connections, Credentials, Certificates and Variables. The execution of these scripts doesn't affect the Automation account and its assets present in the primary region.
 
 ### Prerequisites
 
- 1. Ensure that the Automation account in the secondary region is created and available so that assets from primary region can be migrated to it. It is preferred if the destination automation account is one without any custom resources as it prevents potential resource clash due to same name and loss of data.
+ 1. Ensure that the Automation account in the secondary region is created and available so that assets from primary region can be migrated to it. It's preferred if the destination automation account is one without any custom resources as it prevents potential resource clash due to same name and loss of data.
  1. Ensure that the system assigned managed identities are enabled in the Automation account in the primary region.
- 1. Ensure that the system assigned managed identities of the primary Automation account has contributor access to the subscription it belongs to.
+ 1. Ensure that the system assigned managed identities of the primary Automation account have contributor access to the subscription it belongs to.
  1. Ensure that the primary Automation account's managed identity has Contributor access with read and write permissions to the Automation account in secondary region. To enable, provide the necessary permissions in secondary Automation account's managed identities. [Learn more](../role-based-access-control/quickstart-assign-role-user-portal.md).
  1. Ensure that the script has access to the Automation account assets in primary region. Hence, it should be executed as a runbook in that Automation account for successful migration.
  1. If the primary Automation account is deployed using a Run as account, then it must be switched to Managed Identity before migration. [Learn more](migrate-run-as-accounts-managed-identity.md).
@@ -148,10 +148,10 @@ Type[] | True | Array consisting of all the types of assets that need to be migr
 ---
 
 ### Limitations
-- The script migrates only Custom PowerShell modules. Default modules and Python packages would not be migrated to replica Automation account.
-- The script does not migrate **Schedules** and **Managed identities** present in Automation account in primary region. These would have to be created manually in replica Automation account.
-- Jobs data and activity logs would not be migrated to the replica account.
+- The script migrates only Custom PowerShell modules. Default modules and Python packages wouldn't be migrated to replica Automation account.
+- The script doesn't migrate **Schedules** and **Managed identities** present in Automation account in primary region. These would have to be created manually in replica Automation account.
+- Jobs data and activity logs wouldn't be migrated to the replica account.
 
 ## Next steps
 
-- Learn more about [regions that support availability zones](../availability-zones/az-region.md).
+- Learn more about [regions that support availability zones](../reliability/availability-zones-region-support.md).

articles/api-management/media/get-started-create-service-instance/get-started-create-service-instance-created-1.png

@@ -115,7 +115,7 @@ sections:
         answer: |
           Azure App Configuration supports [geo-replication](./concept-geo-replication.md) for enhanced resiliency to regional outages.
 
-          Azure App Configuration supports Azure availability zones to protect your application and data from single datacenter failures. All availability zone enabled regions consist of a minimum of three availability zones, where each is a physically independent datacenter. For resiliency, this support in App Configuration is enabled for all customers at no extra cost. Following are regions that App Configuration has enabled availability zone support. For more information, see [Regions and Availability Zones in Azure.](../reliability/availability-zones-service-support.md)
+          Azure App Configuration supports Azure availability zones to protect your application and data from single datacenter failures. All availability zone enabled regions consist of a minimum of three availability zones, where each is a physically independent datacenter. For resiliency, this support in App Configuration is enabled for all customers at no extra cost. Following are regions that App Configuration has enabled availability zone support. For more information, see [Azure regions with availability zone support](../reliability/availability-zones-region-support.md).
           
           [!INCLUDE [Azure App Configuration availability zones table](../../includes/azure-app-configuration-availability-zones.md)]