stashing some updates

Author: normesta

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

@@ -1,7 +1,7 @@
 ---
 title: Container-level WORM policies for immutable blob data
 titleSuffix: Azure Storage
-description: Description goes here.
+description: Description for container-level WORM goes here.
 services: storage
 author: normesta
 

articles/storage/blobs/immutable-policy-configure-version-scope.md

@@ -32,7 +32,7 @@ Configuring a version-level immutability policy is a two-step process:
 
 To configure version-level time-based retention policies, blob versioning must be enabled for the storage account. Keep in mind that enabling blob versioning may have a billing impact. To learn how to enable blob versioning, see [Enable and manage blob versioning](versioning-enable.md).
 
-For information about supported storage account configurations for version-level immutability policies, see [Supported account configurations](immutable-storage-overview.md#supported-account-configurations).
+For information about supported storage account configurations for version-level immutability policies, see [Version-level WORM policies for immutable blob data](immutable-version-level-worm-policies.md).
 
 ## Enable support for version-level immutability
 

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

@@ -1,7 +1,7 @@
 ---
 title: Version-level WORM policies for immutable blob data
 titleSuffix: Azure Storage
-description: Description goes here.
+description: Description for version-level WORM goes here.
 services: storage
 author: normesta
 

articles/storage/blobs/object-replication-overview.md

@@ -78,9 +78,9 @@ Object replication is supported when the source and destination accounts are in
 
 Immutability policies for Azure Blob Storage include time-based retention policies and legal holds. When an immutability policy is in effect on the destination account, object replication may be affected. For more information about immutability policies, see [Store business-critical blob data with immutable storage](immutable-storage-overview.md).
 
-If a container-level immutability policy is in effect for a container in the destination account, and an object in the source container is updated or deleted, then the operation on the source container may succeed, but replication of that operation to the destination container will fail. For more information about which operations are prohibited with an immutability policy that is scoped to a container, see [Scenarios with container-level scope](immutable-storage-overview.md#scenarios-with-container-level-scope).
+If a container-level immutability policy is in effect for a container in the destination account, and an object in the source container is updated or deleted, then the operation on the source container may succeed, but replication of that operation to the destination container will fail. For more information about which operations are prohibited with an immutability policy that is scoped to a container, see [Scenarios with container-level scope](immutable-container-level-worm-policies.md#scenarios).
 
-If a version-level immutability policy is in effect for a blob version in the destination account, and a delete or update operation is performed on the blob version in the source container, then the operation on the source object may succeed, but replication of that operation to the destination object will fail. For more information about which operations are prohibited with an immutability policy that is scoped to a container, see [Scenarios with version-level scope](immutable-storage-overview.md#scenarios-with-version-level-scope).
+If a version-level immutability policy is in effect for a blob version in the destination account, and a delete or update operation is performed on the blob version in the source container, then the operation on the source object may succeed, but replication of that operation to the destination object will fail. For more information about which operations are prohibited with an immutability policy that is scoped to a container, see [Scenarios with version-level scope](immutable-version-level-worm-policies.md#scenarios).
 
 ## Object replication policies and rules
 

articles/storage/blobs/point-in-time-restore-overview.md

@@ -90,7 +90,7 @@ Point-in-time restore for block blobs has the following limitations and known is
 - Snapshots aren't created or deleted as part of a restore operation. Only the base blob is restored to its previous state.
 - Point-in-time restore isn't supported for hierarchical namespaces or operations via Azure Data Lake Storage Gen2.
 - Point-in-time restore isn't supported when the storage account's **AllowedCopyScope** property is set to restrict copy scope to the same Microsoft Entra tenant or virtual network. For more information, see [About Permitted scope for copy operations (preview)](../common/security-restrict-copy-operations.md?toc=/azure/storage/blobs/toc.json&tabs=portal#about-permitted-scope-for-copy-operations-preview).
-- Point-in-time restore isn't supported when version-level immutability is enabled on a storage account or a container in an account. For more information on version-level immutability, see [Overview of immutable storage for blob data](immutable-storage-overview.md#version-level-scope).
+- Point-in-time restore isn't supported when version-level immutability is enabled on a storage account or a container in an account. For more information on version-level immutability, see [Configure immutability policies for blob versions](immutable-version-level-worm-policies.md).
 
 > [!IMPORTANT]
 > If you restore block blobs to a point that is earlier than September 22, 2020, preview limitations for point-in-time restore will be in effect. Microsoft recommends that you choose a restore point that is equal to or later than September 22, 2020 to take advantage of the generally available point-in-time restore feature.