Merge pull request #298705 from MicrosoftDocs/main

4/23/2025 AM Publish

Author: Taojunshen

articles/active-directory-b2c/best-practices.md

@@ -82,7 +82,7 @@ Manage your Azure AD B2C environment.
 | Use version control for your custom policies | Consider using GitHub, Azure Repos, or another cloud-based version control system for your Azure AD B2C custom policies. |
 | Use the Microsoft Graph API to automate the management of your B2C tenants | Microsoft Graph APIs:<br/>Manage [Identity Experience Framework](/graph/api/resources/trustframeworkpolicy?preserve-view=true&view=graph-rest-beta) (custom policies)<br/>[Keys](/graph/api/resources/trustframeworkkeyset?preserve-view=true&view=graph-rest-beta)<br/>[User Flows](/graph/api/resources/identityuserflow?preserve-view=true&view=graph-rest-beta) |
 | Integrate with Azure DevOps | A [CI/CD pipeline](deploy-custom-policies-devops.md) makes moving code between different environments easy and ensures production readiness always.   |
-| Deploy custom policy | Azure AD B2C relies on caching to deliver performance to your end users. When you deploy a custom policy using whatever method, expect a delay of up to **30 minutes** for your users to see the changes. As a result of this behavior, consider the following practices when you deploy your custom policies: <br> - If you're deploying to a development environment, set the `DeploymentMode` attribute in your custom policy file's `<TrustFrameworkPolicy>` element to `Production`. <br> - Deploy your updated policy files to a production environment when traffic in your app is low. <br> - When you deploy to a production environment to update existing policy files, upload the updated files with new name(s), and then update your app reference to the new name(s). You can then remove the old policy files afterwards.<br> - You can set the `DeploymentMode` to `Development` in a production environment to bypass the caching behavior. However, we don't recommend this practice. If you [Collect Azure AD B2C logs with Application Insights](troubleshoot-with-application-insights.md), all claims sent to and from identity providers are collected, which is a security and performance risk. |
+| Deploy custom policy | Azure AD B2C relies on caching to deliver performance to your end users. When you deploy a custom policy using whatever method, expect a delay of up to **30 minutes** for your users to see the changes. As a result of this behavior, consider the following practices when you deploy your custom policies: <br> - If you're deploying to a development environment, set the `DeploymentMode` attribute in your custom policy file's `<TrustFrameworkPolicy>` element to `Production`. <br> - Deploy your updated policy files to a production environment when traffic in your app is low. <br> - When you deploy to a production environment to update existing policy files, upload the updated files with new names, which act as new versions of the policies. Then, update your app references to the new names/versions. You can remove the old policy files afterward or keep them as your last known good configuration for easy rollback.<br> - If you need to deploy to a production environment to update existing policy files without versioning, make the new policy backward compatible with the old policy by following some simple rules. If you need to change a technical profile, claim, or [SubJourney](subjourneys.md), create a new version of it, publish the policy, and wait for 30 minutes for Azure AD B2C caches to pick up the new version. Then, in a subsequent update, make changes to use the new version and perform another policy update. Wait for another 30 minutes, then you can delete the old version of the elements if needed. Ensure all of your business logic is inside SubJourneys.<br> - You can set the `DeploymentMode` to `Development` in a production environment to bypass the caching behavior. However, we don't recommend this practice. If you [Collect Azure AD B2C logs with Application Insights](troubleshoot-with-application-insights.md), all claims sent to and from identity providers are collected, which is a security and performance risk. |
 | Deploy app registration updates | When you modify your application registration in your Azure AD B2C tenant, such as updating the application's redirect URI, expect a delay of up to **2 hours (3600s)** for the changes to take effect in the production environment. We recommend that you modify your application registration in your production environment when traffic in your app is low.|
 | Integrate with Azure Monitor | [Audit log events](view-audit-logs.md) are only retained for seven days. [Integrate with Azure Monitor](azure-monitor.md) to retain the logs for long-term use, or integrate with third-party security information and event management (SIEM) tools to gain insights into your environment. |
 | Setup active alerting and monitoring | [Track user behavior](./analytics-with-application-insights.md) in Azure AD B2C using Application Insights. |

articles/active-directory-b2c/jwt-issuer-technical-profile.md

@@ -14,15 +14,15 @@ ms.author: kengaderdus
 ms.subservice: b2c
 
 
-#Customer intent: As a developer implementing custom policies in Azure Active Directory B2C, I want to define a technical profile for a JWT token issuer, so that I can emit a JWT token that is returned to the relying party application during the authentication flow.
+#Customer intent: As a developer implementing custom policies in Azure Active Directory B2C, I want to define a technical profile for a JWT issuer, so that I can emit a JWT that is returned to the relying party application during the authentication flow.
 
 ---
 
