Merge pull request #285860 from MicrosoftDocs/main

8/29/2024 PM Publish

Author: Taojunshen

articles/api-management/breaking-changes/overview.md

@@ -26,7 +26,7 @@ The following table lists all the upcoming breaking changes and feature retireme
 | [API version retirements][api2023] | June 1, 2024 |
 | [Workspaces preview breaking changes][workspaces2024] | June 14, 2024 |
 | [stv1 platform retirement - Global Azure][stv12024] | August 31, 2024 |
-| [stv1 platform retirement - Azure Government, Azure in China][stv1sov2025] | February 25, 2025 |
+| [stv1 platform retirement - Azure Government, Azure in China][stv1sov2025] | February 24, 2025 |
 | [Git repository retirement][git2025] | March 15, 2025 |
 | [Direct management API retirement][mgmtapi2025] | March 15, 2025 |
 | [Workspaces preview breaking changes, part 2][workspaces2025march] | March 31, 2025 |

articles/api-management/breaking-changes/stv1-platform-retirement-august-2024.md

@@ -5,7 +5,7 @@ services: api-management
 author: dlepow
 ms.service: azure-api-management
 ms.topic: reference
-ms.date: 08/08/2024
+ms.date: 08/28/2024
 ms.author: danlep
 ---
 
@@ -24,11 +24,11 @@ The following table summarizes the compute platforms currently used for instance
 | -------| ----------| ----------- | ---- |
 | `stv2` | Single-tenant v2 | Azure-allocated compute infrastructure that supports availability zones, private endpoints | Developer, Basic, Standard, Premium |
 | `stv1` |  Single-tenant v1 | Azure-allocated compute infrastructure |  Developer, Basic, Standard, Premium | 
-| `mtv1` | Multi-tenant v1 |  Shared infrastructure that supports native autoscaling and scaling down to zero in times of no traffic |  Consumption |
+| `mtv1` | Multitenant v1 |  Shared infrastructure that supports native autoscaling and scaling down to zero in times of no traffic |  Consumption |
 
 **For continued support and to take advantage of upcoming features, customers must [migrate](../migrate-stv1-to-stv2.md) their Azure API Management instances from the `stv1` compute platform to the `stv2` compute platform.** The `stv2` compute platform comes with additional features and improvements such as support for Azure Private Link and other networking features. 
 
-New instances created in service tiers other than the Consumption tier are mostly hosted on the `stv2` platform already. Existing instances on the `stv1` compute platform will continue to work normally until the retirement date, but those instances won’t receive the latest features available to the `stv2` platform. Support for `stv1` instances will be retired by 31 August 2024.  
+New instances created in service tiers other than the Consumption tier are mostly hosted on the `stv2` platform already. Existing instances on the `stv1` compute platform will continue to work normally until the retirement date, but those instances won't receive the latest features available to the `stv2` platform. Support for `stv1` instances will be retired by 31 August 2024.  
 
 ## Is my service affected by this?
 
@@ -38,17 +38,31 @@ If the value of the `platformVersion` property of your service is `stv1`, it's h
 
 Support for API Management instances hosted on the `stv1` platform will be retired by 31 August 2024.
 
-> [!WARNING]
-> If your instance is currently hosted on the `stv1` platform, you must migrate to the `stv2` platform. Failure to migrate by the retirement date might result in loss of the environments running APIs and all configuration data.
-
 ## What do I need to do?
 
-**Migrate all your existing instances hosted on the `stv1` compute platform to the `stv2` compute platform by 31 August 2024.**  
+**Migrate all your existing instances hosted on the `stv1` compute platform to the `stv2` compute platform.**  
 
 If you have existing instances hosted on the `stv1` platform, follow our **[migration guide](../migrate-stv1-to-stv2.md)** to ensure a successful migration. 
 
+## What happens after 31 August 2024?
+
+**Your `stv1` instance will not be shut down, deactivated, or deleted.** However, the SLA commitment for the instance ends, and any `stv1` instance after the retirement date will be scheduled for automatic migration to the `stv2` platform.
+
+### End of SLA commitment for `stv1` instances
+
+As of 1 September 2024, API Management will no longer provide any service level guarantees, and by extension service credits, for performance or availability issues related to the Developer, Basic, Standard, and Premium service instances running on the `stv1` compute platform. Also, no new security and compliance investments will be made in the API Management `stv1` platform. 
+
+Through continued use of an instance hosted on the `stv1` platform beyond the retirement date, you acknowledge that Azure does not commit to the SLA of 99.95% for the retired instances.
+
+### Automatic migration
+
+Starting 1 September 2024, we'll automatically migrate remaining `stv1` service instances to the `stv2` compute platform. All affected customers will be notified of the upcoming automatic migration a week in advance. Automatic migration might cause downtime for your upstream API consumers. You may still migrate your own instances before automatic migration takes place.
+
 [!INCLUDE [api-management-migration-support](../../../includes/api-management-migration-support.md)]
 
