Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into ga-multi-ad

Author: b-ahibbard

articles/api-management/api-management-howto-developer-portal-customize.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: tutorial
-ms.date: 03/29/2024
+ms.date: 04/28/2025
 ms.author: danlep
 ms.custom: engagement-fy23
 ---
@@ -28,7 +28,7 @@ In this tutorial, you learn how to:
 
 For more information about developer portal features and options, see [Azure API Management developer portal overview](developer-portal-overview.md).
 
-:::image type="content" source="media/api-management-howto-developer-portal-customize/cover.png" alt-text="Screenshot of the API Management developer portal - administrator mode." border="false":::
+:::image type="content" source="media/api-management-howto-developer-portal-customize/cover.png" alt-text="Screenshot of the API Management developer portal - administrator mode." :::
 
 ## Prerequisites
 
@@ -49,6 +49,8 @@ Follow these steps to access the managed version of the developer portal.
     It might take a few minutes to enable the developer portal.
 1. In the left menu, under **Developer portal**, select **Portal overview**. Then select the **Developer portal** button in the top navigation bar. A new browser tab with an administrative version of the portal will open.
 
+[!INCLUDE [developer-portal-editor-refresh](../../includes/developer-portal-editor-refresh.md)] 
+
 ## Understand the portal's administrative interface
 
 [!INCLUDE [api-management-developer-portal-editor](../../includes/api-management-developer-portal-editor.md)]
@@ -70,7 +72,7 @@ You'll want to use your own images and other media content in the developer port
 
 A placeholder logo is provided in the top left corner of the navigation bar. You can replace it with your own logo to match your organization's branding.
 
-1. In the developer portal, select the default **Contoso** logo in the top left of the navigation bar. 
+1. In the developer portal, select the default logo in the top left of the navigation bar. 
 1. Select **Edit**. 
 1. In the **Picture** pop-up, under **Main**, select **Source**.
 1. In the **Media** pop-up, select one of the following:

articles/api-management/developer-portal-overview.md

@@ -7,7 +7,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: concept-article
-ms.date: 03/29/2024
+ms.date: 04/28/2025
 ms.author: danlep 
 ---
 
@@ -76,21 +76,18 @@ The developer portal's administrative interface provides a visual editor for pub
 
 [!INCLUDE [api-management-developer-portal-add](../../includes/api-management-developer-portal-add.md)]
 
-[!INCLUDE [api-management-developer-portal-wordpress](../../includes/api-management-developer-portal-wordpress.md)]
+### Pages and layouts
 
+The pre-provisioned content in the developer portal showcases pages with commonly used features. Find them on the **Pages** panel. You can modify the content of these pages or add new ones to suit your needs.
 
-### Layouts and pages
-
-Layouts define how pages are displayed. For example, in the default content, there are two layouts: one applies to the home page, and the other to all remaining pages. You can modify these layouts and add more layouts to suit your needs.
+Select **Layouts** on the **Pages** panel to define how pages are displayed. The developer portal comes with a default layout that's applied to the pages. You can modify this layout and add more layouts to suit your needs.
 
 A layout gets applied to a page by matching its URL template to the page's URL. For example, a layout with a URL template of `/wiki/*` is applied to every page with the `/wiki/` segment in the URL: `/wiki/getting-started`, `/wiki/styles`, etc.
 
 In the following image, content belonging to the layout is outlined in blue, while the page-specific content is outlined in red. 
 
 :::image type="content" source="media/developer-portal-overview/pages-layouts.png" alt-text="Screenshot of layout content in the developer portal." :::
 
-The pre-provisioned content in the developer portal showcases pages with commonly used features. You can modify the content of these pages or add new ones to suit your needs.
-
 > [!NOTE]
 > Due to integration considerations, the following pages can't be removed or moved under a different URL: `/404`, `/500`, `/captcha`, `/change-password`, `/config.json`, `/confirm/invitation`, `/confirm-v2/identities/basic/signup`, `/confirm-v2/password`, `/internal-status-0123456789abcdef`, `/publish`, `/signin`, `/signin-sso`, `/signup`.
 
@@ -248,7 +245,8 @@ To restore a previous portal revision:
 If you want to discard all changes you've made to the developer portal, you can reset the website to its starting state. Resetting the portal deletes any changes you've made to the developer portal pages, layouts, customizations, and uploaded media.
 
 > [!NOTE]
-> Resetting the developer portal doesn't delete the published version of the developer portal.
+> * Resetting the developer portal doesn't delete the published version of the developer portal.
+> * Resetting the portal could update the portal to a newer version of the developer portal codebase with updated components. The placeholder content that appears might also be changed. Developer portal features and customization options remain consistent. 
 
 To reset the developer portal:
 