-# Define a technical profile for a JWT token issuer in an Azure Active Directory B2C custom policy
+# Define a technical profile for a JWT issuer in an Azure Active Directory B2C custom policy
 
 [!INCLUDE [active-directory-b2c-advanced-audience-warning](../../includes/active-directory-b2c-advanced-audience-warning.md)]
 
-Azure Active Directory B2C (Azure AD B2C) emits several types of security tokens as it processes each authentication flow. A technical profile for a JWT token issuer emits a JWT token that is returned back to the relying party application. Usually this technical profile is the last orchestration step in the user journey.
+Azure Active Directory B2C (Azure AD B2C) emits several types of security tokens as it processes each authentication flow. A technical profile for a JWT issuer emits a JWT that is returned back to the relying party application. Usually this technical profile is the last orchestration step in the user journey.
 
 ## Protocol
 
@@ -73,7 +73,7 @@ The CryptographicKeys element contains the following attributes:
 
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |
-| issuer_secret | Yes | The X509 certificate (RSA key set) to use to sign the JWT token. This is the `B2C_1A_TokenSigningKeyContainer` key you configure in [Get started with custom policies](tutorial-create-user-flows.md?pivots=b2c-custom-policy). |
+| issuer_secret | Yes | The X509 certificate (RSA key set) to use to sign the JWT. This is the `B2C_1A_TokenSigningKeyContainer` key you configure in [Get started with custom policies](tutorial-create-user-flows.md?pivots=b2c-custom-policy). |
 | issuer_refresh_token_key | Yes | The X509 certificate (RSA key set) to use to encrypt the refresh token. You configured the `B2C_1A_TokenEncryptionKeyContainer` key in [Get started with custom policies](tutorial-create-user-flows.md?pivots=b2c-custom-policy) |
 
 ## Session management

articles/active-directory-b2c/userjourneys.md

@@ -46,7 +46,7 @@ The **UserJourney** element contains the following attribute:
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |
 | Id | Yes | An identifier of a user journey that can be used to reference it from other elements in the policy. The **DefaultUserJourney** element of the [relying party policy](relyingparty.md) points to this attribute. |
-| DefaultCpimIssuerTechnicalProfileReferenceId| No | The default token issuer technical profile reference ID. For example, [JWT token issuer](userjourneys.md), [SAML token issuer](saml-issuer-technical-profile.md), or [OAuth2 custom error](oauth2-error-technical-profile.md). If your user journey or sub journey already has another `SendClaims` orchestration step, set the `DefaultCpimIssuerTechnicalProfileReferenceId` attribute to the user journey's token issuer technical profile. |
+| DefaultCpimIssuerTechnicalProfileReferenceId| No | The default token issuer technical profile reference ID. For example, [JWT issuer](userjourneys.md), [SAML token issuer](saml-issuer-technical-profile.md), or [OAuth2 custom error](oauth2-error-technical-profile.md). If your user journey or sub journey already has another `SendClaims` orchestration step, set the `DefaultCpimIssuerTechnicalProfileReferenceId` attribute to the user journey's token issuer technical profile. |
 
 The **UserJourney** element contains the following elements:
 

articles/api-management/api-management-policies.md

@@ -151,6 +151,21 @@ More information about policies:
 | [HTTP data source for resolver](http-data-source-policy.md) | Configures the HTTP request and optionally the HTTP response to resolve data for an object type and field in a GraphQL schema. | Yes | Yes | Yes | No | No |
 | [Publish event to GraphQL subscription](publish-event-policy.md) | Publishes an event to one or more subscriptions specified in a GraphQL API schema. Configure the policy in a GraphQL resolver for a related field in the schema for another operation type such as a mutation. | Yes | Yes | Yes | No | No |
 
