remove ext. 1 references

Author: b-ahibbard

articles/azure-netapp-files/application-volume-group-add-hosts.md

@@ -46,8 +46,6 @@ Building a multiple-host SAP HANA database always starts with creating a volume
 
     Select **Next** and continue through the **Protocol** and **Tags** sections, providing the same input as the first HANA host. (See Step 4 through Step 6 in [Deploy the first SAP HANA host](application-volume-group-deploy-first-host.md).)   
 
-    [!INCLUDE [Extension 1 interface call-out](./includes/extension-one.md)]
-
     Select **Next: Volumes** when you reach the end of the sections. 
 
     For hosts that you add, only the data and the log volumes are created. The **Volumes** page displays the two volumes in a generic form, using the `{HostId}` as a placeholder. This process simplifies the workflow, because changes are made only once for the data and log volumes for all the hosts that are being created.

articles/azure-netapp-files/application-volume-group-add-volume-secondary.md

@@ -18,7 +18,7 @@ The HANA System Replication (HSR) functionality enables SAP HANA databases to sy
 
 * Both the primary and the secondary SAP HANA databases have the same SAP ID (SID), but their volume names need to be different.
 
-* The secondary SAP HANA system might be in a different location, typically a different zone or region.  As such, the proximity placement group (PPG, availability set) is different.
+* The secondary SAP HANA system might be in a different location, typically a different zone or region. As such, the proximity placement group (PPG, availability set) is different.
 
 The following diagram illustrates the concept of HSR: 
 
@@ -33,89 +33,6 @@ The workflow for creating a secondary SAP HANA system is similar to the workflow
 
 This section shows an example of creating a single-host, secondary SAP HANA system.
 