articles/api-management/media/api-management-howto-developer-portal-customize/cover.png

@@ -4,7 +4,7 @@ description: Learn how to create and use hybrid connections in Azure App Service
 author: madsd
 ms.assetid: 66774bde-13f5-45d0-9a70-4e9536a4f619
 ms.topic: article
-ms.date: 04/10/2025
+ms.date: 04/29/2025
 ms.author: madsd
 ms.custom: "UpdateFrequency3, fasttrack-edit"
 #customer intent: As an app developer, I want to understand the usage of Hybrid Connections to provide access to apps in Azure App Service.
@@ -237,10 +237,10 @@ The status of **Connected** means that at least one HCM is configured with that
 
     :::image type="content" source="media/app-service-hybrid-connections/hybrid-connections-service-bus-endpoint.png" alt-text="Screenshot of Hybrid Connection Service Bus endpoint.":::
 
-  - The Service Bus gateways are the resources that accept the request into the Hybrid Connection and pass it through the Azure Relay. You need to allowlist all 128 of the gateways. The gateways are in the format: `G#-prod-[stamp]-sb.servicebus.windows.net`. The number sign, `#`, is a number between 0 and 127 and `stamp` is the name of the instance within your Azure data center where your Service Bus endpoint exists.
+  - The Service Bus gateways are the resources that accept the request into the Hybrid Connection and pass it through the Azure Relay. You need to allowlist all of the gateways. The gateways are in the format: `G#-prod-[stamp]-sb.servicebus.windows.net` and `GV#-prod-[stamp]-sb.servicebus.windows.net`. The number sign, `#`, is a number between 0 and 127 and `stamp` is the name of the instance within your Azure data center where your Service Bus endpoint exists.
 
   - If you can use a wildcard, you can allowlist *\*.servicebus.windows.net*.
-  - If you can't use a wildcard, you must allowlist all 128 gateways.
+  - If you can't use a wildcard, you must allowlist all 256 of the gateways.
 
     You can find out the stamp using *nslookup* on the Service Bus endpoint URL.
 
@@ -255,6 +255,13 @@ The status of **Connected** means that at least one HCM is configured with that
     ...
     G126-prod-sn3-010-sb.servicebus.windows.net  
     G127-prod-sn3-010-sb.servicebus.windows.net
+    GV0-prod-sn3-010-sb.servicebus.windows.net  
+    GV1-prod-sn3-010-sb.servicebus.windows.net  
+    GV2-prod-sn3-010-sb.servicebus.windows.net  
+    GV3-prod-sn3-010-sb.servicebus.windows.net  
+    ...
+    GV126-prod-sn3-010-sb.servicebus.windows.net  
+    GV127-prod-sn3-010-sb.servicebus.windows.net
 
 If your status says **Connected** but your app can't reach your endpoint then:
 

articles/api-management/media/api-management-howto-developer-portal-customize/preview-new-ui.png

@@ -4,7 +4,7 @@ description: Learn how to scale automatically in Azure App Service with no confi
 author: msangapu-msft
 ms.author: msangapu
 ms.topic: how-to
-ms.date: 03/01/2024
+ms.date: 04/18/2025
 ms.custom: devx-track-azurecli
 
 ---
@@ -15,18 +15,20 @@ ms.custom: devx-track-azurecli
 > Automatic scaling is available for all app types: Windows and Linux (deploy as code and container). Automatic scaling isn't supported for deployment slot traffic.
 >
 
-Automatic scaling is a new scale-out option that automatically handles scaling decisions for your web apps and App Service plans. It's different from the preexisting **[Azure autoscale](/azure/azure-monitor/autoscale/autoscale-overview)**, which lets you define scaling rules based on schedules and resources. With automatic scaling, you can adjust scaling settings to improve your app's performance and avoid cold start issues. The platform prewarms instances to act as a buffer when scaling out, ensuring smooth performance transitions. You're charged per second for every instance, including prewarmed instances.
+Automatic scaling is a scale-out option that automatically handles scaling decisions for your web apps and App Service plans. It's different from **[Azure autoscale](/azure/azure-monitor/autoscale/autoscale-overview)**, which lets you define scaling rules based on schedules and resources.
+
+With automatic scaling, you can adjust scaling settings to improve your app's performance and avoid cold start issues. The platform prewarms instances to act as a buffer when scaling out, ensuring smooth performance transitions. You're charged per second for every instance, including prewarmed instances.
 
 The following table compares scale-out and scale-in options available on App Service:
 
 | | **Manual** | **Autoscale** | **Automatic scaling** |
 | --- | --- | --- | --- |
