Final edits

Author: normesta

articles/storage/blobs/immutable-container-level-worm-policies.md

@@ -13,11 +13,11 @@ ms.author: normesta
 
 # Container-level write once, read many (WORM) policies for immutable blob data
 
-A container-level write once, read many (WORM) policy is a type of immutability policy that can be set at the container-level.
+A container-level write once, read many (WORM) policy is a type of immutability policy that can be set at the container-level. To learn more about immutable storage for Azure Blob Storage, see [Store business-critical blob data with immutable storage in a write once, read many (WORM) state](immutable-storage-overview.md)
 
 ## Availability
 
-Container-level WORM policies are available for all new and existing containers. These policies are supported for general-purpose v2, premium block blob, general-purpose v1 (legacy), and blob storage (legacy) accounts.
+Container-level WORM (CLW) policies are available for all new and existing containers. These policies are supported for general-purpose v2, premium block blob, general-purpose v1 (legacy), and blob storage (legacy) accounts.
 
 > [!TIP]
 > Microsoft recommends upgrading general-purpose v1 accounts to general-purpose v2 so that you can take advantage of more features. For information on upgrading an existing general-purpose v1 storage account, see [Upgrade a storage account](../common/storage-account-upgrade.md).

articles/storage/blobs/immutable-version-level-worm-policies.md

@@ -1,27 +1,27 @@
 ---
 title: Version-level WORM policies for immutable blob data
 titleSuffix: Azure Storage
-description: Description for version-level WORM goes here.
+description:  version-level write once, read many (WORM) policy is a type of immutability policy that can be set at the account, container, or version level.
 services: storage
 author: normesta
 
 ms.service: azure-blob-storage
 ms.topic: conceptual
-ms.date: 09/14/2022
+ms.date: 03/26/2024
 ms.author: normesta
 ---
 
 # Version-level write once, read many (WORM) policies for immutable blob data
 
-Something needed here as an introduction.
+A version-level write once, read many (WORM) policy is a type of immutability policy that can be set at the account, container, or version level. To learn more about immutable storage for Azure Blob Storage, see [Store business-critical blob data with immutable storage in a write once, read many (WORM) state](immutable-storage-overview.md).
 
 ## Availability
 
-Version-level immutability policies are supported on the account level for new accounts, and at the container and blob level for new and existing accounts/containers. These policies are supported for both general-purpose v2 and premium block blob accounts. This feature is not supported on hierarchical namespace accounts.
+Version-level immutability (VLW) policies are supported on the account level for new accounts, and at the container and blob level for new and existing accounts/containers. These policies are supported for both general-purpose v2 and premium block blob accounts. This feature isn't supported on hierarchical namespace accounts.
 
 ## Version dependency
 