+> [!NOTE]
+> Azure support can't extend the timeline for automatic migration or for SLA support of `stv1` instances after the retirement date.
+
 ## Related content
 
 * [Migrate from stv1 platform to stv2](../migrate-stv1-to-stv2.md)

articles/api-management/breaking-changes/stv1-platform-retirement-sovereign-clouds-february-2025.md

@@ -5,7 +5,7 @@ services: api-management
 author: dlepow
 ms.service: azure-api-management
 ms.topic: reference
-ms.date: 08/09/2024
+ms.date: 08/28/2024
 ms.author: danlep
 ---
 
@@ -24,7 +24,7 @@ The following table summarizes the compute platforms currently used for instance
 | -------| ----------| ----------- | ---- |
 | `stv2` | Single-tenant v2 | Azure-allocated compute infrastructure that supports availability zones, private endpoints | Developer, Basic, Standard, Premium |
 | `stv1` |  Single-tenant v1 | Azure-allocated compute infrastructure |  Developer, Basic, Standard, Premium | 
-| `mtv1` | Multi-tenant v1 |  Shared infrastructure that supports native autoscaling and scaling down to zero in times of no traffic |  Consumption |
+| `mtv1` | Multitenant v1 |  Shared infrastructure that supports native autoscaling and scaling down to zero in times of no traffic |  Consumption |
 
 **For continued support and to take advantage of upcoming features, customers must [migrate](../migrate-stv1-to-stv2.md) their Azure API Management instances from the `stv1` compute platform to the `stv2` compute platform.** The `stv2` compute platform comes with additional features and improvements such as support for Azure Private Link and other networking features. 
 
@@ -38,14 +38,25 @@ If the value of the `platformVersion` property of your service is `stv1`, it's h
 
 In Azure Government and Azure operated by 21Vianet, support for API Management instances hosted on the `stv1` platform will be retired by 24 February 2025.
 
+Also, as of 1 September 2024, API Management will no longer back API Management instances running on the `stv1` compute platform with an SLA.
+
 ## What do I need to do?
 
 **Migrate all your existing instances hosted on the `stv1` compute platform to the `stv2` compute platform by 24 February 2025.**  
 
 If you have existing instances hosted on the `stv1` platform, follow our **[migration guide](../migrate-stv1-to-stv2.md)** to ensure a successful migration. 
 
+## End of SLA commitment for `stv1` instances - 1 September 2024
+
+As of 1 September 2024, API Management will no longer provide any service level guarantees, and by extension service credits, for performance or availability issues related to the Developer, Basic, Standard, and Premium service instances running on the `stv1` compute platform. Also, no new security and compliance investments will be made in the API Management `stv1` platform. 
+
+Through continued use of an instance hosted on the `stv1` platform beyond 1 September 2024, you acknowledge that Azure does not commit to the SLA of 99.95%.
+
+
 [!INCLUDE [api-management-migration-support](../../../includes/api-management-migration-support.md)]
 
+> [!NOTE]
+> Azure support can't extend the timeline for SLA support of `stv1` instances.
 
 ## Related content
 

articles/api-management/migrate-stv1-to-stv2-no-vnet.md

@@ -45,12 +45,17 @@ API Management platform migration from `stv1` to `stv2` involves updating the un
 
 ## Migrate the instance to stv2 platform
 
+### Public IP address options 
 You can choose whether the virtual IP address of API Management will change, or whether the original VIP address is preserved.
 
 * **New virtual IP address** - If you choose this mode, API requests remain responsive during migration. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 30 minutes. After migration, you'll need to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address. 
 
 * **Preserve IP address** - If you preserve the VIP address, API requests will be unresponsive for approximately 15 minutes while the IP address is migrated to the new infrastructure. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 45 minutes. No further configuration is required after migration.
 
