ADLS Gen2 support clarified

stevenmatthew · stevenmatthew · commit 7b5e20fa7db4 · 2024-05-14T19:14:47.000-07:00
diff --git a/articles/storage/blobs/data-protection-overview.md b/articles/storage/blobs/data-protection-overview.md
@@ -109,9 +109,9 @@ The following table summarizes the cost considerations for the various data prot
 
 Azure Storage always maintains multiple copies of your data so that it's protected from planned and unplanned events, including transient hardware failures, network or power outages, and massive natural disasters. Redundancy ensures that your storage account meets its availability and durability targets even in the face of failures. For more information about how to configure your storage account for high availability, see [Azure Storage redundancy](../common/storage-redundancy.md).
 
-If your storage account is configured for geo-redundancy, you have the option to fail over your account from the primary to the secondary region during a data center failure. For more information, see [Disaster recovery and storage account failover](../common/storage-disaster-recovery-guidance.md).
+If your storage account is configured for geo-redundancy, you have the option to initiate an unplanned failover from the primary to the secondary region during a data center failure. For more information, see [Disaster recovery planning and failover](../common/storage-disaster-recovery-guidance.md#customer-managed-unplanned-failover). 
 
-Customer-managed failover isn't currently supported for storage accounts with a hierarchical namespace enabled. For more information, see [Blob storage features available in Azure Data Lake Storage Gen2](./storage-feature-support-in-storage-accounts.md).
+Customer-managed failover currently supports storage accounts with a hierarchical namespace enabled in preview status only. For more information, see [Disaster recovery planning and failover](../common/storage-disaster-recovery-guidance.md#plan-for-failover).
 
 ## Next steps
 
diff --git a/articles/storage/common/storage-disaster-recovery-guidance.md b/articles/storage/common/storage-disaster-recovery-guidance.md
@@ -50,7 +50,7 @@ Read-access geo-redundant storage (RA-GRS) and read-access geo-zone-redundant st
 
 For more information about redundancy for Azure Storage, see [Azure Storage redundancy](storage-redundancy.md).
 
-## Plan for storage account failover
+## Plan for failover
 
 Azure Storage accounts support three types of failover:
 
@@ -67,7 +67,39 @@ Each type of failover has a unique set of use cases, corresponding expectations
 |----------------------------------------|-----------------|----------|--------------------|----------------------------------------|
 | Customer-managed planned failover      | Storage account | The storage service endpoints for the primary and secondary regions are available, and you want to perform disaster recovery testing. <br></br> The storage service endpoints for the primary region are available, but a networking or compute outage in the primary region is preventing your workloads from functioning properly. | [No](#anticipate-data-loss-and-inconsistencies)  | [Yes <br> *(In preview)*](#azure-data-lake-storage-gen2) |
 | Customer-managed (unplanned) failover              | Storage account | The storage service endpoints for the primary region become unavailable, but the secondary region is available. <br></br> You received an Azure Advisory in which Microsoft advises you to perform a failover operation of storage accounts potentially affected by an outage. | [Yes](#anticipate-data-loss-and-inconsistencies) | [Yes <br> *(In preview)*](#azure-data-lake-storage-gen2) |
-| Microsoft-managed                      | Entire region or scale unit   | The primary region becomes unavailable due to a significant disaster, but the secondary region is available. | [Yes](#anticipate-data-loss-and-inconsistencies) | [Yes](#azure-data-lake-storage-gen2) |
+| Microsoft-managed                      | Entire region   | The primary region becomes unavailable due to a significant disaster, but the secondary region is available. | [Yes](#anticipate-data-loss-and-inconsistencies) | [Yes](#azure-data-lake-storage-gen2) |
+
+Although both types of customer-managed failover work in a similar manner, there are primarily two ways in which they differ:
+
+- The management of the redundancy configurations within the primary and secondary regions (LRS or ZRS).
+- The status of the geo-redundancy configuration at each stage of the failover and failback process.
+
+The following table compares the redundancy state of a storage account after a failover of each type:
+
+| Result of failover on...                | Customer-managed planned failover (preview)  | Customer-managed (unplanned) failover                                               |
+|-----------------------------------------|----------------------------------------------|-------------------------------------------------------------------------|
+| ...the secondary region                 | The secondary region becomes the new primary | The secondary region becomes the new primary                            |
+| ...the original primary region          | The original primary region becomes the new secondary |The copy of the data in the original primary region is deleted  |
+| ...the account redundancy configuration | The storage account is converted to GRS      | The storage account is converted to LRS                                 |
+| ...the geo-redundancy configuration     | Geo-redundancy is retained                   | Geo-redundancy is lost                                                  |
+
+The following table summarizes the resulting redundancy configuration at every stage of the failover and failback process for each type of failover:
+
+| Original <br> configuration           | After <br> failover | After re-enabling <br> geo redundancy | After <br> failback | After re-enabling <br> geo redundancy |
+|---------------------------------------|---------------------|---------------------------------------|---------------------|---------------------------------------|
+| **Customer-managed planned failover** |                     |                                       |                     |                                       |
+| GRS                                   | GRS                 | n/a <sup>2</sup>                      | GRS                 | n/a <sup>2</sup>                      |
+| GZRS                                  | GRS                 | n/a <sup>2</sup>                      | GZRS                | n/a <sup>2</sup>                      |
+| **Customer-managed (unplanned) failover**                              |                     |                                       |                     |                                       |
+| GRS                                   | LRS                 | GRS <sup>1</sup>                      | LRS                 | GRS <sup>1</sup>                      |
+| GZRS                                  | LRS                 | GRS <sup>1</sup>                      | ZRS                 | GZRS <sup>1</sup>                     |
+
+<sup>1</sup> Geo-redundancy is lost during unplanned failover and must be manually reconfigured.<br>
+<sup>2</sup> Geo-redundancy is retained during a unplanned failover and doesn't need to be manually reconfigured.
+
+If the data endpoints for the storage services in your storage account become unavailable in the primary region, you can initiate a failover to the secondary region. After the failover is complete, the secondary region becomes the new primary and users can proceed to access data there.
+
+To understand the effect of this type of failover on your users and applications, it's helpful to know what happens during every step of the failover and failback process. For details about how the process works, see [How customer-managed (unplanned) failover works](storage-failover-customer-managed-unplanned.md).
 
 ### Customer-managed planned failover (preview)
 
@@ -79,7 +111,7 @@ Each type of failover has a unique set of use cases, corresponding expectations
 
 [!INCLUDE [storage-failover-user-unplanned-preview-lst](../../../includes/storage-failover-user-unplanned-preview-lst.md)]
 
-Customer-managed planned failover (preview) can be used to to test your disaster recovery plan. During the planned failover process, the primnary and secondary regions are swapped. The original primary region is demoted and becomes the new secondary, while the original secondary region is promoted and becomes the new primary. After the failover completes, users can proceed to access data in the new primary region and administrators can validate their disaster recovery plan. The storage account must be available in both the primary and secondary regions before a planned failover can be initiated.
+Customer-managed planned failover (preview) can be used to to test your disaster recovery plan. During the planned failover process, the primary and secondary regions are swapped. The original primary region is demoted and becomes the new secondary, while the original secondary region is promoted and becomes the new primary. After the failover completes, users can proceed to access data in the new primary region and administrators can validate their disaster recovery plan. The storage account must be available in both the primary and secondary regions before a planned failover can be initiated.
 
 Planned failover can also be used during a partial networking or compute outage in your primary region. These outages might occur, for example, when workloads in your primary region are disrupted but your storage service endpoints are available.
 
@@ -89,7 +121,7 @@ To understand the effect of this type of failover on your users and applications
 
 ### Customer-managed (unplanned) failover
 
-Although both types of customer-managed failover work in a similar manner, there are primarily two ways in which they differ:
+<!--Although both types of customer-managed failover work in a similar manner, there are primarily two ways in which they differ:
 
 - The management of the redundancy configurations within the primary and secondary regions (LRS or ZRS).
 - The status of the geo-redundancy configuration at each stage of the failover and failback process.
@@ -115,19 +147,19 @@ The following table summarizes the resulting redundancy configuration at every s
 | GZRS                                  | LRS                 | GRS <sup>1</sup>                      | ZRS                 | GZRS <sup>1</sup>                     |
 
 <sup>1</sup> Geo-redundancy is lost during unplanned failover and must be manually reconfigured.<br>
-<sup>2</sup> Geo-redundancy is retained during a unplanned failover and doesn't need to be manually reconfigured.
+<sup>2</sup> Geo-redundancy is retained during a unplanned failover and doesn't need to be manually reconfigured.-->
 
 If the data endpoints for the storage services in your storage account become unavailable in the primary region, you can initiate a failover to the secondary region. After the failover is complete, the secondary region becomes the new primary and users can proceed to access data there.
 
-To understand the effect of this type of failover on your users and applications, it's helpful to know what happens during every step of the failover and failback process. For details about how the process works, see [How customer-managed (unplanned) failover works](storage-failover-customer-managed-unplanned.md).
+To understand the effect of this type of failover on your users and applications, it's helpful to know what happens during every step of the unplanned failover and failback process. For details about how the process works, see [How customer-managed (unplanned) failover works](storage-failover-customer-managed-unplanned.md).
 
 ### Microsoft-managed failover
 
-Although Microsoft could potentially initiate a regional failover, this only happens in extreme circumstances such as major disasters. Regional failovers are extremely uncommon and only take place when the original primary region is deemed unrecoverable within a reasonable amount of time. During these events, no action on your part is required. If your storage account is configured for RA-GRS or RA-GZRS, your applications can read from the secondary region during a Microsoft-managed failover. However, you don't have write access to your storage account until the failover process is complete.
+Microsoft may potentially initiate a regional failover in the event of an extreme circumstance such as a catastrophic disaster that impacts an entire geo region. During these events, no action on your part is required. If your storage account is configured for RA-GRS or RA-GZRS, your applications can read from the secondary region during a Microsoft-managed failover. However, you don't have write access to your storage account until the failover process is complete.
 
 > [!IMPORTANT]
 > Use customer-managed failover options to develop, test, and implement your disaster recovery plans. **Do not** rely on Microsoft-managed failover, which might only be used in extreme circumstances.
-> A Microsoft-managed failover would be initiated for an entire physical unit, such as a region, datacenter or scale unit. It can't be initiated for individual storage accounts, subscriptions, or tenants. If you need the ability to selectively failover your individual storage accounts, use [customer-managed planned failover](#customer-managed-planned-failover-preview).
+> A Microsoft-managed failover would be initiated for an entire physical unit, such as a region, datacenter. It can't be initiated for individual storage accounts, subscriptions, or tenants. If you need the ability to selectively failover your individual storage accounts, use [customer-managed planned failover](#customer-managed-planned-failover-preview).
 
 ### Anticipate data loss and inconsistencies
 
