Merge pull request #288146 from MicrosoftDocs/main

10/9/2024 PM Publish

Author: Taojunshen

articles/app-service/app-service-plan-manage.md

@@ -50,7 +50,9 @@ You can create an empty App Service plan, or you can create a plan as part of ap
 
 ## Move an app to another App Service plan
 
-You can move an app to another App Service plan, as long as the source plan and the target plan are in the _same resource group and geographical region and of the same OS type_. Any change in type, such as Windows to Linux or any type that's different from the originating type, isn't supported.
+You can move an app to another App Service plan, as long as the source plan and the target plan are in the _same resource group and geographical region and of the same OS type_. Any change in type, such as Windows to Linux or any type that's different from the originating type, isn't supported. 
+
+Any VNET integration configured on the app must be disabled prior to changing App Service plans. 
 
 
 > [!NOTE]

articles/azure-netapp-files/azure-netapp-files-delegate-subnet.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: how-to
-ms.date: 09/28/2023
+ms.date: 10/09/2024
 ms.author: anfdocs
 ---
 # Delegate a subnet to Azure NetApp Files 
@@ -14,20 +14,20 @@ You must delegate a subnet to Azure NetApp Files. When you create a volume, you
 
 ## Considerations
 
-* When creating the delegated subnet for Azure NetApp Files, the size of the subnet matters. A subnet with a /28 network mask provides (only) 11 usable IP addresses, which might be insufficient for certain use cases. In that case, you should plan for a larger delegated subnet. For instance, a subnet with a /26 network mask provides 59 and a /24 network mask provides 251 available IP addresses respectively. You should consider even larger subnets (for example, /23 network mask) in scenarios where application volume group for SAP HANA is used and where many volumes and storage endpoints are anticipated. The network mask of the delegated network can't be changed after the initial creation. Make sure to plan your VNet and delegated subnet sizes consciously. 
+* When creating the delegated subnet for Azure NetApp Files, the size of the subnet matters. A subnet with a /28 network mask provides (only) 11 usable IP addresses, which might be insufficient for certain use cases. In that case, you should plan for a larger delegated subnet. For instance, a subnet with a /26 network mask provides 59 and a /24 network mask provides 251 available IP addresses respectively. You should consider even larger subnets (for example, /23 network mask) in scenarios where application volume group for SAP HANA is used and where many volumes and storage endpoints are anticipated. The network mask of the delegated network can't be changed after the initial creation. Make sure to plan your virtual network (VNet) and delegated subnet sizes consciously. 
 * In each VNet, only one subnet can be delegated to Azure NetApp Files.   
    Azure enables you to create multiple delegated subnets in a VNet.  However, any attempts to create a new volume would fail if you use more than one delegated subnet.  
    You can have only a single delegated subnet in a VNet. A NetApp account can deploy volumes into multiple VNets, each having its own delegated subnet.  
