Merge branch 'main' into release-backup-security

Author: v-alje

articles/azure-government/azure-secure-isolation-guidance.md

@@ -601,7 +601,7 @@ You can enable IPsec in addition to MACsec on your ExpressRoute Direct ports, as
 #### Traffic across Microsoft global network backbone
 Azure services such as Storage and SQL Database can be configured for geo-replication to help ensure durability and high availability especially for disaster recovery scenarios. Azure relies on [paired regions](../reliability/cross-region-replication-azure.md) to deliver [geo-redundant storage](../storage/common/storage-redundancy.md) (GRS) and paired regions are also recommended when configuring active [geo-replication](/azure/azure-sql/database/active-geo-replication-overview) for Azure SQL Database. Paired regions are located within the same geography; however, network traffic isn't guaranteed to always follow the same path from one Azure region to another. To provide the reliability needed for the Azure cloud, Microsoft has many physical networking paths with automatic routing around failures for optimal reliability.
 
-Moreover, all Azure traffic traveling within a region or between regions is [encrypted by Microsoft using MACsec](../security/fundamentals/encryption-overview.md#data-link-layer-encryption-in-azure), which relies on AES-128 block cipher for encryption. This traffic stays entirely within the Microsoft [global network backbone](../networking/microsoft-global-network.md) and never enters the public Internet. The backbone is one of the largest in the world with more than 250,000 km of lit fiber optic and undersea cable systems.
+Moreover, all Azure traffic traveling within a region or between regions is [encrypted by Microsoft using MACsec](../security/fundamentals/encryption-overview.md#data-link-layer-encryption), which relies on AES-128 block cipher for encryption. This traffic stays entirely within the Microsoft [global network backbone](../networking/microsoft-global-network.md) and never enters the public Internet. The backbone is one of the largest in the world with more than 250,000 km of lit fiber optic and undersea cable systems.
 
 > [!IMPORTANT]
 > You should review Azure **[best practices for the protection of data in transit](../security/fundamentals/data-encryption-best-practices.md#protect-data-in-transit)** to help ensure that all data in transit is encrypted. For key Azure PaaS storage services (for example, Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics), data encryption in transit is **[enforced by default](/azure/azure-sql/database/security-overview#transport-layer-security-encryption-in-transit)**.

articles/azure-netapp-files/configure-cache-volumes.md

@@ -18,44 +18,64 @@ Azure NetApp Files cache volumes are cloud-based caches of an external origin vo
 
 Write-back allows the write to be committed to stable storage at the cache and acknowledges the client without waiting for the data to make it to the origin. This results in a globally distributed file system that enables writes to perform at near-local speeds for specific workloads and environments, offering significant performance benefits whereas write-around waits for the origin to commit the writes to the stable storage before acknowledging the client. This results in every write incurring the penalty of traversing the network between the cache and origin.  
 
-## Considerations
+## Requirements and considerations
 
 * Cache volumes are currently only supported with the REST API (new caches endpoint).
-* The delegated subnet address space for hosting the Azure NetApp Files volumes must have at least seven free IP addresses: six for cluster peering and one for data access to one or more cache volumes.
-    * Ensure the delegated subnet address space is sized appropriately to accommodate the Azure NetApp Files network interfaces. Review the [guidelines for Azure NetApp Files network planning](azure-netapp-files-network-topologies.md) to ensure you meet the requirements for delegated subnet sizing.
-* When creating each cache volume, the Azure NetApp Files volume placement algorithm attempts to reuse the same Azure NetApp Files storage system as any previously created cache volumes in the subscription to reduce the number of NICs/IPs consumed in the delegated subnet. If this isn't possible, another 6+1 NICs are consumed.
-* You can't use the same source cluster for multiple subscriptions for creating cache volumes in the same availability zone in the same region. 
-* If enabling write-back on the external origin volume:
-    * You must be running ONTAP 9.15.1P5 or later on the system hosting the external origin volume. 
-    * Each external origin system node has at least 128 GB of RAM and 20 CPUs to absorb the write-back messages initiated by write-back enabled caches. This is the equivalent of an A400 or greater. If the origin cluster serves as the origin to multiple write-back enabled Azure NetApp Files cache volumes, it requires more CPUs and RAM.
-    * Testing is executed for files smaller than 100 GB and WAN roundtrip times between the cache and origin not exceeding 100 milliseconds. Any workloads outside of these limits might result in unexpected performance characteristics.
-    * The external origin must remain less than 80% full. Cache volumes aren't granted exclusive lock delegations if there isn't at least 20% space remaining in the origin volume. Calls to a write-back-enabled cache are forwarded to the origin in this situation. This helps prevent running out of space at the origin, which would result in leaving dirty data orphaned at a write-back-enabled cache.
-    * You shouldn't configure qtree, user, or group quotas at an origin volume with write-back enabled cache volumes. This may incur a significant latency increase.
-* You should be aware of the supported and unsupported features for cache volumes in Azure NetApp Files.
-    * Unsupported features:
-        * NFSv4.2
-        * Ransomware protection
-        * FlexCache disaster recovery
-        * S3 Buckets
-        * Azure NetApp Files backup
-        * Cross-region, cross-zone, and cross-zone-region replication
-        * Snapshot policies
-        * Application volume groups
-    * Supported features:
-        * NFSv3 and NFSv4.1, SMB, and dual-protocol (NFS and SMB)
-        * Lightweight Directory Access Protocol (LDAP)
-        * Kerberos
-        * Availability zone volume placement
-        * Customer-managed keys
 * The Azure NetApp Files cache volume must be deployed in an availability zone. To populate a new or existing volume in an availability zone, see [Manage availability zones in Azure NetApp Files](manage-availability-zone-volume-placement.md). 
-* Cache volumes only support Standard network features. Basic network features can't be configured on cache volumes. 
-* When creating a cache volume, ensure there's sufficient space in the capacity pool to accommodate the new cache volume.
-* You can't move a cache volume to another capacity pool.
-* You can't transition noncustomer managed key cache volumes to customer managed key (CMK).
+* When creating a cache volume, ensure that there's sufficient space in the capacity pool to accommodate the new cache volume.
 * You should ensure that the protocol type is the same for the cache volume and origin volume. The security style and the Unix permissions are inherited from the origin volume. For example, creating a cache volume with NFSv3 or NFSv4 when origin is UNIX, and SMB when the origin is NTFS.
 * You should enable encryption on the origin volume.
 * You should configure an Active Directory (AD) or LDAP connection within the NetApp account to create an LDAP-enabled cache volume.
-* The `globalFileLocking` parameter value must be the same on all cache volumes that share the same origin volume. Global file locking can be enabled when creating the first cache volume by setting `globalFileLocking` to true. The subsequent cache volumes from the same origin volume must have this setting set to true. To change the global file locking setting on existing cache volumes, you must update the origin volume first and then the change will propagate to all the cache volumes associated with that origin volume. The `volume flexcache origin config modify -is-global-file-locking-enabled` command should be executed on the source cluster to change the setting on the origin volume.
+* You can't move a cache volume to another capacity pool.
+* The `globalFileLocking` parameter value must be the same on all cache volumes that share the same origin volume. Global file locking can be enabled when creating the first cache volume by setting `globalFileLocking` to true. The subsequent cache volumes from the same origin volume must have this setting set to true. To change the global file locking setting on existing cache volumes, you must update the origin volume first. After updating the origin volume, the change propagates to all the cache volumes associated with that origin volume. The `volume flexcache origin config modify -is-global-file-locking-enabled` command should be executed on the source cluster to change the setting on the origin volume.
+
+### Networking considerations 
+
+* Cache volumes only support Standard network features. Basic network features can't be configured on cache volumes. 
+* The delegated subnet address space for hosting the Azure NetApp Files volumes must have at least seven free IP addresses: six for cluster peering and one for data access to one or more cache volumes.
+    * Ensure that the delegated subnet address space is sized appropriately to accommodate the Azure NetApp Files network interfaces. Review the [guidelines for Azure NetApp Files network planning](azure-netapp-files-network-topologies.md) to ensure you meet the requirements for delegated subnet sizing.
+* When creating each cache volume, the Azure NetApp Files volume placement algorithm attempts to reuse the same Azure NetApp Files storage system as any previously created cache volumes in the subscription to reduce the number of network interface cards (NICs)/IPs consumed in the delegated subnet. If this isn't possible, another 6+1 NICs are consumed.
+* You can't use the same source cluster for multiple subscriptions for creating cache volumes in the same availability zone in the same region. 
+
+### Write-back considerations 
+
+If you're enabling write-back on the external origin volume:
+
+* You must be running ONTAP 9.15.1P5 or later on the system hosting the external origin volume. 
+* Each external origin system node has at least 128 GB of RAM and 20 CPUs to absorb the write-back messages initiated by write-back enabled caches. This is the equivalent of an A400 or greater. If the origin cluster serves as the origin to multiple write-back enabled Azure NetApp Files cache volumes, it requires more CPUs and RAM.
+* Testing is executed for files smaller than 100 GB and WAN roundtrip times between the cache and origin not exceeding 100 milliseconds. Any workloads outside of these limits might result in unexpected performance characteristics.
+* The external origin must remain less than 80% full. Cache volumes aren't granted exclusive lock delegations if there isn't at least 20% space remaining in the origin volume. Calls to a write-back-enabled cache are forwarded to the origin in this situation. This helps prevent running out of space at the origin, which would result in leaving dirty data orphaned at a write-back-enabled cache.
+* You shouldn't configure qtree, user, or group quotas at an origin volume with write-back enabled cache volumes. This may incur a significant latency increase.
+
+### Interoperability considerations 
+
+You can't use cache volumes if the following features are configured on the source or destination: 
+
+#### Unsupported features
+
+The following features can't be used with Azure NetApp Files cache volumes:
+
+* Application volume groups
+* Azure NetApp Files backup
+* Cross-region, cross-zone, and cross-zone-region replication
+* FlexCache disaster recovery
+* NFSv4.2
+* Ransomware protection
+* Snapshot policies
+* S3 Buckets
+
+#### Supported features
+
+The following features are supported with cache volumes:
+
+* Availability zone volume placement
+* Customer-managed keys
+* Lightweight Directory Access Protocol (LDAP)
+* NFSv3 and NFSv4.1, SMB, and dual-protocol (NFS and SMB)
+* Kerberos
+
+>[!NOTE]
+>You can't transition noncustomer managed key cache volumes to customer managed key.
 
 ## Register the feature
 
@@ -119,19 +139,19 @@ The network connectivity must be in place for all intercluster (IC) LIFs on the
     > Don't execute the `vserverPeeringCommand` until the next step.
 
     > [!NOTE]
-    > If cache volumes are already created using this ONTAP system, then the existing cluster peer is reused. There can be situations where a different Azure NetApp Files cluster may be used which would require a new cluster peer.
+    > If cache volumes are already created using this ONTAP system, then the existing cluster peer is reused. There can be situations where a different Azure NetApp Files cluster might be used, which requires a new cluster peer.
 
 3.	Monitor if the cache state is available for storage VM peering using a GET request.
 
-    When the `cacheState = VserverPeeringOfferSent`, go to the ONTAP system that contains the external origin volume and execute the `vserver peer show` command until an entry appears where the remote storage VM displays the `<value of the -peer-vserver in the vserverPeeringCommand>`. The Peer State shows "pending".
+    When the `cacheState = VserverPeeringOfferSent`, go to the ONTAP system that contains the external origin volume and execute the `vserver peer show` command until an entry appears where the remote storage VM displays the `<value of the -peer-vserver in the vserverPeeringCommand>`. The peer state shows "pending."
 
-    Execute the `vserverPeeringCommand` on the ONTAP system that contains the external origin volume. The peer state should transition to "peered".
+    Execute the `vserverPeeringCommand` on the ONTAP system that contains the external origin volume. The peer state should transition to "peered."
 
     > [!NOTE]
-    > You have 12 minutes after the `cacheState` transitions to `VserverPeeringOfferSent` to complete execution of the `vserverPeeringCommand`. If you don't execute the command within 12 minutes, cache creation fails. You will need to delete the cache volume and initiate a new PUT request.
+    > You have 12 minutes after the `cacheState` transitions to `VserverPeeringOfferSent` to complete execution of the `vserverPeeringCommand`. If you don't execute the command within 12 minutes, cache creation fails. You'll need to delete the cache volume and initiate a new PUT request.
 
     > [!NOTE]
-    > If cache volumes are already created using this ONTAP system and the cluster peer was reused, then the existing vserver peer may be reused. If that happens, then step 3 will be skipped and the next step will be executed.
+    > If cache volumes are already created using this ONTAP system and the cluster peer was reused, then the existing vserver peer may be reused. If that happens, you'll skip step three and the next step will be executed.
 
 4.	Complete the cache volume creation.
 

articles/azure-netapp-files/faq-data-migration-protection.md

@@ -99,11 +99,11 @@ No. If you want to use the existing subnet, you should clean up the IP addresses
 
 ### Can I enable cool access on a migration volume in the migration assistant tool?
 
-You should only enable cool access if you've finalized migration. Otherwise, use a different volume. Finalizing the migration converts the volume a regular Azure NetApp Files volume allowing you to enable cool access.
+You should only enable cool access if you've finalized migration. Otherwise, use a different volume. Finalizing the migration converts the volume to a regular Azure NetApp Files volume, allowing you to enable cool access.
 
 ### Why am I not able to resume migrations after it has been paused from the migration assistant tool?
 
-Select the action from the **Migration** tab of the volume, not from the migration assistant view. The Migration tab is up to date for all migrations that are paused or resumed.
+Select the action icon from the **Migration** tab of the volume, not from the migration assistant view. 
 
 ### Are there post-migration steps to be performed on ONTAP systems?
 

articles/azure-netapp-files/migrate-volumes.md

@@ -196,7 +196,7 @@ The network connectivity must be in place for all intercluster (IC) LIFs on the
     GET https://<region>.management.azure.com/subscriptions/<subscription-ID>/providers/Microsoft.NetApp/locations/<location>/operationResults/<>?api-version=2025-06-01&...
     ```
 
-    An example response: 
+    The response looks like: 
 
     ```json
     {
@@ -259,7 +259,7 @@ The portal version of the migration assistant is currently in preview.
     | **Cut over** | Removes the replication relationship. If this is the last migration to this Azure NetApp Files storage, the peering relationship is also removed. |
     | **Finalize migration** |  Deletes the external migration relationship and converts the destination volume into a regular volume. If this is the last migration to this Azure NetApp Files account, the peering relationship is also removed. |
     | **Cancel migration** | Cancels the migration process and deletes the destination volume. The peering relationship between the ONTAP cluster and Azure NetApp Files is removed if it's not used by any other migration volume. |
-    | **View migration details** | Migration details provide information about the migration for a specific volume. To view these details, go to the under the **Actions** column then select the three dots `...` associated with the volume and **View migration details**. |
+    | **View migration details** | Learn about the migration status and details for a specific volume. To view these details, select the three dots `...` associated with the volume under the Actions column then **View migration details**. |
  
 2.  Select **New migration**.
 3.	In the **Source** tab, provide the following information:
@@ -268,7 +268,7 @@ The portal version of the migration assistant is currently in preview.
     Enter the name for the cluster that contains the volume you're migrating.
 
     * **SVM Name**
-    Enter the name for the external storage VM that contains the volume you're migrating.
+    Enter the name for the external SVM that contains the volume you're migrating.
     
     * **Source volume name**
     Enter the name for the external ONTAP volume that you're migrating. 

articles/cost-management-billing/manage/subscription-transfer.md

@@ -7,7 +7,7 @@ ms.reviewer: nicholak
 ms.service: cost-management-billing
 ms.subservice: billing
 ms.topic: concept-article
-ms.date: 10/21/2025
+ms.date: 11/06/2025
 ---
 
 # Azure product transfer hub