+## AI gateway 
+
+|Policy  |Description  | Classic | V2  | Consumption |Self-hosted  | Workspace |
+|---------|---------|---------|---------|---------|--------|----------|
+| [Limit Azure OpenAI Service token usage](azure-openai-token-limit-policy.md) | Prevents Azure OpenAI API usage spikes by limiting large language model tokens per calculated key. | Yes | Yes | No | Yes | Yes |
+| [Limit large language model API token usage](llm-token-limit-policy.md) | Prevents large language model (LLM) API usage spikes by limiting LLM tokens per calculated key. | Yes | Yes | No | Yes | Yes |
+|  [Emit Azure OpenAI token metrics](azure-openai-emit-token-metric-policy.md) | Sends metrics to Application Insights for consumption of large language model tokens through Azure OpenAI service APIs. | Yes | Yes | No | Yes | Yes |
+|  [Emit large language model API token metrics](llm-emit-token-metric-policy.md) | Sends metrics to Application Insights for consumption of large language model (LLM) tokens through LLM APIs. | Yes | Yes | No | Yes | Yes |
+|  [Get cached responses of Azure OpenAI API requests](azure-openai-semantic-cache-lookup-policy.md) | Performs lookup in Azure OpenAI API cache using semantic search and returns a valid cached response when available. | Yes | Yes | Yes | Yes | No |
+|  [Get cached responses of large language model API requests](llm-semantic-cache-lookup-policy.md) | Performs lookup in large language model API cache using semantic search and returns a valid cached response when available. | Yes | Yes | Yes | Yes | No |
+|  [Store responses of Azure OpenAI API requests to cache](azure-openai-semantic-cache-store-policy.md) | Caches response according to the Azure OpenAI API cache configuration. | Yes | Yes | Yes | Yes | No |
+|  [Store responses of large language model API requests to cache](llm-semantic-cache-store-policy.md) | Caches response according to the large language model API cache configuration. | Yes | Yes | Yes | Yes | No |
+| [Enforce content safety checks on LLM requests](llm-content-safety-policy.md) | Enforces content safety checks on LLM requests (prompts) by transmitting them to the [Azure AI Content Safety](/azure/ai-services/content-safety/overview) service before sending to the backend LLM. | Yes | Yes | Yes | Yes | Yes |
+
+
 ## Policy control and flow
 
 |Policy  |Description  | Classic | V2  | Consumption |Self-hosted  | Workspace |

articles/api-management/inject-vnet-v2.md

@@ -23,7 +23,7 @@ This article guides you through the requirements to inject your Azure API Manage
 When an API Management Premium v2 instance is injected in a virtual network: 
 
 * The API Management gateway endpoint is accessible through the virtual network at a private IP address.
-* API Management can make outbound requests to API backends that are isolated in the network. 
+* API Management can make outbound requests to API backends that are isolated in the network or any peered network, as long as network connectivity is properly configured. 
 
 This configuration is recommended for scenarios where you want to isolate network traffic to both the API Management instance and the backend APIs.
 

articles/api-management/integrate-vnet-outbound.md

@@ -12,7 +12,7 @@ ms.date: 04/03/2025
 
 [!INCLUDE [api-management-availability-standardv2-premiumv2](../../includes/api-management-availability-standardv2-premiumv2.md)] 
 
-This article guides you through the process of configuring *virtual network integration* for your Standard v2 or Premium v2 (preview) Azure API Management instance. With virtual network integration, your instance can make outbound requests to APIs that are isolated in a single connected virtual network.
+This article guides you through the process of configuring *virtual network integration* for your Standard v2 or Premium v2 (preview) Azure API Management instance. With virtual network integration, your instance can make outbound requests to APIs that are isolated in a single connected virtual network or any peered virtual network, as long as network connectivity is properly configured.
 
 When an API Management instance is integrated with a virtual network for outbound requests, the gateway and developer portal endpoints remain publicly accessible. The API Management instance can reach both public and network-isolated backend services.
 

articles/api-management/virtual-network-concepts.md

@@ -64,7 +64,7 @@ In the API Management Premium v2 tier, inject your instance into a delegated sub
 In this configuration: 
 
 * The API Management gateway endpoint is accessible through the virtual network at a private IP address.
-* API Management can make outbound requests to API backends that are isolated in the network. 
+* API Management can make outbound requests to API backends that are isolated in the network or any peered network, as long as network connectivity is properly configured. 
 
 This configuration is recommended for scenarios where you want to isolate both the API Management instance and the backend APIs. Virtual network injection in the Premium v2 tier automatically manages network connectivity to most service dependencies for Azure API Management.
 
