Merge branch 'main' into release-ga-lbcd

Author: v-alje

articles/api-management/api-management-sample-send-request.md

@@ -59,7 +59,7 @@ There are certain tradeoffs when using a fire-and-forget style of request. If fo
 The `send-request` policy enables using an external service to perform complex processing functions and return data to the API management service that can be used for further policy processing.
 
 ### Authorizing reference tokens
-A major function of API Management is protecting backend resources. If the authorization server used by your API creates [JWT tokens](../active-directory/develop/security-tokens.md#json-web-tokens-and-claims) as part of its OAuth2 flow, as [Microsoft Entra ID](../active-directory/hybrid/whatis-hybrid-identity.md) does, then you can use the `validate-jwt` policy or `validate-azure-ad-token` policy to verify the validity of the token. Some authorization servers create what are called [reference tokens](https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/) that cannot be verified without making a callback to the authorization server.
+A major function of API Management is protecting backend resources. If the authorization server used by your API creates [JWTs](../active-directory/develop/security-tokens.md#json-web-tokens-and-claims) as part of its OAuth2 flow, as [Microsoft Entra ID](../active-directory/hybrid/whatis-hybrid-identity.md) does, then you can use the `validate-jwt` policy or `validate-azure-ad-token` policy to verify the validity of the token. Some authorization servers create what are called [reference tokens](https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/) that cannot be verified without making a callback to the authorization server.
 
 ### Standardized introspection
 In the past, there has been no standardized way of verifying a reference token with an authorization server. However a recently proposed standard [RFC 7662](https://tools.ietf.org/html/rfc7662) was published by the IETF that defines how a resource server can verify the validity of a token.

articles/api-management/validate-jwt-policy.md

@@ -115,15 +115,15 @@ The `validate-jwt` policy enforces existence and validity of a supported JSON we
 
 ### Usage notes
 
-* The `validate-jwt` policy requires that the `exp` registered claim is included in the JWT token, unless `require-expiration-time` attribute is specified and set to `false`.
+* The `validate-jwt` policy requires that the `exp` registered claim is included in the JWT, unless `require-expiration-time` attribute is specified and set to `false`.
 * The policy supports both symmetric and asymmetric signing algorithms: 
     * **Symmetric** - The following encryption algorithms are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512.
     	* If used in the policy, the key must be provided inline within the policy in the Base64-encoded form.
     * **Asymmetric** - The following encryption algorithms are supported: PS256, RS256, RS512, ES256. 
     	* If used in the policy, the key may be provided either via an OpenID configuration endpoint, or by providing the ID of an uploaded certificate (in PFX format) that contains the public key, or the modulus-exponent pair of the public key.
 * To configure the policy with one or more OpenID configuration endpoints for use with a self-hosted gateway, the OpenID configuration endpoints URLs must also be reachable by the cloud gateway.
 * You can use access restriction policies in different scopes for different purposes. For example, you can secure the whole API with Microsoft Entra authentication by applying the `validate-jwt` policy on the API level, or you can apply it on the API operation level and use `claims` for more granular control.
-* When using a custom header (`header-name`), the configured required scheme (`require-scheme`) will be ignored. To use a required scheme, JWT tokens must be provided in the `Authorization` header.
+* When using a custom header (`header-name`), the configured required scheme (`require-scheme`) will be ignored. To use a required scheme, JWTs must be provided in the `Authorization` header.
 
 ## Examples
 

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: concept-article
-ms.date: 04/23/2025
+ms.date: 06/10/2025
 ms.author: anfdocs
 ---
 # Resource limits for Azure NetApp Files
@@ -49,7 +49,7 @@ The following table describes resource limits for Azure NetApp Files:
 |  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  |
-|  Maximum number of volumes supported for cool access per subscription per region |  10  |  Yes  |
+|  Maximum number of volumes supported for cool access per subscription per region |  500  |  Yes  |
 
 
 \* [!INCLUDE [Limitations for capacity pool minimum of 1 TiB](includes/2-tib-capacity-pool.md)]

articles/azure-netapp-files/includes/cool-access-options.md

@@ -0,0 +1,38 @@
+---
+author: b-ahibbard
+ms.service: azure-netapp-files
+ms.topic: include
+ms.date: 06/06/2025
+ms.author: anfdocs
+ms.custom: include file
+
+# manage-cool-access.md // 2 workflows
+---
+    
+* **Enable Cool Access**:
+
+    The coolness period defines the minimum number of days before data is transitioned to the cold tier. The default value is 31 days. The supported values are between 2 and 183 days.
+
+    >[!NOTE]
+    > The coolness period is calculated from the time of volume creation. If any existing volumes are enabled with cool access, the coolness period is applied retroactively on those volumes. If certain data blocks on the volumes have not been accessed for the number of days specified in the coolness period, those blocks move to the cool tier once the feature is enabled. Once the coolness period is reached, background jobs can take up to 48 hours to initiate the data transfer to the cool tier.
+
+* **Cool Access Retrieval Policy**:
+
+    This option specifies under which conditions data moves back to the hot tier. You can set this option to **Default**, **On-Read**, or **Never**.
+
+    If you don't set a value for the cool access retrieval policy, the retrieval policy is set to Default. The following table describes each policy's data retrieval behavior:
+
+    | Retrieval policy | Behavior |
+    | - | - | 
+    | Default | Cold data is returned to the hot tier when performing random reads. Data is served from the cool tier with sequential reads. | 
+    | On-read | On both sequential and random reads, cold data  is returned to the hot tier. |
+    | Never | Cold data is served directly from the cool tier. After data moves to the cool tier, it's not returned to the hot tier. |
+
+* **Cool Access Tiering policy**     
+
+    The tiering policy manages what data moves to the cool tier. You can tier all data or limit tiering to snapshots. Select one of the following policies: 
+
+    | Tiering policy | Description |
+    | - | - | 
+    | `Auto` | This policy encompasses both data in the active file system and snapshot copy data. |
+    | `SnapshotOnly` | This policy limits tiering to data in snapshots. All data blocks associated with files in the active file system remain in the hot tier. |

articles/azure-netapp-files/manage-cool-access.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-ahibbard
 ms.service: azure-netapp-files
 ms.topic: how-to
-ms.date: 05/14/2025
+ms.date: 06/06/2025
 ms.author: anfdocs
 ms.custom:
   - build-2025
@@ -29,14 +29,23 @@ There are several considerations to be aware of when using cool access.
 * Although cool access is available for the Standard, Premium, and Ultra service levels, how you're billed for using the feature differs from the hot tier service-level charges. For details and examples, see the [Billing section](cool-access-introduction.md#billing).
 * Cool access supports two tiering policies: `Auto` and `SnapshotOnly`. The `SnapshotOnly` policy limits data tiering to data in snapshots, while all data blocks associated with files in the active file system remain in the hot tier. The `Auto` policy encompasses both snapshot copy data and data in the active file system.
     Throughput is based on the [the service level](azure-netapp-files-service-levels.md#supported-service-levels) for both the `Auto` and `SnapshotOnly` tiering policies.
+* To prevent data retrieval from the cool tier to the hot tier during sequential read operations (for example, antivirus or other file scanning operations), set the cool access retrieval policy to **Default** or **Never**. For more information about the retrieval policy, see [Enable cool access on a new volume](#enable-cool-access-on-a-new-volume).
+* Files moved to the cool tier remains there after you disable cool access on a volume. You must perform an I/O operation on _each_ file to return it to the warm tier. 
+* For the maximum number of volumes supported for cool access per subscription per region, see [Resource limits for Azure NetApp Files](azure-netapp-files-resource-limits.md#resource-limits).
+* Cool access is supported with large volumes. Confirm that you're [registered to use large volumes](large-volumes-requirements-considerations.md#register-the-feature) before creating a cool-access-enabled large volume. 
+
+### Considerations for cool access-enabled capacity pools 
+
 * You can convert an existing capacity pool into a cool-access capacity pool to create cool access volumes. After the capacity pool is enabled for cool access, you can't convert it back to a non-cool-access capacity pool.  
     * When you enable cool access, data that satisfies the conditions set by the coolness period moves to the cool tier. For example, if the coolness period is set to 30 days, any data that has been cool for at least 30 days moves to the cool tier _when_ you enable cool access. Once the coolness period is reached, background jobs can take up to 48 hours to initiate the data transfer to the cool tier. 
 * A cool-access capacity pool can contain both volumes with cool access enabled and volumes with cool access disabled.
-* To prevent data retrieval from the cool tier to the hot tier during sequential read operations (for example, antivirus or other file scanning operations), set the cool access retrieval policy to **Default** or **Never**. For more information, see [Enable cool access on a new volume](#enable-cool-access-on-a-new-volume).
 * After the capacity pool is configured with the option to support cool access volumes, the setting can't be disabled at the _capacity pool_ level. You can turn on or turn off the cool access setting at the _volume_ level anytime. Turning off the cool access setting at the volume level stops further tiering of data.  
-* Files moved to the cool tier remains there after you disable cool access on a volume. You must perform an I/O operation on _each_ file to return it to the warm tier. 
-* For the maximum number of volumes supported for cool access per subscription per region, see [Resource limits for Azure NetApp Files](azure-netapp-files-resource-limits.md#resource-limits).
-* Cool access is supported with large volumes. Confirm that you're [registered to use large volumes](large-volumes-requirements-considerations.md#register-the-feature) before creating a cool-access-enabled large volume. 
+
+#### Considerations for moving volumes to another capacity pool
+
+* Volumes enabled for cool access can be moved between capacity pools only if those capacity pools are enabled for cool access. When a volume is enabled for cool access, it can only reside in a cool access-enabled capacity pool even if cool access has been disabled on the volume. 
+* If you [move a cool access volume to another capacity pool (service level change)](dynamic-change-volume-service-level.md), you must also enable that pool for cool access.
+* If you disable cool access and turn off tiering on a cool access volume (that is, the volume no longer uses cool access), you can't move it to a non-cool-access capacity pool. In a cool access capacity pool, you can move all volumes, *whether they're enabled for cool access or not*, only to another cool access capacity pool.  
 
 ### Considerations for throughput in Premium and Ultra service level volumes with cool access
 
@@ -56,12 +65,6 @@ There are several considerations to be aware of when using cool access.
 - **Data rehydration:** Data isn't rehydrated to the hot tier when the volume is deleted, ensuring the deletion process is efficient and mitigating unnecessary data movement. 
     - The only way to rehydrate data from the cool tier to the hot tier is for the client or application to read the data block. 
 
-### Considerations for moving volumes to another capacity pool
-
-* Volumes enabled for cool access can be moved between capacity pools only if those capacity pools are enabled for cool access. When a volume is enabled for cool access, it can only reside in a cool access-enabled capacity pool even if cool access has been disabled on the volume. 
-* If you [move a cool access volume to another capacity pool (service level change)](dynamic-change-volume-service-level.md), you must also enable that pool for cool access.
-* If you disable cool access and turn off tiering on a cool access volume (that is, the volume no longer uses cool access), you can't move it to a non-cool-access capacity pool. In a cool access capacity pool, you can move all volumes, *whether they're enabled for cool access or not*, only to another cool access capacity pool.  
-
 
 ### Considerations for cross-region and cross-zone replication 
 
@@ -156,32 +159,12 @@ You can enable Azure NetApp Files storage with cool access during the creation o
 1. On the **Capacity Pools** menu, select **Volumes**. Select **+ Add volume** to create a new network file system (NFS), server message block (SMB), or dual-protocol volume.
 1. On the **Create a volume** page, on the **Basics** tab, set the following options to enable the volume for cool access:
 
-    * **Enable Cool Access**: This option specifies whether the volume supports cool access.
-    * **Coolness Period**: The coolness period defines the minimum number of days before data is transitioned to the cold tier. Once the coolness period is reached, background jobs can take up to 48 hours to initiate the data transfer to the cool tier. The default value is 31 days. The supported values are between 2 and 183 days.
-
-    * **Cool Access Retrieval Policy**: This option specifies under which conditions data moves back to the hot tier. You can set this option to **Default**, **On-Read**, or **Never**.
-
-        The following list describes the data retrieval behavior with the **Cool Access Retrieval Policy** settings:
-
-        * Cool access is **enabled**:  
-            * If **Cool Access Retrieval Policy** is set to **Default**: Cold data is retrieved only by performing random reads. Sequential reads are served directly from the cool tier.
-            * If no value is set for **Cool Access Retrieval Policy**: The active retrieval policy is **Default**.
-            * If **Cool Access Retrieval Policy** is set to **On-Read**: Cold data is retrieved by performing both sequential and random reads.
-            * If **Cool Access Retrieval Policy** is set to **Never**: Cold data is served directly from the cool tier and isn't retrieved to the hot tier.
-        * Cool access is **disabled**:
-            * You can set a cool access retrieval policy if cool access is disabled only if there's existing data on the cool tier. 
-            * After you disable the cool access setting on the volume, the cool access retrieval policy remains the same.    
-    
-    * **Cool Access Tiering Policy** 
-
-        Select either `SnapshotOnly` or `Auto`. 
-
-        * The `SnapshotOnly` policy limits data tiering to data in snapshots, while all data blocks associated with files in the active file system remain in the hot tier.
-        * The `Auto` policy encompasses both snapshot copy data and data in the active file system. 
+    [!INCLUDE [Cool access configuration settings](includes/cool-access-options.md)]
 
     :::image type="content" source="./media/manage-cool-access/cool-access-new-volume.png" alt-text="Screenshot that shows the Create a volume page. On the Basics tab, the Enable Cool Access checkbox is selected. The options for the cool access retrieval policy are displayed. " lightbox="./media/manage-cool-access/cool-access-new-volume.png"::: 
 
-1. Follow the steps in one of these articles to finish the volume creation:
+1. To finish creating the volume, follow the instructions for the relevant protocol:
+
     * [Create an NFS volume](azure-netapp-files-create-volumes.md)
     * [Create an SMB volume](azure-netapp-files-create-volumes-smb.md)
     * [Create a dual-protocol volume](create-volumes-dual-protocol.md)
@@ -190,34 +173,20 @@ You can enable Azure NetApp Files storage with cool access during the creation o
 
 In a capacity pool enabled for cool access, you can enable an existing volume to support cool access.  
 
+>[!NOTE]
+> If cool access is disabled, you can only set a retrieval policy if there's existing data on the cool tier.
+>
+> If you disable cool access, the cool access setting on the volume, the cool access retrieval policy remains the same.
+
 1. Right-click the volume for which you want to enable the cool access.
 1. On the **Edit** window that appears, set the following options for the volume:
-    * **Enable Cool Access**: The coolness period defines the minimum number of days before data is transitioned to the cold tier. The default value is 31 days. The supported values are between 2 and 183 days.
-    >[!NOTE]
-    > The coolness period is calculated from the time of volume creation. If any existing volumes are enabled with cool access, the coolness period is applied retroactively on those volumes. This means if certain data blocks on the volumes have been infrequently accessed for the number of days specified in the coolness period, those blocks move to the cool tier once the feature is enabled. Once the coolness period is reached, background jobs can take up to 48 hours to initiate the data transfer to the cool tier.
-    * **Cool Access Retrieval Policy**: This option specifies under which conditions data moves back to the hot tier. You can set this option to **Default**, **On-Read**, or **Never**.
-
-        The following list describes the data retrieval behavior with the **Cool Access Retrieval Policy** settings:
-
-        * Cool access is **enabled**:  
-            * If no value is set for **Cool Access Retrieval Policy**:  
-                The retrieval policy is set to **Default**. Cold data is retrieved to the hot tier only when random reads are performed. Sequential reads are served directly from the cool tier.
-            * If **Cool Access Retrieval Policy** is set to **Default**: Cold data is retrieved only by performing random reads.
-            * If **Cool Access Retrieval Policy** is set to **On-Read**: Cold data is retrieved by performing both sequential and random reads.
-            * If **Cool Access Retrieval Policy** is set to **Never**: Cold data is served directly from the cool tier and isn't retrieved to the hot tier.
-        * Cool access is **disabled**: 
-            * You can set a cool access retrieval policy if cool access is disabled only if there's existing data on the cool tier. 
-            * After you disable the cool access setting on the volume, the cool access retrieval policy remains the same.
-    * **Cool Access Tiering policy**     
-
-        Select either `SnapshotOnly` or `Auto`. 
-
-        * The `SnapshotOnly` policy limits data tiering to data in snapshots, while all data blocks associated with files in the active file system remain in the hot tier.
-        * The `Auto` policy encompasses both snapshot copy data and data in the active file system. 
 
+    [!INCLUDE [Cool access configuration settings](includes/cool-access-options.md)]
 
     :::image type="content" source="./media/manage-cool-access/cool-access-existing-volume.png" alt-text="Screenshot that shows the Enable Cool Access checkbox selected. " lightbox="./media/manage-cool-access/cool-access-existing-volume.png"::: 
 
+1. Select **OK** to confirm the changes. 
+
 ### <a name="modify_cool"></a>Modify cool access configuration for a volume
 
 Based on the client read/write patterns, you can modify the cool access configuration as needed for a volume.