-[!INCLUDE [Extension 1 interface call-out](./includes/extension-one.md)]
-
-### [Without Extension 1](#tab/without-extension-one)
-
-1. From your NetApp account, select **Application volume groups**, and select **+Add Group**. In Deployment Type, select **SAP HANA** then **Next**. 
-
-2. In the **SAP HANA** tab, provide HANA-specific information. 
-
-    > [!IMPORTANT]
-    > Be sure to select the **HSR secondary** option to indicate that you are creating a replication secondary system for the HANA system.  
-
-    * **SAP ID (SID)**:   
-        The three alphanumeric-character SAP HANA system identifier.
-    * **Group name**:  
-        The volume group name. 
-    * **SAP node memory**:  
-        This value defines the size of the SAP HANA database on the host. It is used to calculate the required volume size and throughput. 
-    * **Capacity overhead (%)**:  
-        When you use snapshots for data protection, you need to plan for extra capacity. This field will add additional size (%) for the data volume.  
-        You can estimate this value by using `"change rate per day" X "number of days retention"`.
-    * **Single-host**:  
-        Select this option for an SAP HANA single-host system or the first host for a multiple-host system. Shared and backup volumes can be created only with the first host.
-    * **Multiple-host**:  
-        Select this option to add additional hosts to a multiple-hosts HANA system.
-    * **HSR secondary**:  
-        Select this option to create a HANA database that will be a replication secondary system for SAP HANA System Replication (HSR).
-
-        Selecting **HSR secondary** also triggers the naming convention for the volume group name to include `"-HA-"` to indicate the HA setup.   
-
-    Select **Next: Volume Group** to continue.
-
-    [ ![Screenshot that shows the HANA section in HSR configuration.](./media/application-volume-group-add-volume-secondary/application-secondary-sap-hana.png) ](./media/application-volume-group-add-volume-secondary/application-secondary-sap-hana.png#lightbox)
-
-3.	In the **Volume group** tab, provide information for creating the volume group:  
-
-    * **Proximity placement group (PPG)**:  
-        Specifies that the data, log, and shared volumes are to be created close to the VMs.
-    * **Capacity pool**:  
-        All volumes will be placed in a single manual QoS capacity pool.  
-        If you want to create the log-backup and data-backup volumes in a separate capacity pool, you can choose not to add those volumes to the volume group.
-    * **Virtual network**:  
-        Specify an existing VNet where the VMs are placed. 
-    * **Subnet**:  
-        Specify the delegated subnet where the IP addresses for the NFS exports will be created. Ensure that you have a delegated subnet with enough free IP addresses.
-
-    Select **Next: Protocol**.
-
-4. In the **Protocols** section of the Volume Group tab, you can modify the **Export Policy**, which should be common to all volumes.  
-
-    Select **Next: Tags**.
-
-5. Because the **HSR secondary** option is selected, the **Tags** section of the Volume Group tab is populated with the tag `HSRPartnerStorageResourceId`. 
-
-    This tag marks the volume resource ID of the corresponding primary volume in the HSR setup, so that the primary volume can be identified for each secondary volume that will be created. 
-
-    You will be able to modify this tag for each volume. 
-
-    > [!IMPORTANT]
-    > At the group level, filling the tag will populate all the volumes in the group with the same volume ID. You will need to change the volume ID for each individual volume later in the workflow or when you update the volumes. Using this tag is optional; it’s for documentation purposes only.
-
-    Select **Next: Volumes**.
-
-    [ ![Screenshot that shows the Tags section of the Volume Group tab.](./media/application-volume-group-add-volume-secondary/application-secondary-volume-group-tags.png) ](./media/application-volume-group-add-volume-secondary/application-secondary-volume-group-tags.png#lightbox)
-
-6. The **Volumes** tab displays information about the volumes that are being created.  
-
-    The volume naming convention includes an `"HA-"` prefix to indicate that the volume belongs to the secondary system of an HSR setup.
-
-    [ ![Screenshot that shows the Volume Group tab.](./media/application-volume-group-add-volume-secondary/application-secondary-volumes-tags.png) ](./media/application-volume-group-add-volume-secondary/application-secondary-volumes-tags.png#lightbox)
-
-7. In the **Volumes** tab, you can select each volume to view or change the volume details, including the protocol and tag for the volume.
-
-    In the **Tags** section of a volume, you can populate the `HSRPartnerStorageResourceId` tag with the resource ID of the corresponding primary volume. This action only marks the primary volume; it does not validate the provided resource ID.
-
-    [ ![Screenshot that shows the tag details.](./media/application-volume-group-add-volume-secondary/application-secondary-volumes-tag-details.png) ](./media/application-volume-group-add-volume-secondary/application-secondary-volumes-tag-details.png#lightbox)
-
-    Select **Volumes** to return to the Volumes overview page.  
-
-8. Select **Review + Create** to list all volumes that will be created. Select **Create Volume Group** to start the volume group creation. 
-
-
-### [Extension 1](#tab/extension-1)
-
 1. From your NetApp account, select **Application volume groups**, and select **+Add Group**. In Deployment Type, select **SAP HANA** then **Next**. 
 
     :::image type="content" source="./media/application-volume-group-add-volume-secondary/extension-one-create.png" alt-text="Screenshot of application volume group creation menu." lightbox="./media/application-volume-group-add-volume-secondary/extension-one-create.png":::
@@ -169,7 +86,7 @@ This section shows an example of creating a single-host, secondary SAP HANA syst
 
     Select **Next: Protocol**.
 
-    :::image type="content" source="./media/application-volume-group-add-volume-secondary/application-volume-group-create-extension-one.png" alt-text="Screenshot of create application volume group interface for extension one." lightbox="./media/application-volume-group-add-volume-secondary/application-volume-group-create-extension-one.png":::
+    :::image type="content" source="./media/application-volume-group-add-volume-secondary/application-volume-group-create-extension-one.png" alt-text="Screenshot of create application volume group interface." lightbox="./media/application-volume-group-add-volume-secondary/application-volume-group-create-extension-one.png":::
 
 4. In the **Protocols** section of the Volume Group tab, you can modify the **Export Policy**, which should be common to all volumes.  
 

articles/azure-netapp-files/application-volume-group-concept.md

@@ -71,7 +71,7 @@ Volume placement within the application volume group enables organizations to ad
 
 #### Customer managed key support
 
-Azure NetApp Files application volume group for SAP HANA extension 1 and Oracle support volume deployments with customer-managed keys, offering increased security and compliance. 
+Azure NetApp Files application volume group for SAP HANA and Oracle support volume deployments with customer-managed keys, offering increased security and compliance. 
 
 #### Constrained zone resource availability
 

articles/azure-netapp-files/application-volume-group-considerations.md

@@ -14,8 +14,12 @@ This article describes the requirements and considerations you need to be aware
 
 ## Requirements and considerations
 
-* You need to use the [manual QoS capacity pool](manage-manual-qos-capacity-pool.md) functionality.  
-* You must create a proximity placement group (PPG) and anchor it to your SAP HANA compute resources. Application volume group for SAP HANA needs this setup to search for an Azure NetApp Files resource that is close to the SAP HANA servers. For more information, see [Best practices about Proximity Placement Groups](#best-practices-about-proximity-placement) and [Create a Proximity Placement Group using the Azure portal](/azure/virtual-machines/windows/proximity-placement-groups-portal).
+* Application volume group supports Basic and Standard network features. To use features including availability zone volume placement, use [Standard network features](azure-netapp-files-network-topologies.md).
+* You need to use the [manual QoS capacity pool](manage-manual-qos-capacity-pool.md) functionality. 
+* Application volume group supports [availability zone volume placement](use-availability-zones.md) as the new default method for placement. This upgrade mitigates the need for AVset pinning and eliminates the need for proximity placement groups. With support for availability zone volume placement, you only need to select the same availability zone as the database servers. Using availability zone volume placement aligns with the Microsoft recommendation on how to deploy SAP HANA infrastructures to achieve best performance with high-availability, maximum flexibility, and simplified deployment. 
+    * If regions don't support availability zones, you can select a regional deployment or choose proximity placement groups (PPG).
+
+    When you create a PPG, you must anchor it to your SAP HANA compute resources. Application volume group for SAP HANA needs this setup to search for an Azure NetApp Files resource that is close to the SAP HANA servers. For more information, see [Best practices about Proximity Placement Groups](#best-practices-about-proximity-placement) and [Create a Proximity Placement Group using the Azure portal](/azure/virtual-machines/windows/proximity-placement-groups-portal).
 
    >[!NOTE]
    >Do not delete the PPG. Deleting a PPG removes the pinning and can cause subsequent volume groups to be created in sub-optimal locations which could lead to increased latency.
@@ -29,32 +33,22 @@ This article describes the requirements and considerations you need to be aware
     * The expected change rate for the data volume (in case you're using snapshots for backup purposes)
 * You must create a VNet and delegated subnet to map the Azure NetApp Files IP addresses.
 
-    It is recommended that you lay out the VNet and delegated subnet at design time. 
+    It's recommended that you lay out the VNet and delegated subnet at design time. 
 
     Application volume group for SAP HANA creates multiple IP addresses, up to six IP addresses for larger-sized estates. Ensure that the delegated subnet has sufficient free IP addresses. Consider using a delegated subnet with a minimum of 251 IP addresses with a subnet size of /24. See [Considerations about delegating a subnet to Azure NetApp Files](azure-netapp-files-delegate-subnet.md#considerations).
-* Application volume group for SAP HANA only supports platform-managed keys for Azure NetApp Files volume encryption at volume creation at this time. Contact your Azure NetApp Files specialist or CSA if you have any questions about transitioning volumes from platform-managed keys to customer-managed keys after volume creation. Alternately, you can use customer-managed keys with extension 1.  
 
 >[!IMPORTANT]
 >The use of application volume group for SAP HANA for applications other than SAP HANA is not supported. Reach out to your Azure NetApp Files specialist for guidance on using Azure NetApp Files multi-volume layouts with other database applications.
 
-### <a name="extension-1-requirements-considerations"></a> Extension 1 requirements and considerations
-
-* You must be [registered for extension 1](application-volume-group-deploy-first-host.md#register-for-extension-1).
-* Application volume group supports Basic network features. If you're registered for extension 1, application volume group also supports [Standard network features](azure-netapp-files-network-topologies.md).
-* Extension 1 supports [availability zone volume placement](use-availability-zones.md) as the new default method for placement. This upgrade mitigates the need for AVset pinning and eliminates the need for proximity placement groups. With support for availability zone volume placement, you only need to select the same availability zone as the database servers. Using availability zone volume placement aligns with the Microsoft recommendation on how to deploy SAP HANA infrastructures to achieve best performance with high-availability, maximum flexibility, and simplified deployment. 
-    If regions do not support availability zones, you can select a regional deployment or choose proximity placement groups.
-* Extension one supports [customer-managed-keys](configure-customer-managed-keys.md).
-
 ## Best practices about proximity placement
 
 To deploy SAP HANA volumes using the application volume group, you need to ensure that your HANA database VMs and the Azure NetApp Files resources are in close proximity to ensure lowest possible latency. You can achieve close proximity using either of the following deployment methods: 
 
 * **Availability zone volume placement (preferred)**
-        Select the availability zone for the volumes and select Standard network features for the deployment. Neither a proximity placement group nor VM pinning are required for this method. Before you can use this workflow, you must [register the feature](application-volume-group-deploy-first-host.md#register-for-extension-1).
+        Select the availability zone for the volumes and select Standard network features for the deployment. Neither a proximity placement group nor VM pinning are required for this method. 
 * **Proximity placement group with VM pinning**
     The application volume group uses a proximity placement group linked (or anchored) to the database VMs. When passed to the application volume group, the PPG is used to find all Azure NetApp Files resources in close proximity to the database servers. Volumes are deployed using Basic network features.
 
-
 > [!IMPORTANT]
 > A PPG is only anchored and can therefore identify the location of the VMs if at least one VM is started and kept running for the duration of all AVG deployments. If all VMs are stopped, the PPG loses its anchor, and at the next restart, the VMs may move to a different location. This situation could lead to increased latency as Azure NetApp Files volumes are not moved after initial creation.