+[!INCLUDE [api-management-migration-precreated-ip](../../includes/api-management-migration-precreated-ip.md)]
+
+### Migration steps
+
 #### [Portal](#tab/portal)
 
 1. In the [Azure portal](https://portal.azure.com), navigate to your API Management instance.

articles/api-management/migrate-stv1-to-stv2-vnet.md

@@ -36,9 +36,10 @@ If you need to migrate a *non-VNnet-injected* API Management hosted on the `stv1
 
 API Management platform migration from `stv1` to `stv2` involves updating the underlying compute alone and has no impact on the service/API configuration persisted in the storage layer.
 
-* The upgrade process involves creating a new compute in parallel to the old compute, which can take up to 45 minutes.
+* The upgrade process involves creating a new compute in parallel to the old compute, which can take up to 45 minutes. Plan longer times for multi-region deployments and in scenarios that involve changing the subnet more than once.
 * The API Management status in the Azure portal will be **Updating**.
 * For certain migration options, the VIP address (or addresses, for a multi-region deployment) of the instance will change. If you migrate and keep the same subnet configuration, you can choose to preserve the VIP address or a new public VIP will be generated. 
+    [!INCLUDE [api-management-migration-no-preserve-ip](../../includes/api-management-migration-no-preserve-ip.md)]
 * For migration scenarios when a new VIP address is generated:
     * Azure manages the migration. 
     * The gateway DNS still points to the old compute if a custom domain is in use. 
@@ -79,6 +80,8 @@ You can migrate your API Management instance to the `stv2` platform keeping the
 
 ### Public IP address options - same-subnet migration
 
+[!INCLUDE [api-management-migration-no-preserve-ip](../../includes/api-management-migration-no-preserve-ip.md)]
+
 You can choose whether the API Management instance's original VIP address is preserved (recommended) or whether a new VIP address will be generated. 
 
 * **Preserve virtual IP address** - If you preserve the VIP address in a VNet in external mode, API requests can remain responsive during migration (see [Expected downtime](#expected-downtime-and-compute-retention)); for a VNet in internal mode, temporary downtime is expected. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 45 minutes. No further configuration is required after migration. 
@@ -90,14 +93,7 @@ You can choose whether the API Management instance's original VIP address is pre
     With this option, the `stv1` compute is retained for a period by default after migration is complete so that you can validate the migrated instance and confirm the network and DNS configuration.  
 
 
-### Precreated IP address for migration
-
-API Management precreates a public IP address for the migration process. Find the precreated IP address in the JSON output of your API Management instance's properties. Under `customProperties`, the precreated IP address is the value of the `Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps` property. For a multi-region deployment, the value is a comma-separated list of precreated IP addresses.
-
-Use the precreated IP address (or addresses) to help you manage the migration process:
-
-* When you migrate and preserve the VIP address, the precreated IP address is assigned temporarily to the new `stv2` deployment, before the original IP address is assigned to the `stv2` deployment. If you have firewall rules limiting access to the API Management instance, for example, you can add the precreated IP address to the allowlist to preserve continuity of client access during migration. After migration is complete, you can remove the precreated IP address from your allowlist.
-* When you migrate and generate a new VIP address, the precreated IP address is assigned to the new `stv2` deployment during migration and persists after migration is complete. Use the precreated IP address to update your network dependencies, such as DNS and firewall rules, to point to the new IP address.
+[!INCLUDE [api-management-migration-precreated-ip](../../includes/api-management-migration-precreated-ip.md)]
 
 ### Expected downtime and compute retention
 
@@ -110,16 +106,16 @@ When migrating a VNet-injected instance and keeping the same subnet configuratio
 |Internal     |    Preserve VIP     |  Downtime for approximately 20 minutes during migration while the existing IP address is assigned to the new `stv2` deployment.       | No retention |
 |Internal     |  New VIP       |   No downtime | Retained by default for 4 hours to allow you to update network dependencies   |
 
-
 ### Migration script
 
-> [!NOTE]
-> If your API Management instance is deployed in multiple regions, the REST API migrates the VNet settings for all locations of your instance using a single call.
-
+[!INCLUDE [api-management-migration-no-preserve-ip](../../includes/api-management-migration-no-preserve-ip.md)]
 
 [!INCLUDE [api-management-migration-cli-steps](../../includes/api-management-migration-cli-steps.md)]
 
 
+> [!NOTE]
+> If your API Management instance is deployed in multiple regions, the REST API migrates the VNet settings for all locations of your instance using a single call.
+
 ## Option 2: Migrate and change to new subnet
 
 Using the Azure portal, you can migrate your instance by specifying a different subnet in the same or a different VNet. After migration, optionally migrate back to the instance's original subnet.

articles/app-service/configure-ssl-certificate.md

@@ -82,12 +82,13 @@ The free certificate comes with the following limitations:
 
 ### [Apex domain](#tab/apex)
 - Must have an A record pointing to your web app's IP address.
-- Isn't supported on apps that aren't publicly accessible.
+- Must be on apps that are publicly accessible.
 - Isn't supported with root domains that are integrated with Traffic Manager.
 - Must meet all the above for successful certificate issuances and renewals.
 
 ### [Subdomain](#tab/subdomain)
 - Must have CNAME mapped _directly_ to `<app-name>.azurewebsites.net` or [trafficmanager.net](configure-domain-traffic-manager.md#enable-custom-domain). Mapping to an intermediate CNAME value blocks certificate issuance and renewal.
+- Must be on apps that are publicly accessible.
 - Must meet all the above for successful certificate issuance and renewals.
 
 ---