-* You can't designate a network security group or service endpoint in the delegated subnet. Doing so causes the subnet delegation to fail.
+* If you're using Basic network features, you can't designate a network security group (NSG) or service endpoint in the delegated subnet. Doing so causes the subnet delegation to fail. To designate an NSG or service endpoint, [upgrade to Standard network features](configure-network-features.md).
 * Access to a volume from a globally peered virtual network isn't currently supported using Basic networks features. Global VNet peering is supported with Standard network features. For more information, see [Supported network topologies](azure-netapp-files-network-topologies.md#supported-network-topologies).
 * For Azure NetApp Files support of [User-defined routes](../virtual-network/virtual-networks-udr-overview.md#custom-routes) (UDRs) and Network security groups (NSGs), see [Constraints in Guidelines for Azure NetApp Files network planning](azure-netapp-files-network-topologies.md#constraints).   
    To establish routing or access control ***to*** the Azure NetApp Files delegated subnet, you can apply UDRs and NSGs to other subnets, even within the same VNet as the subnet delegated to Azure NetApp Files.  
 
 ## Steps
 
-1.	Go to the **Virtual networks** blade in the Azure portal and select the virtual network that you want to use for Azure NetApp Files.    
+1.	Navigate to **Virtual networks** in the Azure portal. Select the virtual network that you want to use for Azure NetApp Files.    
 
-1. Select **Subnets** from the Virtual network blade and click the **+Subnet** button. 
+1. From Virtual network, select  **Subnets** then the **+Subnet** button. 
 
 1. Create a new subnet to use for Azure NetApp Files by completing the following required fields in the Add Subnet page:
     * **Name**: Specify the subnet name.

articles/azure-netapp-files/cross-region-replication-introduction.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 10/01/2024
+ms.date: 10/09/2024
 ms.author: anfdocs
 ms.custom: references_regions
 ---
@@ -48,13 +48,14 @@ Azure NetApp Files volume replication is supported between various [Azure region
 | Geography | Regional Pair A | Regional Pair B  |
 |:--- |:--- |:--- |
 | Australia/Southeast Asia | Australia East | Southeast Asia |
+| Israel/Sweden | Israel Central | Sweden Central | 
+| Qatar/Europe | Qatar Central | West Europe |
 | France/Europe | France Central | West Europe |
 | Germany/UK | Germany West Central | UK South |
 | Germany/Europe | Germany West Central | West Europe | 
 | Germany/France | Germany West Central | France Central |
-| Spain/Sweden | Spain Central | Sweden Central |
 | Sweden/Germany | Sweden Central | Germany West Central |
-| Qatar/Europe | Qatar Central | West Europe |
+| Spain/Sweden | Spain Central | Sweden Central |
 | North America | East US | East US 2 |
 | North America | East US 2| West US 2 |
 | North America | East US 2 | West US 3 |

articles/azure-vmware/request-host-quota-azure-vmware-solution.md

@@ -38,16 +38,17 @@ You need an Azure account in an Azure subscription that adheres to one of the fo
    > If the *Problem Type* is not is not visible from the short-list offered, select **None of the Above**. *AVS Quota requests* will be in the offered list of *Problem Types*.
 
 1. In the **Description** of the support ticket, on the **Details** tab, provide information for:
- 
+
    - Region Name
    - Number of hosts
    - Host SKU type
-   - Any other details, including Availability Zone requirements for integrating with other Azure services; for example, Azure NetApp Files, Azure Blob Storage.
-
-   >[!NOTE]
+   - Any other details, including Stretched Cluster, Availability Zone requirements for integrating with other Azure services; for example, Azure NetApp Files, Azure Blob Storage.
+      
+   > [!NOTE]
    > - Azure VMware Solution requires a minimum of three hosts and recommends redundancy of N+1 hosts.
-   > - **New** The unused quota expires after 30 days. A new request will need to be submitted for any additional quota.
-
+   > - Any unused quota expires after 30 days. A new request will need to be submitted for any additional quota.
+   > - **NEW** If requesting quota to leverage Portable [VMware Cloud Foundation (VCF)](/azure/azure-vmware/vmware-cloud-foundations-license-portability) pricing, add the following statement as is, by replacing \<N\> with the Number of VCF cores you have purchased from Broadcom for license portability to Azure VMware Solution.
+    ***"I acknowledge that I have procured portable VCF license from Broadcom for \<N\> cores to use with Azure VMware Solution."***  
 1. Select **Review + Create** to submit the request.
 
 
@@ -95,14 +96,16 @@ Access the Azure portal using the **Admin On Behalf Of (AOBO)** procedure from P
 
       - Region Name
       - Number of hosts
+      - Host SKU type
       - Any other details, including Availability Zone requirements for integrating with other Azure services; for example, Azure NetApp Files, Azure Blob Storage.
       - Is intended to host multiple customers?
-   
-      >[!NOTE]
+
+      > [!NOTE]
       > - Azure VMware Solution requires a minimum of three hosts and recommends redundancy of N+1 hosts.
-      > - **New** The unused quota expires after 30 days. A new request will need to be submitted for any additional quota.
-   
-   1. Select **Review + Create** to submit the request.
+      > - Any unused quota expires after 30 days. A new request will need to be submitted for any additional quota.
+      > - **NEW** If requesting quota to leverage Portable [VMware Cloud Foundation (VCF)](/azure/azure-vmware/vmware-cloud-foundations-license-portability) pricing, add the following statement as is, by replacing \<N\> with the Number of VCF cores you have purchased from Broadcom for license portability to Azure VMware Solution.
+        ***"I acknowledge that I have procured portable VCF license from Broadcom for \<N\> cores to use with Azure VMware Solution."***
+1. Select **Review + Create** to submit the request.
 
 
 ## Next steps

articles/backup/azure-kubernetes-service-cluster-restore.md

@@ -16,8 +16,8 @@ This article describes how to restore backed-up Azure Kubernetes Service (AKS).
 
 Azure Backup now allows you to back up AKS clusters (cluster resources and persistent volumes attached to the cluster) using a backup extension, which must be installed in the cluster. Backup vault communicates with the cluster via this Backup Extension to perform backup and restore operations. 
 
->[!Note]
->Vaulted backup and Cross Region Restore for AKS using Azure Backup are currently in preview.
+> [!NOTE]
+> Vaulted backup and Cross Region Restore for AKS using Azure Backup are currently in preview.
 
 ## Before you start
 
@@ -33,97 +33,37 @@ For more information on the limitations and supported scenarios, see the [suppor
 
 To restore the backed-up AKS cluster, follow these steps:
 
-1. Go to **Backup center** and select **Restore**.
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/start-kubernetes-cluster-restore.png" alt-text="Screenshot shows how to start the restore process.":::
-
-2. On the next page, select **Select backup instance**, and then select the *instance* that you want to restore.
-
-   If the instance is available in both *Primary* and *Secondary Region*, select the *region to restore* too, and then select **Continue**.
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/select-backup-instance-for-restore.png" alt-text="Screenshot shows selection of backup instance for restore.":::
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/choose-instances-for-restore.png" alt-text="Screenshot shows choosing instances for restore.":::
-   
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/starting-kubernetes-restore.png" alt-text="Screenshot shows starting restore.":::
-
-3. Click **Select restore point** to select the *restore point* you want to restore. 
-
-   If the restore point is available in both Vault and Operation datastore, select the one you want to restore from.
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/select-restore-points-for-kubernetes.png" alt-text="Screenshot shows how to view the restore points.":::
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/choose-restore-points-for-kubernetes.png" alt-text="Screenshot shows selection of a restore point.":::
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/open-restore-page.png" alt-text="Screenshot shows how to go to the Restore page.":::
-
-
-4. In the **Restore parameters** section, click **Select Kubernetes Service** and select the *AKS cluster* to which you want to restore the backup to.
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/parameter-selection.png" alt-text="Screenshot shows how to initiate parameter selection.":::
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/select-kubernetes-service-parameter.png" alt-text="Screenshot shows selection of parameter Kubernetes Service.":::
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/set-for-restore-after-parameter-selection.png" alt-text="Screenshot shows the Restore page with the selection of Kubernetes parameter.":::
-
-5. To select the *backed-up cluster resources* for restore, click **Select resources**.
-
-   Learn more about [restore configurations](#restore-configurations).
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/select-resources-to-restore-page.png" alt-text="Screenshot shows the Select Resources to restore page.":::
-
-6. If you selected a recovery point for restore from *Vault-standard datastore*, then provide a *snapshot resource group* and *storage account* as the staging location.
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/restore-parameters.png" alt-text="Screenshot shows the parameters to add for restore from Vault-standard storage.":::
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/restore-parameter-storage.png" alt-text="Screenshot shows the storage parameter to add for restore from Vault-standard storage.":::
-
->[!Note]
->Currently, resources created in the staging location can't belong within a Private Endpoint. Ensure that you enable _public access_ on the storage account provided as a staging location.
-
-7. Select **Validate** to run validation on the cluster selections for restore.
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/validate-restore-parameters.png" alt-text="Screenshot shows the validation of restore parameters.":::
-
-
-8. Once the validation is successful, select **Review + restore** and restore the backups to the selected cluster.
-
-   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/review-restore-tab.png" alt-text="Screenshot shows the Review + restore tab for restore.":::
+1. In the Azure portal, navigate to your AKS cluster resource.
+1. From the service menu, under **Settings**, select **Backup** > **Restore**.
+1. On the *Start: Restore* page, select **Select backup instance**, select the *instance* that you want to restore, and then select **Select** > **Continue**.
+1. On the *Basics* tab of the *Restore* page, select the *Restore Region* you want to restore the backup to, and then select **Next: Restore point**.
+1. Select **Select restore point**, select the *restore point* you want to restore from, and then select **Select** > **Next: Restore parameters**.
+1. On the *Restore parameters* tab, ensure that the *AKS cluster* is selected as the *restore target*, and then select **Validate**.
+1. Once the validation completes, select **Next: Review + restore** > **Restore**.
 
 ### Restore configurations
 
-As part of item-level restore capability of AKS backup, you can utilize multiple restore configuration filters   to perform restore.
+As part of item-level restore capability of AKS backup, you can utilize multiple restore configuration filters to perform restore.
 
-- Select the *Namespaces* that you want to restore from the list. The list shows only the backed-up Namespaces. 
+- On the *Restore parameters* tab, next to *Restore configuration*, select **Select resources**, and select the *Namespaces* that you want to restore from the list. The list shows only the backed-up namespaces.
 
   :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/select-namespace.png" alt-text="Screenshot shows selection of Namespace.":::
 
-  You can also select the checkboxes if you want to restore cluster scoped resources and persistent volumes (of Azure Disk only).
-
-  To restore specific cluster resources, use the labels attached to them in the textbox. Only resources with the entered labels are backed up.
-
 - You can provide *API Groups* and *Kinds* to restore specific resource types. The list of *API Group* and *Kind* is available in the *Appendix*. You can enter *multiple API Groups*.
+- To restore a workload, such as Deployment from a backup via API Group, the entry should be:
 
-  :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/use-api-for-restore.png" alt-text="Screenshot shows the usage of API for restore.":::
-
-- To restore a workload, such as Deployment from a backup via API Group, the entry should be: 
-
-   - **Kind**: Select **Deployment**.
-   - **Group**: Select **Group**.
-   - **Namespace Mapping**: To migrate the backed-up cluster resources to a different *Namespace*, select the *backed-up Namespace*, and then enter the *Namespace* to which you want to migrate the resources.
-
-     If the *Namespace* doesn't exist in the AKS cluster, it gets created. If a conflict occurs during the cluster resources restore, you can skip or patch the conflicting resources.
-   
-     :::image type="content" source="./media/azure-kubernetes-service-cluster-restore/select-backed-up-namespace-for-migrate.png" alt-text="Screenshot shows the selection of namespace for migration.":::
+  - **Kind**: Select **Deployment**.
+  - **Group**: Select **Group**.
+  - **Namespace Mapping**: To migrate the backed-up cluster resources to a different *Namespace*, select the *backed-up Namespace*, and then enter the *Namespace* to which you want to migrate the resources.
 
 Azure Backup for AKS currently supports the following two options when doing a restore operation when resource clash happens (backed-up resource has the same name as the resource in the target AKS cluster). You can choose one of these options when defining the restore configuration.
 
 - **Skip**: This option is selected by default. For example, if you backed up a PVC named *pvc-azuredisk* and you're restoring it in a target cluster that has the PVC with the same name, then the backup extension skips restoring the backed-up persistent volume claim (PVC). In such scenarios, we recommend you to delete the resource from the cluster, and then do the restore operation.
 
-- **Patch**: This option allows the patching mutable variable in the backed-up resource on the resource in the target cluster. If you want to update the number of replicas in the target cluster, you can opt for patching as an operation. 
+- **Patch**: This option allows the patching mutable variable in the backed-up resource on the resource in the target cluster. If you want to update the number of replicas in the target cluster, you can opt for patching as an operation.
 
->[!Note]
->AKS backup currently doesn't delete and recreate resources in the target cluster if they already exist. If you attempt to restore Persistent Volumess in the original location, delete the existing Persistent Volumes, and then do the restore operation.
+> [!NOTE]
+> AKS backup currently doesn't delete and recreate resources in the target cluster if they already exist. If you attempt to restore Persistent Volumes in the original location, delete the existing Persistent Volumes, and then do the restore operation.
 
 ## Restore in secondary region (preview)