@@ -74,7 +74,7 @@ For more information, see [Inject a Premium v2 instance into a virtual network](
 
 ## Virtual network integration (v2 tiers)
 
-The Standard v2 and Premium v2 tiers support outbound virtual network integration to allow your API Management instance to reach API backends that are isolated in a single connected virtual network. The API Management gateway, management plane, and developer portal remain publicly accessible from the internet. 
+The Standard v2 and Premium v2 tiers support outbound virtual network integration to allow your API Management instance to reach API backends that are isolated in a single connected virtual network or any peered virtual network, as long as network connectivity is properly configured. The API Management gateway, management plane, and developer portal remain publicly accessible from the internet. 
 
 Outbound integration enables the API Management instance to reach both public and network-isolated backend services.
 

articles/azure-cache-for-redis/TOC.yml

@@ -11,8 +11,6 @@
     items:
     - name: Create a cache
       items: 
-      - name: Create an Azure Managed Redis instance
-        href: /redis/quickstart-create-managed-redis
       - name: Create an Azure Cache for Redis instance in the Basic, Standard and Premium tiers
         href: quickstart-create-redis.md
       - name: Create an Azure Cache for Redis instance in the Enterprise tiers
@@ -65,7 +63,7 @@
 - name: Azure Cache for Redis 
   expanded: true
   items:
-  - name: What's new?
+  - name: What's new in Azure Cache for Redis?
     href: cache-whats-new.md
 
   - name: Deploy and configure
@@ -232,7 +230,16 @@
       href: cache-troubleshoot-data-loss.md
     - name: Troubleshooting FAQs
       href: cache-monitor-troubleshoot-faq.yml 
-      
+
+- name: Azure Managed Redis 
+  href: /azure/redis/index
+  expanded: true
+  items:
+  - name: About Azure Managed Redis
+    href: /azure/redis/overview
+  - name: Azure Managed Redis architecture
+    href: /azure/redis/architecture
+
 - name: Samples
   items:
   - name: Use Azure Functions triggers and bindings

articles/azure-netapp-files/application-volume-group-oracle-deploy-volumes.md

@@ -12,7 +12,7 @@ ms.service: azure-netapp-files
 ms.workload: storage
 ms.tgt_pltfrm: na
 ms.topic: how-to
-ms.date: 03/13/2025
+ms.date: 04/22/2025
 ms.author: anfdocs
 ---
 # Deploy application volume group for Oracle
@@ -23,26 +23,6 @@ This article describes how to deploy all required volumes for your Oracle databa
 
 You should understand the [requirements and considerations for application volume group for Oracle](application-volume-group-oracle-considerations.md). 
 
-## Register the feature  
-
-Before using Azure NetApp Files application volume group for Oracle for the first time, you need to register it. 
-
-1. Register the feature: 
-
-    ```azurepowershell-interactive
-    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFOracleVolumeGroup 
-    ```
-
-2. Check the status of the feature registration: 
-
-    ```azurepowershell-interactive
-    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFOracleVolumeGroup
-    ```
-    > [!NOTE]
-    > The **RegistrationState** may be in the `Registering` state for up to 60 minutes before changing to `Registered`. Wait until the status is **Registered** before continuing.
-
-You can also use [Azure CLI commands](/cli/azure/feature) `az feature register` and `az feature show` to register the feature and display the registration status. 
-
 ## Steps 
 
 1. From your NetApp account, select **Application volume groups** then **+Add Group**.

articles/azure-netapp-files/azure-netapp-files-resource-limits.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 04/17/2024
+ms.date: 04/23/2025
 ms.author: anfdocs
 ---
 # Resource limits for Azure NetApp Files
@@ -45,7 +45,7 @@ The following table describes resource limits for Azure NetApp Files:
 |  Maximum assigned throughput for a manual QoS volume     |    4,500 MiB/s    |    No    |    
 |  Number of cross-region replication data protection volumes (destination volumes)     |    500    |    Yes    |     
 |  Number of cross-zone replication data protection volumes (destination volumes)     |    500    |    Yes    |     
-|  Maximum numbers of policy-based (scheduled) backups per volume  | <ul><li> Daily retention count: 2 (minimum) to 1019 (maximum) </li> <li> Weekly retention count: 1 (minimum) to 1019 (maximum) </li> <li> Monthly retention count: 1 (minimum) to 1019 (maximum) </ol></li> <br> The maximum hourly, daily, weekly, and monthly backup retention counts *combined* is 1019.  |  No  |
+|  Maximum numbers of policy-based (scheduled) backups per volume  | <ul><li> Daily retention count: 2 (minimum) to 1019 (maximum) </li> <li> Weekly retention count: 0 (minimum) to 1019 (maximum) </li> <li> Monthly retention count: 0 (minimum) to 1019 (maximum) </ol></li> <br> The maximum hourly, daily, weekly, and monthly backup retention counts *combined* is 1019.  |  No  |
 |  Maximum size of protected volume  |  100 TiB  |  No  |
 |  Maximum number of volumes that can be backed up per subscription   |  500  |  No  |
 |  Maximum number of manual backups per volume per day |  5  |  No  |