-Version-level policies require that [blob versioning](versioning-overview.md) is enabled for the storage account. To learn how to enable blob versioning, see [Enable and manage blob versioning](versioning-enable.md). Keep in mind that enabling versioning may have a billing impact. For more information, see the Pricing and billing section in Blob versioning.
+Version-level policies require that [blob versioning](versioning-overview.md) is enabled for the storage account. To learn how to enable blob versioning, see [Enable and manage blob versioning](versioning-enable.md). Keep in mind that enabling versioning may have a billing impact. For more information, see the [Pricing and billing section for Blob Versioning](versioning-overview.md#pricing-and-billing).
 
 After versioning is enabled, when a blob is first uploaded, that version of the blob is the current version. Each time the blob is overwritten, a new version is created that stores the previous state of the blob. When you delete the current version of a blob, the current version becomes a previous version and is retained until explicitly deleted. A previous blob version possesses the time-based retention policy that was in effect when the current version became a previous version.
 
@@ -33,34 +33,34 @@ To learn how to configure version-level time-based retention policies, see [Conf
 
 ## Enablement and policy setting
 
-Using immutable policies with VLW is a two-step process, including enablement and policy setting.
+Using immutable policies with version-level WORM is a two-step process. First, enable version-level immutability. Then, you can set version-level immutability policies.
 
-To set a policy at the account level, the account must be enabled to set VLW policies. This can only happen at account creation time— there is no option to enable VLW for pre-existing accounts.
+To set a policy at the storage account level, you must enable version-level WORM on the storage account. You can do this only at account creation time. There's no option to enable version-level WORM for pre-existing accounts.
 
 > [!div class="mx-imgBorder"]
 > ![Diagram of setting a policy for version-level immutable storage at the account level.](media/immutable-version-level-worm-policies/version-level-immutable-storage-account-level.png)
 
-To set a policy at the container level, either the account OR container must be enabled to set VLW policies. To enable a container to set VLW policies, it is recommended that it be turned on at container creation, but a pre-existing container can be migrated from a non-VLW enabled container to a VLW enabled container. If a user chooses not to migrate, they can still always set a CLW policy at the container, but the option to set blob-level policies will not be available.
+To set a policy at the container level, you must enable version-level WORM either on the account OR on the container. To enable a container to set version-level WORM policies, Microsoft recommends that you enable version-level WORM at container creation, but an existing container can be migrated from a non-enabled container to an enabled one. If a user chooses not to migrate, they can still always set a container-level policy at the container, but the option to set blob-level policies won't be available.
 
 > [!div class="mx-imgBorder"]
 > ![Diagram of setting a policy for version-level immutable storage at the container level.](media/immutable-version-level-worm-policies/version-level-immutable-container-level.png)
 
-To set a policy at the blob level, either the account or container level must be enabled to set VLW policies. There is no option to allow enablement at the blob level; it must be inherited.
+To set a policy at the blob level, you must enable version-level WORM on either the account or container. There's no option to enable version-level WORM at the blob level; it must be inherited.
 
 > [!div class="mx-imgBorder"]
 > ![Diagram of setting a policy for version-level immutable storage at the blob level.](media/immutable-version-level-worm-policies/version-level-immutable-storage-blob-level.png)
 
 ### Migration
 
-Existing containers can support version-level immutability but must undergo a migration process first. This process may take some time and isn't reversible. You can migrate 10 containers at a time per storage account. For more information about migrating a container to support version-level immutability, see [Migrate an existing container to support version-level immutability](immutable-policy-configure-version-scope.md#migrate-an-existing-container-to-support-version-level-immutability).
+Existing containers can support version-level immutability but must undergo a migration process first. This process might take some time. Once enabled, version-level WORM support for that container can't be removed. You can migrate 10 containers at a time per storage account. For more information about migrating a container to support version-level immutability, see [Migrate an existing container to support version-level immutability](immutable-policy-configure-version-scope.md#migrate-an-existing-container-to-support-version-level-immutability).
 
 ### Configure a policy on the current version
 
 After you enable support for version-level immutability for a storage account or container, then you have the option to configure a default time-based retention policy for the account or container. When you configure a default time-based retention policy for the account or container and then upload a blob, the blob inherits that default policy. You can also choose to override the default policy for any blob on upload by configuring a custom policy for that blob.
 
 If the default time-based retention policy for the account or container is unlocked, then the current version of a blob that inherits the default policy will also have an unlocked policy. After an individual blob is uploaded, you can shorten or extend the retention period for the policy on the current version of the blob or delete the current version. You can also lock the policy for the current version, even if the default policy on the account or container remains unlocked.
 
-If the default time-based retention policy for the account or container is locked, then the current version of a blob that inherits the default policy will also have a locked policy. However, if you override the default policy when you upload a blob by setting a policy only for that blob, then that blob's policy will remain unlocked until you explicitly lock it. When the policy on the current version is locked, you can extend the retention interval, but you can't delete the policy or shorten the retention interval.
+If the default time-based retention policy for the account or container is locked, then the current version of a blob that inherits the default policy will also have a locked policy. However, if you override the default policy when you upload a blob by setting a policy only for that blob, then that blob's policy remains unlocked until you explicitly lock it. When the policy on the current version is locked, you can extend the retention interval, but you can't delete the policy or shorten the retention interval.
 
 If there's no default policy configured for either the storage account or the container, then you can upload a blob either with a custom policy or with no policy.
 
@@ -88,7 +88,7 @@ If the policy on a current version is modified, the policies on existing previou
 
 ## Deletion
 
-Once an account or container is enabled for an immutable policy, it cannot be deleted until it is empty. The main thing to note is that it does not matter if an immutable policy has been set on a VLW account or container, it matters if it is enabled for a policy. Once it is, the account or container must be empty to be deleted.
+Once an account or container is enabled for an immutable policy, it can't be deleted until it's empty. The main thing to note is that it doesn't matter if an immutable policy has been set on a version-level WORM account or container, it matters if it's enabled for a policy. Once it is, the account or container must be empty to be deleted.
 
 > [!div class="mx-imgBorder"]
 > ![Diagram that shows the order of operations in deleting an account that has a version-level immutability policy.](media/immutable-version-level-worm-policies/version-level-immutable-storage-deletion.png)
@@ -97,8 +97,8 @@ Once an account or container is enabled for an immutable policy, it cannot be de
 
 | Scenario | Prohibited operations | Blob protection | Container protection | Account protection |
 |----|----|---|---|----|
-| A blob version is protected by an active retention policy and/or a legal hold is in effect | [Delete Blob](/rest/api/storageservices/delete-blob), [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), and [Put Page](/rest/api/storageservices/put-page) | The blob version cannot be deleted. User metadata cannot be written.<br>Overwriting a blob with [Put Blob](/rest/api/storageservices/put-blob), [Put Block List](/rest/api/storageservices/put-block-list), or [Copy Blob](/rest/api/storageservices/copy-blob) creates a new version<sup>1</sup>.| Container deletion fails if at least one blob exists in the container, regardless of whether policy is locked or unlocked. | Storage account deletion fails if there is at least one container with version-level immutable storage enabled, or if it is enabled for the account.|
-| A blob version is protected by an expired retention policy and no legal hold is in effect| Set Blob Metadata and Put Page | A blob version is protected by an expired retention policy and no legal hold is in effect|The blob version can be deleted.<br>Overwriting a blob with [Put Blob](/rest/api/storageservices/put-blob), [Put Block List](/rest/api/storageservices/put-block-list), or [Copy Blob](/rest/api/storageservices/copy-blob) creates a new version<sup>1</sup>.| Storage account deletion fails if there is at least one container that contains a blob version with a locked time-based retention policy.<br>Unlocked policies do not provide delete protection.|
+| A blob version is protected by an active retention policy and/or a legal hold is in effect | [Delete Blob](/rest/api/storageservices/delete-blob), [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), and [Put Page](/rest/api/storageservices/put-page) | The blob version can't be deleted. User metadata can't be written.<br>Overwriting a blob with [Put Blob](/rest/api/storageservices/put-blob), [Put Block List](/rest/api/storageservices/put-block-list), or [Copy Blob](/rest/api/storageservices/copy-blob) creates a new version<sup>1</sup>.| Container deletion fails if at least one blob exists in the container, regardless of whether policy is locked or unlocked. | Storage account deletion fails if there is at least one container with version-level immutable storage enabled, or if it's enabled for the account.|
+| A blob version is protected by an expired retention policy and no legal hold is in effect| Set Blob Metadata and Put Page | A blob version is protected by an expired retention policy and no legal hold is in effect|The blob version can be deleted.<br>Overwriting a blob with [Put Blob](/rest/api/storageservices/put-blob), [Put Block List](/rest/api/storageservices/put-block-list), or [Copy Blob](/rest/api/storageservices/copy-blob) creates a new version<sup>1</sup>.| Storage account deletion fails if there is at least one container that contains a blob version with a locked time-based retention policy.<br>Unlocked policies don't provide delete protection.|
 
 <sup>1</sup>    Blob versions are always immutable for content. If versioning is enabled for the storage account, then a write operation to a block blob creates a new version, with the exception of the Put Block operation.
 
@@ -110,7 +110,6 @@ There can only be 10,000 containers set with unique time-based retention policie
 
 - [Data protection overview](data-protection-overview.md)
 - [Store business-critical blob data with immutable storage](immutable-storage-overview.md)
-- [Version-level WORM policies for immutable blob data](immutable-version-level-worm-policies.md)
 - [Container-level WORM policies](immutable-container-level-worm-policies.md)
 - [Configure immutability policies for blob versions](immutable-policy-configure-version-scope.md)
 - [Configure immutability policies for containers](immutable-policy-configure-container-scope.md)