-| Available pricing tiers	| Basic and up. | Standard and up. | Premium V2 (P1V2, P2V2 and P3V2) pricing tiers. Premium V3 (P0V3, P1V3, P2V3, P3V3, P1MV3, P2MV3, P3MV3, P4MV3 and P5MV3) pricing tiers.|
-|Rule-based scaling	|No.	|Yes	|No, the platform manages out the scale and scale in based on HTTP traffic. |
-|Schedule-based scaling	|No.	|Yes.	|No.|
-|Always-ready instances | No, your web app runs on the number of manually scaled instances.	| No, your web app runs on other instances available during the scale-out operation, based on the threshold defined for autoscale rules. | Yes (minimum 1). |
-|Prewarmed instances	|No.	|No.	|Yes (default 1). |
-|Per-app maximum	|No.	|No.	|Yes.|
+| Available pricing tiers | Basic and up | Standard and up | Premium V2 (P1V2, P2V2, and P3V2) pricing tiers. Premium V3 (P0V3, P1V3, P2V3, P3V3, P1MV3, P2MV3, P3MV3, P4MV3, and P5MV3) pricing tiers.|
+|Rule-based scaling |No |Yes   |No, the platform manages the scale-out and scale-in based on HTTP traffic. |
+|Schedule-based scaling |No |Yes |No |
+|Always-ready instances | No, your web app runs on the number of manually scaled instances. | No, your web app runs on other instances available during the scale-out operation, based on the threshold defined for autoscale rules. | Yes (minimum 1) |
+|Prewarmed instances |No |No |Yes (default 1) |
+|Per-app maximum |No |No |Yes |
 
 ## How automatic scaling works
 
@@ -40,11 +42,11 @@ Here are a few scenarios where you should scale out automatically:
 
 ## Enable automatic scaling
 
-The **Maximum burst** level represents the highest number of instances that your App Service plan can increase to based on incoming HTTP requests. For Premium v2 & v3 plans, you can set **Maximum burst** to up to 30 instances. The **Maximum burst** number must be equal to or greater than the number of workers specified for the App Service plan.
+The **Maximum burst** setting represents the highest number of instances that your App Service plan can increase to based on incoming HTTP requests. For Premium v2 & v3 plans, you can specify up to 30 instances. The maximum burst number must be equal to or greater than the number of workers specified for the App Service plan.
 
 #### [Azure portal](#tab/azure-portal)
 
-To enable automatic scaling, go to the web app's left menu and select **scale-out (App Service Plan)**. Select **Automatic**, update the **Maximum burst** value, and select the **Save** button.
+To enable automatic scaling, go to the web app's left menu. Under **Settings**, select **Scale-out (App Service plan)**. Select **Automatic**, update the **Maximum burst** value, and select the **Save** button.
 
 :::image type="content" source="./media/manage-automatic-scaling/azure-portal-automatic-scaling.png" alt-text="Screenshot that shows automatic scaling in Azure portal" :::
 
@@ -57,7 +59,7 @@ az appservice plan update --name <APP_SERVICE_PLAN> --resource-group <RESOURCE_G
 ```
 
 >[!NOTE]
-> If you receive the error message "Operation returned an invalid status 'Bad Request'," try using a different resource group or create a new one.
+> If you receive the error message `Operation returned an invalid status 'Bad Request'`, try using a different resource group or create a new one.
 >
 
 ---
@@ -68,11 +70,14 @@ The app-level setting **Always ready instances** specifies the minimum number of
 
 #### [Azure portal](#tab/azure-portal)
 
-To set the minimum number of web app instances, go to the web app's left menu and select **scale-out (App Service Plan)**. Update the **Always ready instances** value, and select the **Save** button.
+To set the minimum number of web app instances, go to the web app's left menu and select **Scale-out (App Service plan)**. Update the **Always ready instances** value, and select the **Save** button.
 
 :::image type="content" source="./media/manage-automatic-scaling/azure-portal-always-ready-instances.png" alt-text="Screenshot of always-ready instances." :::
 
 #### [Azure CLI](#tab/azure-cli)
+
+To set the minimum number of web app instances, use the following command:
+
 ```azurecli-interactive
  az webapp update --resource-group <RESOURCE_GROUP> --name <APP_NAME> --minimum-elastic-instance-count <ALWAYS_READY_COUNT> 
 ```
@@ -81,11 +86,11 @@ To set the minimum number of web app instances, go to the web app's left menu an
 
 ## Set the maximum number of web app instances
 
-The **Maximum scale limit** value sets the maximum number of instances a web app can scale to. The **Maximum scale limit** is helpful when a downstream component like a database has limited throughput. The per-app maximum can be between 1 and the **Maximum burst**.
+The **Maximum scale limit** value sets the maximum number of instances a web app can scale to. The **Maximum scale limit** is helpful when a downstream component like a database has limited throughput. The per-app maximum can be between 1 and the maximum burst value.
 
 #### [Azure portal](#tab/azure-portal)
 
-To set the maximum number of web app instances, go to the web app's left menu and select **scale-out (App Service Plan)**. Select **Enforce scale-out limit**, update the **Maximum scale limit**, and select the **Save** button.
+To set the maximum number of web app instances, go to the web app's left menu and select **Scale-out (App Service plan)**. Select **Enforce scale-out limit**, update the **Maximum scale limit**, and select the **Save** button.
 
 :::image type="content" source="./media/manage-automatic-scaling/azure-portal-maximum-scale-limit.png" alt-text="Screenshot of maximum scale limit." :::
 
@@ -97,7 +102,7 @@ Currently, you can't change the **Maximum scale limit** in the Azure CLI. You mu
 
 ## Update prewarmed instances
 
-The **prewarmed instance** setting provides warmed instances as a buffer during HTTP scale and activation events. Prewarmed instances continue to buffer until the maximum scale-out limit is reached. The default **prewarmed instance** count is 1 and, for most scenarios, this value should remain as 1.
+The prewarmed instance setting provides warmed instances as a buffer during HTTP scale and activation events. Prewarmed instances continue to buffer until the maximum scale-out limit is reached. The default prewarmed instance count is *1* and, for most scenarios, this value should remain as 1.
 
 #### [Azure portal](#tab/azure-portal)
 
@@ -117,7 +122,7 @@ You can modify the number of prewarmed instances for an app by using the Azure C
 
 #### [Azure portal](#tab/azure-portal)
 
-To disable automatic scaling, go to the web app's left menu and select **scale-out (App Service Plan)**. Select **Manual** and select the **Save** button.
+To disable automatic scaling, go to the web app's left menu and select **Scale-out (App Service plan)**. Select **Manual** and select the **Save** button.
 
 :::image type="content" source="./media/manage-automatic-scaling/azure-portal-manual-scaling.png" alt-text="Screenshot of manual scaling." :::
 
@@ -141,6 +146,7 @@ No, you can only have Azure App Service web apps in the App Service plan in whic
 >
 
 ### How does automatic scaling work behind the scenes?
+
 Applications set to automatically scale are continuously monitored, with worker health assessments occurring at least once every few seconds. If the system detects increased load on the application, health checks become more frequent. If worker health deteriorates and requests slow down, other instances are requested. The speed at which instances are added varies based on the individual application's load pattern and startup time. Applications with brief startup times and intermittent bursts of load might see one virtual machine added every few seconds to a minute.
 
 Once the load subsides, the platform initiates a review for potential scaling in. This process typically begins about 5-10 minutes after the load stops increasing. During scaling in, instances are removed at a maximum rate of one every few seconds to a minute.
@@ -168,11 +174,12 @@ If your web app returns a 5xx status, these endpoint pings might result in inter
 ### How do I track the number of scaled-out instances during the automatic scaling event?
 
 The `AutomaticScalingInstanceCount` metric reports the number of virtual machines on which the app is running, including the prewarmed instance if it's deployed. This metric can also be used to track the maximum number of instances your web app scaled out during an automatic scaling event. This metric is available only for the apps that have **Automatic Scaling** enabled.
+
 ### How does ARR Affinity affect automatic scaling?
 
 Azure App Service uses Application Request Routing cookies known as an ARR Affinity. ARR Affinity cookies restrict scaling because they send requests only to servers associated with the cookie, rather than any available instance. For apps that store state, it's better to scale up (increase resources on a single instance). For stateless apps, scaling out (adding more instances) offers more flexibility and scalability. ARR Affinity cookies are enabled by default on App Service. Depending on your application needs, you might choose to disable ARR affinity cookies when using automatic scaling.
 
-To disable ARR Affinity cookies: select your App Service app, and under **Settings**, select **Configuration**. Next select the **General settings** tab. Under **ARR affinity**, select **Off** and then select the **Save** button.
+To disable ARR Affinity cookies: select your App Service app, and under **Settings**, select **Configuration**. Next select the **General settings** tab. Under **Session affinity**, select **Off** and then select the **Save** button.
 
 <a name="Related content"></a>